A Question On Collision Boxes

[SneaksieDave]

I wasn't sure if this should be in modelling or programming, but modelling seemed closer. Taken from the 'Weather Effects' thread, with regard to the rain.map.

 

Right, the same happens to me, reproducably. Collision box problem with the red book I think. I'm not going to derail this thread, but making this scene showed me we have quite a few origin and box problems with some items.

 

Btw for those clipping box problems, you know you can type "g_showcollisionmodels 1" in the console and see them, right?

 

First concern: Wow, should our collision models be *that* complex? They're pretty much accurate to the poly, it looks like. Isn't that very expensive? By contrast, AI show rather simplistic models. Why does a func_static endtable need a 300 poly model, when the AI don't even have that? See the first image. Why would a cup need that much collision detail? It only needs a rect around it.

 

Second concern: Anyway, I don't see anything wrong with the book, so I don't know why the problem, and I'm probably using the wrong word anyway. The origins are not aligned with the grid in many cases - that's what I mean. A book will hover 1cm above the table, because it can't be set *on* the table, in other words (in part due to the D3Ed grid size less than 1 acts wacky bug). Many things, like books, vases, tables, etc., don't share common-grid surfaces. So placing them in contact with each other doesn't work too well. See second image. Two books on a table (rain.map), grid size set to 1, and all three objects are floating in the air.

[Springheel]

Wow, should our collision models be *that* complex? They're pretty much accurate to the poly, it looks like. Isn't that very expensive? By contrast, AI show rather simplistic models.

 

I suspect it's because collision models haven't been made for most of our models, and when D3 has to make one on the fly it just uses the original mesh. Eventually we will have to make simplified collision models, but I think that's primarily an optimization issue (though I could be wrong).

 

 

placing them in contact with each other doesn't work too well.

 

I've noticed that problem too. But how would that cause the player to get stuck? And shouldn't the objects 'fall' down onto the table at map start-up?

[OrbWeaver]

I never really understood collision models, in my view you should just be able to create a model in your 3D app along with the actual mesh, and use it as the collision model - however when I made a mover I had to muck around with drawing brushes and exporting or something like that before the mover would respond properly.

[SneaksieDave]

But how would that cause the player to get stuck? And shouldn't the objects 'fall' down onto the table at map start-up?

 

It's not so much that that's the cause of the player getting stuck (though it could be); just that it looks bad when everything's floating around.

 

They won't fall unless they're moveable with physics.

[Dram]

AFAIK the collision model for statics is the original mesh because they're statics. In other words, ALL models by ID are pretty much like that (static meshes of course).

[Ishtvan]

I think our first priority for collision models (CMs) should be moveables. Moveables require a .cm in the model, and there is some limit like 16 faces. You might also be able to set it up as a box with the "mins" and "maxs" keywords in the entity def. We need this for a lot of reasons, mainly so we can start testing more custom moveables, assigning mass and density to them, etc. We have all these models for them, but no CMs, so they don't actually work as moveables. Once that is done and more things are made into moveables, we should see less "hovering" problems because they'll fall down to be flush with the surface.

 

@OrbWeaver: Yeah it is pretty confusing, different entity classes handle CMs differently. For some of them it's as simple as setting "mins" and "maxs" in the editor to generate a box, for others I guess you have to export and stuff.

 

Springheel is right that statics use the model as the collision model by default. It seems to perform okay, possibly because you're never moving the static, just seeing if other things collide with it, whereas with a moveable, you're checking to see both if it collides with anything and if anything collides with it.

 

You can put in a simplified CM for a static, just add it directly into the same model file, and texture it with common/collision (or it might be common/clip, I forget which). It seems to run okay as-is, although BT reported getting some performance increase, especially when AI were navigating around it, when adding in simplified ones. You can also put in a simplified clip box for AI (common/monsterclip or something), but not for physics, so the AI will see the chair cm as a box and not eat up CPU time navigating it, but physics will still collide exactly.

[SneaksieDave]

Ishtvan, in case you didn't see this: http://forums.thedarkmod.com/index.php?showtopic=3965&hl=

[OrbWeaver]

The monster clip is especially important, this should be used everywhere it can. Basically anywhere a monster cannot go can be sectioned off by adding a brush textured with the appropriate clip texture to remove the geometry from the AAS.

 

This includes, for example, putting a clip "wall" over a mesh or patch fence which the AI cannot get past.

[Ishtvan]

The monster clip is especially important, this should be used everywhere it can. Basically anywhere a monster cannot go can be sectioned off by adding a brush textured with the appropriate clip texture to remove the geometry from the AAS.

 

This includes, for example, putting a clip "wall" over a mesh or patch fence which the AI cannot get past.

 

I agree. If I recall correctly, BlackThief has tried this and reported noticable performance increase in maps with AI when doing this.

[SneaksieDave]

I wonder if he meant playing, or compiling (calculating the AAS). Because the latter is a HORRIBLE time pirate when a map starts getting big. I've seen a map that can BSP in seconds take so long to AAS that I gave up and killed the process.