Every new collision shape requires a lengthy implementation and test. Thus we can't implement an arbitrary number of collision shapes, but only one, if at all.

Therefore I would like to learn about a particular situation in your project where a different collision shape is needed, and the reason why an ellipsoid or a PhysX capsule can not be used in this situation. Dependent on this we'll think about if and which collision shape to implement. At the moment I see no real reason for more collision shapes.

If you look at the platformer games, they work better with
a flat collision Hull on the floor.
So the units dont fall off the cliff unexpectitly, but
exactly when the Cliff-Hull and Entity-Hull dont match anymore.
With elipsoid Hulls, the entity probably slide down when getting close to the edge.

I saw this behavior in "SuperUli" here. Where I suppose the elipsoid hull was the reason for unexpectantly sliding off edges.
(Though I dont know how the code is setup in this situation)


In this case a Cylinder would be the best compromise,
to have both less "stucking" in the horizontal direction, and
a very specified collision in the vertical direction.

So these cylinders can be used for platformers, and "firstperson
movement" alike.

is it really necessary to show the physx logo if you use physx? i didn't know that...



jcl, you wouldn't have to implement it yourself from scratch.

at the moment the ellipsoid system uses the open source OPCODE library as far as i know? that's outdated...

the new state of the art open source collision libraries are newton and bullet. you could use one of them instead. their convex hull systems are even better than what physx has to offer. they both use the very liberal zlib license now and their collision systems can be used independently from their physics systems.

(but if you are at it you could implement their physics aswell since it makes a lot of sense if only one collision system gets used for everything.)

I've tried to describe that problem in the AABB-thread:

"The first screen uses a faked box-trace that achieves the desired effect/ movement, the second horizontal line demonstrates the problem with OBB-USE_BOX-(gravity) trace:

(Ignore the bright blue box, the dark blue box is the bounding box.)"

A box-trace would help here.

That's interesting. I would've thought you'd use the Gilbert-Johnson-Keerthi algorithm for collision detection, in which case supporting a new type of convex hull that's compatible with all other collision shapes would simply be a matter of writing a new support function for that type of hull.

As others have said, I think a cylindrical hull (as well as support by c_trace with USE_BOX) would by the most advantageous addition for us programmers if you can really only do one.

Jibb

A flat bottom hull trace is often required, not only for platformers. A flat hull is just a special case of an ellipsoid. You can easily make the hull a flat disk by setting min_z and max_z tight together.

Yes, but then the collision hull has no vertical depth (and still isn't perfectly flat on the bottom). We need the collision hull to have a flat bottom/top and perfectly vertical sides that match the vertical size of the model.

which brings back the solution of a cylinder...

Again, I need an example where a cylinder is really required. Superku gave a valid example, but this already works with the current system.

i thought all problems would go away when c_trace/c_move stuff started using physx for collision dedection?