Collision shapes for complex worlds

[Spek]

Question in short; what is a good way to generate collision shape(s) for static world geometry? Typically this world is made of corridors and such, but also more advanced surfaces appear (curvy pipes, spiral stairs, bumpy floors, organic shapes, ...).


Now in detail. I've been using CollisionTrees (thus per triangle) for quite a long time in Newton 2.x. because:
A- You can make up any shape
B- Its easy; when importing a world from an OBJ file for example, you can just copy the same mesh and use it for physics. No need to hand-make a world out of primitives.


BUT... I had several issues:
A- It's static of course. No problem most of the time, but some parts of the world are candidate for changes. Moving platforms, destroyable walls, bridges that can open/close, et cetera.

B- You don't always want every polygon of the visual world to collide. Small * on the floor (loose pave tiles, junk) would slow me down or even get me stuck sometimes!

C- Its probably not the most efficient way, memory and performance wise. Very often complicated pieces of the map can be simplified to just a OBB or cylinder (but not always!!). Also, the visual mesh contains a lot of parts I will simply never reach (details on the ceiling?).

D- Stairs are horrible. I've implemented some hacks such as forward scans to determine if there is a passable obstacle in front. Ifso, some magic force would lift me up. But the detection doesn't always work well in case a lot of detail and other junk is in my way. Often I would get stuck or had to take a sprint in order to get me up the stair.

E- The worst issue was stuff falling through the walls or floor. Don't know why it happens, but it happens. My player (just a cylinder really) doesn't seem to have this problem, but small stuff -in my case often compounds of one or more convex hulls- would fall through the CollisionTree or act weird. Bugs in either my code or Newton 2.x, lower framerates, small stuff missing triangles, ... I don't know, but it just didn't feel very stabile.



Right. I'm redoing things (going to Newton 3 for example), so that gives a chance to rethink. My guess is that a physics engine prefers primitives to work with. And yeah, using the NewtonMeshCalculateOOBB( ) function, I can generate OBB's (automatically) to cover up my world.

But before going that route, I want to make sure if its necessary. Because it will give the mappers some more work, and some shapes just don't lend themselves for boxes or other primitives. Spiral stairs, a hollow sewer pipe, a bumpy terrain, ...

I'm sure some of you guys used Newton in more advanced worlds. So, how did you deal with world-collisions?

Ciao!

[Julio Jerez]

you can use a scene collision, and populate the scene collision with any sub-collision you want.

collision scene are cool because you can add multiple collision trees as sub shapes, plus you can add other collision shapes as well like heightfield or any primitive.
each sub collision has a matrix you can use to move the shape


also next time you get these kind of problems, you can ask questions here.

E- The worst issue was stuff falling through the walls or floor. Don't know why it happens, but it happens. My player (just a cylinder really) doesn't seem to have this problem, but small stuff -in my case often compounds of one or more convex hulls- would fall through the CollisionTree or act weird. Bugs in either my code or Newton 2.x, lower framerates, small stuff missing triangles, ... I don't know, but it just didn't feel very stabile.
Ciao!

[Spek]

Didn't use a SceneCollision so far, it has been a while since I touched the Newton SDK

Previously I used multiple CollisionTrees (each "Room" would have one), and as the game is roaming, old collisionTrees would be removed and new ones added on the fly as the player moves.

Anyhow, what is the extra value when using a SceneCollision as a container that holds my "static" scene stuff?

Second, should I try to avoid/replace CollisionTrees with primitives whenever possible, or shouldn't it matter really, in terms of stability & player navigation (performance wasn't a real issue so far).

Third, does it really matter how many collisiontrees I'll be using. Previously each room would be 1 collisionTree, but now I'm thinking to create either a primitive or a collisiontree for each sub-part of a room (floor, wall1, wall2, wall3, ceiling, ...) so I can easily change/move/adjust individual parts.


I'm trying to get a good understanding of what works and what doesn't, as this affects the mapping editor and parts of the artist workflow. So I'd better don't make false assumptions or stupid choices :p

[Julio Jerez]

the scene collision is a container for other collision.
this prevent the creation of a full body just to add a static collision to the world.

if you want to add a building made out of rooms, and each room is a collision tree, using collision tree, this means one body per collision. This increases memory, collision time and solver time.

Using a scene collision and adding the collision trees to it, save lot of CPU time in the solver and memory, the collision time is the same.
you can see the scene collision as a way to partition yor world and a course resolution.

Collision tree are better for modeling complex mesh, I would use that, but that is the beauty of scene collision, it let you add any kind of other primitives to it (wit the exception of other collision tree)

[Spek]

All right, sounds logical.

I'm not far enough to do some quick testing, but I'll keep using CollisionTrees then. Eventually an option to toggle between either a collisionTree or an OBB per map object. Many walls and floors will do fine with just a OBB.

Not sure what to do with stairs yet. Lot's of triangles in a narrow space (think of a spiral stair with gaps and railings) will make scanning the environment difficult, in order to add some (up/down) forces to help climbing.


As for stuff falling through the floor, are there known issues for the combi between Convex-hull Compounds / CollisionTrees / Lower framerates / Newton 2.x (maybe something was fixed in 3.x?)?

[JoeJ]

As for stuff falling through the floor

Mostly this is caused by bad polygon models: Bad vertex winding order, zero length edges, nonplanar polys, double sided polys, etc...
I don't know which of those things can affect Newton, but usually output from 3d modelling tools is not suited for physics engines without some cleaning.

The other reason is for small, fast moving objects you need to enable continuous collision to prevent them from tunneling through walls.

For player controller a capsule may be less problematic than a cylinder (no corners).
For scanning you can not only use rays, but also spheres, capsules or convex polyhedra with newton.
This may be good to be sure not to miss stuff like railings (if necessary at all).

[Spek]

Thanks guys

Bad polygons sounds logical, though I doubt it. Bad winding, line-shaped, or zero-sized shapes would be noticed instantly. By my eyes, as the shaders don't like them either Plus I think I can safely say I make "clean" models. A floor really just is a floor for example made of connected(welded) upwards facing triangles. No double sided stuff or gaps. And even if there would be a tiny hole (talking about millimeters then) an object shouldn't fall through right?


High speed doesn't seem to be a likely cause. Though objects are often pretty small indeed ( say a brick or bottle), and moreover, the framerate back then would sometimes be ~15 only or something. The drawing-framerate that is (if I set NewtonSetMinimumFrameRate( 60 ), does Newton really run 60 FPS then?). Can't remember if ContinousMode gave different results...


Thinking of it, I always wondered if I construct my compounds well:
- An array of newtoncollisions is made (convex hulls in my case)
- A compoundCollision is made, and each subCollision is added
- The *SAME* array of subcollisions will be re-used for other instances of the same object
Now I'm not sure about the latter... If I create 10 couches, all 10 share the same sub-collisions (but unique compound collisions though).

[Julio Jerez]

please try again with 3.13
if you get a problem you can save the scene and load it in the demo sand box, then there posible to debug it and see what is wrong.

[Spek]

Using Delphi, so trying it in the Sandbox is gonna be a bit difficult. But I'll just try with the latest Newton and see what happens. Almost got some basic physics implemented back into the engine, but it probably takes a bit longer to play with more advanced situations.

New Newton, new engine, SceneCollision, better framerates, splitting the world up in smaller chunks & using OBBs if possible, and last but not least, fresh knowledge... that all together might make the difference !

Thanks for helping guys

[Julio Jerez]

there is a function that can serialize your world to a file, then it can be loaded in the sandbox demo