[SOLVED] POLYGON flag with weird results

A lazy Sunday to ye all,

And the next question. For certain parts I'd like to have polygonal collision detection. I assign to certain models the following code:



The results are strange. Basically all three models show the BB assigned by the engine, two of which are totally useless. I also noted, that in MED the center of the correctly hulled model is sitting differently from the centers of the incorrect models (all illustrated in the pic in the Spoiler.)

I know, I can use code like that:



But a) I want the polygonal detection and b) it is very odd and I should be able to address it. What's wrong with our models? (We use 3DS Max 5.1 for modelling and export / import via FBX).



EDIT/ Problem solved thanks to Superku and Uhrwerk, see last post.

When you press F11 twice you'll always see the bounding box. Seeing a bounding box does not mean that the entity does not have the POLYGON flag set. So you cannot jump to conclusion from that. Are you experiencing trouble with the collision detection?

Your action BBRail01short is most likely not doing what you expect it to do. Letting the engine automatically determine the hull of an entity and then overwriting these values by hand seems not useful to me.

I'd also recommend setting the entities center always inside it's bounds, mostly centered.

Solved the problem myself, i.e. wasn't one. The ColDet works, though the BB is shown incorrectly not as I would have expected.

Sorry for bothering you.

If the bounding box is shown incorrectly this is a bug and should be reported. But how do you get the idea it is shown incorrectly?

Upps, seconds to late. Thanks for your trouble. I, too, would assume, centering the centre kind of seems logical. Don't know what the modeller thought by off-centering the headpiece...



Well, I meant setting min und max as a workaround of POLYGONAL fails, not as an addition to it.



Not sure if it's a bug, since I don't know the exact workings of the engine yet. But check the pic in the OP. The BBs are plainly off in size. POLYGON was set. Would you say it's a bug? I can't decide and don't want to bother the devs with dumb stuff of mine.

And although these weird boxes show up, the ColDet works polygonal.

As always - thanks for quick and useful replies.

You're mixing up two concepts. An entity always has a bounding box - regardless of the POLYGON flag. This bounding box is determined by the min_x ... max_z members. The POLYGON flag just tells the engine to ignore the bounding box when doing collision detection, but does not remove it. Setting d3d_lines to a value > 1 (This is exactly what happens when you press F11 twice) will draw the bounding box regardless of the polygon flag.

At a first glance you might think that this is irritating and senseless but you can use the bounding box for other purposes as well, e.g. to emit particles inside a predefined cube etc. Even entities with the PASSABLE flag set can use their bounding boxes.

As a little addition to Uhrwerk's words, in A7 (at least 3 years ago but I don't think this has changed) the collision detection on big models could fail with the POLYGON flag set with the small default bounding box. I once had a platform, sth like 768-1024 quants long (player height = 90 quants), where the player could fall through the right 3rd of the entity, until jcl explained to me that I would have to adjust the bounding box (i.e. call c_setminmax) of the entity too.
I assume the collision engine works like this that it grabs the non-passable entities from the/ a (ABT?) tree, checks for possible bounding box-box collisions with a little buffer and only then executes box-polygonal collision detection.

So basically what I was trying to achieve with my workaround...



Aaah. Concept understood, thanks. All right, then just to learn: How does the engine compute th BB? Those in the pic (and others) are way off in their dimensions.

It does not compute them. There are default values for these. See the manual: http://www.conitec.net/beta/aentity-min_x.htm

When you call c_updatehull the engine iterates over all vertices and if they lay outside the current bounds the bounds are updated to include the current one. But that is just a guess!

Did you call c_updatehull for them without writing to min_x ... max_z afterwards?

You did understand that you have to use both commands, right? Like
set(my,POLYGON);
c_setminmax(my);

Btw. if you are using A6 I think you have to wait one frame before calling c_setminmax because otherwise the values get overwritten in the first frame after creation, i.e. change

c_setminmax(my);
wait(1);
vec_set(my.min_x,vector(-22,-5,-20));
...
to

wait(1);
c_setminmax(my);
vec_set(my.min_x,vector(-22,-5,-20));

Wow. Though I feel a bit dumb, it was good learning today. I better understand several things now. I attached a screen with a fairly large grille-model. Models like that need to be set to POLYGON, since I need to pass them. For all other things I use hulls, but let them calculate via c_updatehull. So, for dummies like me (I can't be the first to run into that wall):



And thanks all.

No need to feel dumb. Anybody who knows this stuff once didn't know it and hat to learn it the same way you do it right now, right?

These lines are equivalent. set is just a macro that is defined in acknex.h as follows:so thatis replaced by the precompiler to

Are you sure that you have to use
c_updatehull(my,1);
? That would be quite surprising. Try to replace the instruction with c_setminmax(my); and keep the wait(1) before it.