Additional primitive collision shapes for c_move/c_trace

I think it'd be very useful to be able to use non-ellipsoid collision shapes without having to use PhysX. As nice as PhysX is, its license means I'm not inclined to use it unless I actually want proper physics simulation (which is yet to be the case).

Capsules and cylinders, for example, would both be more suitable for humanoid actor movement than ellipsoids, with the latter having many other applications (wheels, barrels, flying discs, etc). And an oriented box would be useful in many cases as well -- for doors, crates, and other props that may be moved around the environment without need for proper physics simulation.

It'd be really cool if each entity had a collision mode where we could choose if it's a capsule, cylinder, box or ellipsoid, the parameters of which could be manipulated using max_x/min_x, and if c_trace with USE_BOX could use these shapes as well

Thanks for reading,

Jibb

I'm not sure, but maybe the PhysX-based collision system on forecast will do that

I can't see it on the forecast page.

Jibb

lol you are right, it has been removed recently

Yes, it WAS there !???

I remember it being there once, but I'm personally not bothered by its absence -- I don't want to have to show a PhysX logo just so I have more collision detection options.

Jibb

I can see cylinders as being a good alternative to boxes, since you can still stretch and pull cylinders vertically without disrupting the surface normals of the sides.

...and still get a nice flat surface underneath (even if you are hovering above the ground with c_trace and USE_BOX) so the actors don't slide down as they step off ledges.

To me, it's the perfect bounding box for actors.

Jibb

Yes, cylinders would be great (BB for actors and enemys)

Cylinders were used in the unreal engine (for example)
Link

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?

That was removed from the Forecast.

How many more examples do you need, though? Haven't we made it clear that ellipsoids do not serve our purposes or give us the behavior we want? We don't want objects to "climb" things when the edge of their collision hull hits them, and we don't want objects to "slide off" of platforms when they get close to the edge. We don't want the "USE_BOX" flag to behave like a "USE_ORB" flag.

I've already given you the example with the window in the "AABB support" thread, and Superku has already demonstrated his problem with a multitude of images and examples. For my problem, your solution was to place an invisible block over the hole, but that's more of a quick fix than a real solution to the problem. The collision system is still prone to errors like that.

We want to be able to use collision hulls with perfectly flat bottoms and perfectly vertical sides that match the vertical depth of the model that the hull is attached to, because that's exactly what we need.

Indeed it seems really strange that AABB was a "feature" once in the pro version and now it´s completely gone.
I would like to have again the possibility to switch between ellipsoid and box.

If a company has its customers demanding new collision shapes, its your responsibility to provide for the customers needs. I looked at the examples posted in this thread as well as the other one (forgot what it was called), and I have not had ANY trouble understanding their argument. So where is the problem? I understand that adding new collision shaped may be troublesome and require proper testing. But isnt that what this community is for? Release a few betas and let us test it. Thats what you have done in the past and that system works. You guys sure didnt have a problem migrating to Lite-C in a rather speedy matter I say we should get a poll going to see exactly where tis community stands.

The fact that this issue keeps popping up is a testament in and of itself to how much people really want it. We need this feature, what more is there to say?

Trying to argue for an issue like this is like trying to argue why a hammer is the optimal tool for beating down nails.

A hammer? Well that'd work much better than using our foreheads!

Jibb

What i don't understand is why in forecast there is lot more complicated things like :
Cloth simulation. Liquids. Soft bodies.
Instead of more simpler things like new collision primitives ?

I htink the best way is to implement yourself the Nvidia Physix collision shapes you need !
You'll nerver be as well served as by yourselves

What would be cool is tyhe advanced character controller :
Nvidia features page

But again if you are a programmer, i would want to say :
make it by yourself if the feature is not in forecast
or if you don't want to wait months too longer


It's a rule , that follow some people using Ogre 3D, tehy have the graphic engine, they implement the physic API they want and the features they want, and finnaly they make the game successfully !

Asking for something is useless, thats what I got from this thread!
jcl only implements what he likes, doesn't give a damn thing about us...
This is second time when he proves my point by ignoring everyones needs!
About PhysX, I wish some day I could make something similar to this:
Youtube link
But for now, this will be really pain in my ass to make something similar..

PhysX collision shapes are supported since almost a year - just look in the manual. I think I can now safely close this discussion.