[Mahak]

Hi all,

Just wondering if there is any way to determine a separate invisible collision mesh within the current engine?  Just thinking it would save a heap of processing power & time on collision detection, esp. on large, detailed meshes.  The only way I can imagine is using an invisible material on a 'collision' subobject and setting the rest of the model's subobjects (barring turrets) to $no_collide...

This being said, I'm not too savvy on how the collision detection is calculated anyways, if anyone has done any work or research on this, a quick explanation would be awesome - maybe it's unnecessary, maybe the built-in calculations are efficient enough, I don't know!

M.

[FreeSpaceFreak]

This idea has been posted before; it was also pointed out that the collision detection code is still quite buggy, and that it should probably be fixed first.

http://www.hard-light.net/forums/index.php?topic=67715.msg1356875#msg1356875

[Water]

Either way, the simplified collision mesh is less likely to have holes compared to a complex mesh.

[Sushi]

As pointed out in the link FSF posted, this can indeed be done using some subobject flags in the POF file. And it does basically work.

[Bobboau]

though the BSP colision code is log(n) complexity, so the more complex the mesh the more effective it becomes

[Mahak]

Thanks for all the replies, guys.  I'll do some tests and check it out, just wanted to make sure there wasn't some super secret awesome way of doing it.  But it looks like the no_collide flag is going to be the way to go.

[Galemp]

It would be nice to use LOD1 instead of LOD0 for collision on fighters and bombers, maybe even up to cruiser size, but on larger ships it becomes significant.

[Fury]

As DaBrain has described in the topic that was linked, collision mesh should actually be slightly above actual mesh. Otherwise weapon impacts and collisions look like they go through hull. In addition a collision mesh that is just above actual mesh, could improve looks of impact effects as they would clip less with actual mesh.

So unless lower LODs are actually above LOD0, they don't work well as collision meshes.

[Mahak]

Heh, another thing I figured out, have to re-order everything so the collision draws first, otherwise you get transparent-o-ship...  Means detail0 has to be null...  urgh.  Is it just me, or does the art workflow in this engine just keep throwing surprises at you?

[DaBrain]

though the BSP colision code is log(n) complexity, so the more complex the mesh the more effective it becomes

Yeah, that really is a problem.

The collision meshes tend to have huge holes.

[Galemp]

The collision meshes tend to have huge holes.

Especially the Arcadia. Even in retail, I can fly right through it. How did that escape testing?

[Vasudan Admiral]

(The log(n) complexity is a good thing! )
The collision meshes that can affect the rendering of ships is not though. That will need to be sorted out before collision meshses are at all practical. The collision meshes shouldn't go near the rendering engine - it's like a film director putting the pizza delivery guy in his scene as an actor or something.

[Water]

Heh, another thing I figured out, have to re-order everything so the collision draws first, otherwise you get transparent-o-ship...  Means detail0 has to be null...  urgh.  Is it just me, or does the art workflow in this engine just keep throwing surprises at you?

Try this.
Create the collision mesh. Keep the mesh closed, this will help towards eliminating holes. UV map it and assign invisible.tga to it. PCS2 and FSO don't actually need the invisible texture but it tells the engine that the object is not viewable. The collision mesh is 590 polys and I haven't yet done any testing to see if less polys make any visual difference to the hits.
Model and texture by Wildcard

The next part is PCS2. Lod 0 is about 5k vs 590 polys in the collision mesh.

Set the properties of detail0 and its sub-objects to $nocollide_this_only
This disables collision on each of the meshes.

Next the collision mesh is set to $collide_invisible
Normally objects with an invisible texture can't be collided with. This reverses that.


As you can see in PCS the collision mesh hides the model, but Freespace shows only the ship.

Looking at detail0's wireframe you can see the collision mesh around the model.

[Scooby_Doo]

Your basically wrapping lod 0 with an invisible mesh?  How well does the engine handle this?  I know shields this would be catastrophic.

[Mahak]

Oh right, if you use the proper invisible.tga the engine knows to ignore it yeah?  I just made my own invisible texture (just value of 0 on the alpha channel of a .dds)  This makes a lot more sense...  Also means I don't have to have dummy objects to fool the heirachy...

Thanks for all the effort Water (screens etc.) - I have to say this forum community is one of the most supportive out there...

M.

[The E]

The engine will just ignore textures named "invisible".

Note that the name HAS to be "invisible", WITHOUT the file extension, in PCS2's texture list.

[redsniper]

what if you have "no collide invisible" on?

[The E]

"no collide invisible" is the entire reason for that hack involving the "invisible" texture. Take a look at the spacesuit in BP:AoA DC in the F3 lab. Then switch to wireframe rendering. See what we did there?

Without "no collide invisible", invisible meshes are treated like normal for the collision detection. With it, collision detection is skipped for those meshes.

[Sushi]

I thought the engine only used LOD0 for collision detection, so it doesn't make sense to have a collision model for LOD1 or beyond. But I could be wrong on that.

[Vasudan Admiral]

Ah the 'invisible' texture - superb idea water.
In fact I think I'll construct all future ships I make like that. Kudos to Sushi and whoever else played a part in implementing those collision flags.