Concave Trace Models (for moveables) Allowed?

[Ishtvan]

Just found some Id documentation that I never saw before

 

from /src/idlib/geometry/tracemodel.h

A trace model is an arbitrary polygonal model which is used by the

collision detection system to find collisions, contacts or the contents

of a volume. For collision detection speed reasons the number of vertices

and edges are limited. The trace model can have any shape. However convex

models are usually preferred.

 

Apparently they can be concave. I think this also means moveable clipmodels can be concave, because the requirement on a moveable clipmodel is that it must be a tracemodel. Are we sure that there wasn't some other problem when we tried concave moveables, like bad friction/bouncyness settings or starting out clipping into something?

[Springheel]

We've already used some concave cms successfully. I'm pretty sure we posted that exact quote in another thread.

 

http://forums.thedarkmod.com/index.php?s=&am...st&p=137162

[Baddcog]

I haven't seen that info yet. That explains why the teapot collision works then. it is very concave but stable.

 

Are the limits set in stone or can we change them. There are certian objects I'd like a better collision for like the tea tray even if it meant a little more processing. It wouldn't take much more but as it is the collision models are very limiting. I'm certianly not suggesting we go overboard but a few more polys/verts for some stuff would be nice. I have pushed some weird shapes through for this but they are very unstable and usually end with SHAS or the tray landing on the ceiling.

[Ishtvan]

The limits are exposed to changing in that tracemodel file, and we have both the header file and implementation. I'm not sure if anything else that is not in the SDK depends on those limits, though (like CollisionModelManager). We could try changing them and finding out what happens.

[greebo]

It think that's the same comment snippet I posted in the other convex vs. concave discussion two month back or so. The limits cannot be changed, if I read the code correctly. I was looking at the leaked collisionmodelmanager code and it was storing the vertex / edge indices into bits of an unsigned integer (that's why the limits are bound to 16 and 32). Presumably the code performs bitwise AND operations for performance reasons.