Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: Mahak on May 04, 2010, 08:57:40 pm
-
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.
-
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
-
Either way, the simplified collision mesh is less likely to have holes compared to a complex mesh.
-
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.
-
though the BSP colision code is log(n) complexity, so the more complex the mesh the more effective it becomes
-
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.
-
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.
-
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.
-
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?
-
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. :(
-
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?
-
(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. :p
-
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
(http://i229.photobucket.com/albums/ee67/waternz/other/Collision-mesh.jpg)
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.
(http://i229.photobucket.com/albums/ee67/waternz/other/Collision-PCSa.jpg)
As you can see in PCS the collision mesh hides the model, but Freespace shows only the ship.
(http://i229.photobucket.com/albums/ee67/waternz/other/Collision-FS0-B.jpg)
Looking at detail0's wireframe you can see the collision mesh around the model.
(http://i229.photobucket.com/albums/ee67/waternz/other/Collision-FS0-A.jpg)
-
Your basically wrapping lod 0 with an invisible mesh? How well does the engine handle this? I know shields this would be catastrophic.
-
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 engine will just ignore textures named "invisible".
Note that the name HAS to be "invisible", WITHOUT the file extension, in PCS2's texture list.
-
what if you have "no collide invisible" on?
-
"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.
-
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.
-
Ah the 'invisible' texture - superb idea water. :D
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. :)
-
Thanks for all the effort Water (screens etc.) - I have to say this forum community is one of the most supportive out there...
You're welcome.
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.
You are right. Re edited the post to remove any references to detail1.
Kudos to Sushi and whoever else played a part in implementing those collision flags. :)
Agreed ;)
-
pretty clever. now tweak all the mod tools to do this automatically :D
still waiting on some scientifically generated performance data
-
Use <ctime> ?
:nervous:
-
Best results would probably come from a very complicated ship using a very simple collision mesh, if you really want to get an idea of the results.
-
I know DaBrain did some tests with an asteroid model that showed a pretty dramatic improvement.
-
Even just the difference when saving out the .pof from pcs2 can be drastic - it obviously doesn't have to generate the collision detection data from the high detail model in lod0 if you use the $nocollide_this_only flag... Nice.
Still waiting for a working collada version of PCS2 - I have a build that works, for some reason the latest stable release has something wrong with it, doesn't recognise multiple materials on an object (the previous, unstable release works - just crashes after saving out a .pof - I'm not complaining though, it's still better than using truespace!!!)
-
When you say "closed mesh" does the entire thing have to be one closed piece or can there be multiple closed pieces overlapping?
-
When you say "closed mesh" does the entire thing have to be one closed piece or can there be multiple closed pieces overlapping?
The only rule that matters - does it have any collision detection problems? You know the sort of stuff FS can handle, just use that to create a simpler version.
-
When you say "closed mesh" does the entire thing have to be one closed piece or can there be multiple closed pieces overlapping?
The only rule that matters - does it have any collision detection problems? You know the sort of stuff FS can handle, just use that to create a simpler version.
LOL I dunno... that was why I was asking you :P
-
also someone sticky this, i dont want to see it fall into the void of forgotten posts.
-
Could using a collision mesh cause problems with shields in-game?
The TCF Durandal that FSF and I both created recently has a shield that FS2 completely ignores despite proper coding, pof data and mission options. FSF created a Collision Mesh as part of the model and he was wondering if that could be the problem.
-
Well, try a version without the collision mesh.
-
You won't believe it, but.........
:nervous:
The collision mesh was the problem. It was somehow interfering with the shield mesh.
-
You won't believe it, but.........
:nervous:
The collision mesh was the problem. It was somehow interfering with the shield mesh.
Interesting. That's something we'll want to look into. Is it possible to have a shield mesh AND a collision mesh, or does the current "collision mesh" technique totally screw that up?
-
Download Durandal with collision mesh here (http://www.mediafire.com/?nhmmj4mjndm). Contains: model, map, table, mission.
FS (3.6.12 RC2) does seem to play the "bzzz" for a shield impact, but apart from that, the shield seems to be fully ignored.
-
Just out of curiosity, is the collition mesh smaller than the shield one?... I mean: the collition mesh is beneath the shield one?
-
Try an 80 face shield rather than 320 to see if it makes any difference.
-
Nope, doesn't seem to make any difference. http://www.mediafire.com/?ux3zminzwlj