easy fix. a invisible box scaled to the min/max values of the model to use for collision. lol.

I think, it could be 100 times better if OBB could be completely changed with physX collusion system.
But the thing is, that we still could use "C_" functions (c_move and so on), and without physics forces.
Plus additional mode to change BBOX's shapes, like box, ellipsoid, cylinder and so on...
The only thing is, that I think it's impossible... for two reasons:
* first cause I don't know how to implement that and is that even possible...
* second reason (the main one) is JCL

With the c_trace function you're able to do any collision system you can imagine on your own. So you've got the engines ellispoid collision system, the PhysX collision system plus the ability to implement any system you like. If you use PhysX you've got a complete physics simulation system, taking away a lot of these time consuming and complex tasks for you. Hence the level of control you have is reduced by this system. This is not a flaw but a necessary consequence of the system design.

Under the line you still have all possibilities to realize any collision you like. And I highly recommend not to see JCL as a problem. He is a very clever and intelligent person and he succeded to adapting this engine from the 90s up to today. That includes doing some pretty hard decisions and even choosing which feature to implement and which feature to abandon.

Initially this is true but I just made a little physics game in Unity and they take care of that. The quaternion class has a slerp member (spherical linear interpretation) that basically does an interpolation to smooth the movement over time. It works and you get rid of the jittering. There are also parameters to influence the smoothness.

Most of the time I don't want a full-blown physics simulation. I just want to move, stop when I hit something, and get the kinda information c_move gives me (normal, point of impact, who I hit).

Even if between some constraints and the like I could do it, I doubt it would be as efficient as a function dedicated to just collision detection.

Finally, c_trace with USE_BOX is a huge part of the issue, and AFAIK PhysX doesn't offer an equivalent function (I'd love to be corrected).

KarBOOM doesn't use any of the c_ or PhysX functions, and I can't see projects of mine in the near future using PhysX or any of the c_ functions, because I'd rather write my own if c_ doesn't pick up the pace.

Jibb

Well complicated !

Unity ,Shiva and some others uses physic engine, i've tried the demos and all runs really fine.
If you need very specific collision, you'll have to do it yourself; but for most cases : FPS, Car , the physic engines
goes well even on AAA games published !

So i htink it's ot each people to call the good Physix function
and adapt them to their A8 project !

Or switch engine or library if anything goes well ?
I don't know !
But for me i'll try to use Physix on my 3DGS sandbox tests !

Then I'm pretty glad I can do you favor. :-) You can use pXent_raycast for that purpose.

I actually think that it is common to use a physics engine and optimized collision geometry for everything. Especially for bigger productions than hobby projects.
I btw don´t see a big difference between a "full-blown physics simulation" and continuous collision detection including glide flag.

Last time I checked c_trace with use_box it worked just fine. If it really does return messed up normals, you should probably post it in the bug hunt?

I appreciate it, but USE_BOX is the main thing missing, and as far as I can tell that function is just a ray.
The problem is the normal returned is not the normal of the surface; it's the normal of the projected ellipsoid colliding with that surface. This is normally fine, except when we encounter an edge. Consider stairs: the normal returned by a c_trace without USE_BOX would be (1, 0, 0) or (0, 0, 1). Now try again with USE_BOX, where the box is bigger than a single stair, and you'll get a sloped normal (like (0.7, 0, 0.7)).

USE_BOX is great for a collision detection (that normal is ideal for ellipsoid collision detection), but really annoying when you actually care about the normal.

Jibb

you can also try USE_POLYGON on c_trace