Mask explanation

#1 @ Norm:

Unfortunately as you may have already guessed by now, not everyone is very well acquainted with the Torque Collision system, and you may be complete right in your assumption that original writer of this code has been long gone...

I did look at the code in question, and I would wager a guess that the front and back masks refer to vertices considered in front or behind the plane in question. The crossMask is the AND of the two bits - so it's only set if both bits are on - and going along with my hypothesis, I would assume that the crossMask means the that the point pretty much lies on the plane.

Of course these are all best guesses - and I doubt many (if at all anyone) has decided to give this piece of code a long analysis. It's an extruding poly list class. An object will give it it's polyList, and the extruding poly list will only include polys that have been extruded according to parameters set up in it's extrude method. It does what it does well as far as anyone can tell, so why bother trying to tinker with it? If you're trying to understand the collision system in general you'd be better off searching TDN / forums for collision questions or if you have a more specific question about what you're trying to accomplish, maybe more people can help.

- Eric

#2 Eric,

Thanks for the reply.

I agree with your view of what the various masks represent but don't understand how the mask bits correlate with specific vertices or why the algorithm works.

My application involves a model of a steer which is supposed to be "herded" into a corral by the player.
Frequently, the steer simply walked through the fence instead of colliding with it and stopping.

I traced the problem to the area I referenced in my original posting.
I never did figure out why this happened but did come up with a work around by playing with the dimensions of the steer's bounding box.

I'm not comfortable with solving problems without understanding why the solution works.

Regards,

Norm

#3 Norm,

Well there are a number of things that could be causing this issue other than the extudedPolyList. It's true that at the end it decided whether or not there's poly's to be collided with, I'd be a little more concerned with how it's used rather than it's inner workings.

Did you make a call to it's ExtrudedPolyList::extude() method before you did your subsequent calls to getPolyList on the object's convexes?

Also note when you do set up this ExtrudedPolyList you also provide a polyhedron to define the area in which you want to extrude from. As far as I can tell, most of the time it's just a box.

Are you updating the working collision set before you run through the list of possible convexes?

How are you're fences representing themselves in terms of collision? When you call getPolyList on their convex, is it returning it's entire list of polys - or a smaller bounding box than you expect? A TSStatic (less accurate)? An interior (more accurate)?

- Eric

#4 Eric,

I am using, as a code base, the stock player.cs code in the starter.fps kit.

I have added a lot of debgging monitor code but for the most part, the player collision related code is unchanged. At a glance, I would say that the answer to each of your questions is "yes".

The fence collision boxes are returning dimensions that encompass their true shapes.

However, the collision box for the the steer, initially, encompassed only its front legs and chest, despite the fact that the bounding box in the DTS file encompasses the entire animal.

I expanded the datablock boxSize to work around the problem.
Its size dimensions were critical.
For the right dimensions, the animal stopped just short of the fence (not part way through it).

Why I had to do this, I don't know.

Thanks again for your help.

Norm

#5 Norm,

IIRC, the player uses a custom box, just like you discovered, whose dimensions are specified by boxSize. AFAIK it's the ONLY object to do so.

Although it's the most intuitive place to take your collision code from - you need to be aware that the player does indeed use boxSize as it's box for collision purposes IIRC. So if you're using a direct copy of the player's collision code - then you need to (as you've already done) adjust the box size manually. It's not a hack, but it's not necessarily what you want (from what I gather).

That should explain why no matter what your collision mesh is on your steed - it doesn't make a difference because it's boxSize that determines it.

The following code (found in Player::onNewDataBlock) does the trick

mObjBox.max.x = mDataBlock->boxSize.x * 0.5;
   mObjBox.max.y = mDataBlock->boxSize.y * 0.5;
   mObjBox.max.z = mDataBlock->boxSize.z;
   mObjBox.min.x = -mObjBox.max.x;
   mObjBox.min.y = -mObjBox.max.y;
   mObjBox.min.z = 0;

   // Setup the box for our convex object...
   mObjBox.getCenter(&mConvex.mCenter);
   mConvex.mSize.x = mObjBox.len_x() / 2.0;
   mConvex.mSize.y = mObjBox.len_y() / 2.0;
   mConvex.mSize.z = mObjBox.len_z() / 2.0;

Where mConvex is probably a BoxConvex, set up to proportions you set up by the datablock.

How exactly you want to represent your collision is up to and a fair bit of research. But hopefully this explains your problem.

- Eric

#6 Great thread you guys; thanks.

#7 Eric and Orion,

I should note that my modification of boxSize was done in Player::onNewDataBlock) and was made conditional based on whether the current object was the player or the steer.

Norm