April 3, 2018 at 4:52 pm #14224
The btBvhTriangleMeshShape is a static-triangle mesh shape, it can only be used for fixed/non-moving objects.
Kind of explains (partly) why my attempt at using this resulted in the model not rotating — it’s not meant to! (Doesn’t explain why it still moved, guess Bullet doesn’t properly check if it’s static.)
Objects basically did collide with it, but it moved about because it wasn’t static (ie. with mass = 0.0), so maybe some sort of cross-check between use of MeshCollider and mass = 0.0 would help avoid confusion… ? Will try this out again later.
This one ought to be a quick win for terrains at least, uses a heightmap:
Would allow for some nice-looking demos!
Looks like btConvexHullShape can be automated, and probably most suited to arbitrary meshes:
This is the fastest kind of arbitrary shape. It is defined by a cloud of vertices but the shape formed is the smallest convex shape that encloses the vertices. For making a convex dynamic shape like a TV, this is ideal. Make sure to reduce the number of vertices below say 100. Reducing the number of vertices can be done automatically using the btShapeHull vertex reduction utility.April 3, 2018 at 8:55 pm #14226
Sorry, I thought you knew this!
Actually, I’m surprised you can’t even rotate MeshColliders (need to double check this but am knee deep in the guts of mx2cc right now) but I always knew that a mesh shouldn’t be moved in anyway after the simulation ‘begins’. And yes, I should add a check for this, but there’s currently no concept in mojo3d for begin/end simulation so this needs to be added too.
The problem I was talking about is best illustrated by the projectiles VR demo – if you change the ground BoxCollider to a MeshCollider (there’s a commented out MeshCollider in there) you can see stuff falling through the ground like crazy. Ditto, if you create a mesh for a terrain you get similar problems.
The TerrainCollider will be cool but it functions very much the same way as MeshCollider, although obviously it can store its data much more ffficiently. But both of these colliders really just return an intercepting bunch of triangles when simluation steps, so end result will/should be the same. I did have TerrainCollider going at one point but the anomolies were very similar to MeshCollider so I decided to ditch it for now so I can just concentrate on one thing.
I am hoping these problems are caused by triangle size and/or update ‘steps’ and I suspect making good use of a physics engine like bullet will be as much art as it is science!April 4, 2018 at 12:21 am #14227
Aw, crap, was convinced that was it! Got to be missing something somewhere, surely. Will have to try and dig up other examples from Github, online tutorials or something… gah!April 4, 2018 at 1:43 am #14228
Messing about with polys/update rate to no avail…
Easier to play about with than the VR demo at least. The cube and sphere seem to catch all boxes that drop, while the cone pretty much ignores them.
Tried both low (4) and high (256) values for cone segments, makes no difference.
One thing I noticed was that even though boxes all seem to bounce off the cube and sphere correctly, they can roll into them (or at least the cube) from the side. Wonder if it’s something to do with more vertically-aligned polys, as in it seems the sides of the cube and the entire cone are failing? (Horizontally-flipped collider ‘polys’ or something?)
Quick test: inverting the cone causes falling boxes to collide correctly with its horizontal (‘bottom’) surface…
cone_body.Rotate (180, 0, 0)
Seems something to do with vertical polys… ?
If I do this, dropped cubes can fall through the ‘sides’ of the cube (see frontmost/topmost face) — might have to re-drop a couple of times to see it:
box_body.Rotate (45, 0, 0)April 5, 2018 at 4:00 am #14250
Tweaking update rate alone probably wont do much, but there are several parameters for stepping the physics I’m not even using:
(Looking at the code now, I’m not even doing the stepping properly as it is!)
I’ll fix this and add a Scene.MaxSubSteps property so we can play with all stepping params.April 5, 2018 at 12:20 pm #14258
Cool, look forward to giving it a go!April 6, 2018 at 10:24 pm #14278
Duh, doesn’t help I broke mesh collider indicies in v1.1.10!
Fixed now which solves your demo’s problems, although the projectiles demo style ‘tunneling’ problems still exist…April 7, 2018 at 9:45 pm #14287
Just confirming the demo is working perfect now.April 8, 2018 at 1:39 am #14288
OK, this is getting pretty cool! Nice little terrain/cubes collision demo…
EDIT: Now using new TerrainCollider. See main ToyBox thread in Monkey 2 Projects forum for source.
Bit slow to start up — wonder if this might now be sped up with the aforementioned btHeightfieldTerrainShape? I’m using the MeshCollider here.
(Needs latest ‘develop’ version for anyone trying it.)April 8, 2018 at 2:11 am #14289
Hmmm, web version is acting up in chrome, boxes fall for about a second and then the page reloads!
But is working OK in nightly…April 8, 2018 at 2:13 am #14290
That actually works better than I thought it would!April 8, 2018 at 2:48 am #14291
Hmm, I’m on Firefox. I do use F5 for dropping boxes here, probably not ideal for web browsers, but assume not related from your description?
EDIT: Wait, from your description, that could well be the problem! Recommend a KeyHit edit and rebuild!April 10, 2018 at 1:26 am #14306
Updated my ToyBox thing to include new TerrainCollider-based TerrainBody, works great so far! (Above web demo updated to use this.)
[Forgot about the Chrome reloading thing — think this may just be down to my use of F5 to re-drop boxes, try amending source in Projects thread.]
You must be logged in to reply to this topic.