[Tarvis]

See http://www.hard-light.net/forums/index.php?topic=67852.0 and http://www.hard-light.net/forums/index.php?topic=67852.msg1339812#msg1339812 for more info.

Here is the list of MediaVPS ships that show this problem.

SHIPS:
Terran:
[fighter2t-02.pof] -- GTF Hercules Mark II
[fighter2t-01.pof] -- GTF Pegasus
[capital01.pof] -- Nameplate area of un-named GTD Orion (but not named ones)
[navbuoy.pof] -- GTNB Pharos
[bomb2t-01.pof] -- TC-Meson Bomb

Shivan:
[capital04.pof] -- SD Demon

MISSILES:
[newhornet.pof] -- Hornet (D) / Hornet #Weak
----[newhornet_tech.pof] -- Hornet Tech Model / Hornet #Weak Tech Model
[pirahna.pof] -- Pirahna (D)
----[pirahna_tech.pof] -- Pirahna Tech Model
[Tsunami.pof] -- Rebel Bomb / Unknown Bomb / Vasudan Flux Cannon
[EMPulse2.pof] -- EMP Adv.
----[empulse2_tech.pof] -- EMP Adv. Tech Model
[Harbinger.pof] -- Unknown Megabomb
----[harbinger.pof] -- Fusion Mortar
[Interceptor.pof] -- FighterKiller
[Hornet.pof] -- Swarmer
----[hornet.pof] -- Cluster Baby / Cluster Bomb Baby

[Cobra]

The Pharos isn't even meant to be shot or collided with, so you can take that off the list. And why are you listing the missiles?

[Snail]

Missiles don't even collide, do they? It's like a radius sorta deal isn't it?

Also if the Demon is bugged this must mean it's been bugged since retail, since the mesh has not been changed...

[Bobboau]

missiles only use radius for collision so you can take them off the list.

[Zacam]

I'd rather they stay on the list.

Whether or not the models are meant to have collisions is irrelevant to the fact that they should not (in an ideal situation) show the problem that they do, so there for it should be corrected.

Thank you for the work and the report, Tarvis. Much appreciated.

[Vasudan Admiral]

No need to correct the missiles if there are other things to do though. Doing so won't change anything in-game, so it'd be more of a 'I'm really really bored' activity.

Edit: also, 2 things
1) The Demon's problems don't appear to be like the others. It's not the same jagged triangles issue, and there have never ever been collision problems with it, so I say leave that one till we get a HTL version.
2) The orion nameplate I bet is more something to do with the nameplate lighting issues in the shaders rather than collision problems. No need to worry about that one either unless there are known collision problems with the nameplate region?

[Bobboau]

do you really think is a good use of time to fix collision detection on models that don't collide?

[Droid803]

Fixing collision on models that don't collide is just a waste of time.
What might be worthwhile though is find out why they are the way they are (if only to prevent this stuff from happening again).

[Tarvis]

do you really think is a good use of time to fix collision detection on models that don't collide?

If they are bombs, perhaps. Unless shooting bombs also uses radii.

Also if the Demon is bugged this must mean it's been bugged since retail, since the mesh has not been changed...

Actually, this problem isn't visible on retail, suggesting perhaps that somehow the issue isn't tied completely to the model...

[Vasudan Admiral]

Hmm, no it means something is wrong with the MVP demon model that wasn't wrong in the original. :\

[Bobboau]

shooting bombs also uses radii

[Zacam]

Bad collision issues == More than just an issue with whether or not it's actually going to hit something or get shot at.

It is a problem which ever way you look at it, and resolving it is _never_ a waste of time because it IS a problem. Just because it may not ever collide with anything does not mean that collision checks are not still performed, and bad model data of ANY kind can rape FPS or cause otherwise unknown behaviour to occur.

So, yes. _I_ do think it is a good use of time to ensure that what is being delivered for everyone to enjoy is as complete as possible, regardless of it's circumstance or whether or not somebody else thinks it's a waste of time, because it ultimately comes down to a question of Quality.

[Bobboau]

we are talking missile models, no, the BSP is never used for them.

[Zacam]

And you know for a fact that the code use for loading and interpreting models is going to know that and as such, not process it in the same way as any other model and _not_ have a problem with the data not being what it should be and as such, generate some sort of issue (even if in just computational overhead resulting in a loss of FPS)?

If the model is flawed, regardless of the circumstance of it's usage, it should be fixed, end of story. I have no problem with prioritizing them lower than actual ship models, that's fine, but they _are_ all going to get fixed. Period.

Now, if someone wouldn't mind giving me some tutorial like or one-on-one interaction for how to accomplish this feat, I'm more than happy to put my money where my mouth is and do the work myself.

[Tarvis]

Hmm, no it means something is wrong with the MVP demon model that wasn't wrong in the original. :\

Oh. I thought somebody said that the mesh was unchanged.

[Bobboau]

And you know for a fact that the code use for loading and interpreting models is going to know that and as such, not process it in the same way as any other model and _not_ have a problem with the data not being what it should be and as such, generate some sort of issue

well... seeing as how I am the person who WROTE that code, the code that interpreted the poly data and generated the vertex/index buffers for it, that are then what is used to draw the model. yeah I'm pretty sure.
the BSP tree is no longer used for rendering, it's only used for collision detection so if a model isn't being collided with then there might as well be no BSP tree at all. so long as there are not duplicate polygons there will be no performance penalty, and even if there was there would have to be a metric ton of duplicate polies for it to have any impact at all.

[Tarvis]

I think the best course of action would be to see how tough it is to fix it. If it's relatively easy, why not do it for missiles too? If it takes a long time or is tedious, perhaps missiles can be left out.

Either way, I posted them as an  F.Y.I. Nothing has to be done about them if there is no need. Same with the Nav Buoy.
(Though there is always the chance a mod may modify the buoy to be some sort of satellite to destroy or such)

[Snail]

I think the best course of action would be to see how tough it is to fix it. If it's relatively easy, why not do it for missiles too? If it takes a long time or is tedious, perhaps missiles can be left out.

Why? It's completely pointless since missiles don't actually use collision detection.

[Tarvis]

Okay then, don't fix them.

I think a more important issue however is actually figuring out why this is happening in the first place, whether it be an error in the model or the game engine (too many polys perhaps? That seems like a silly cause though)

[Dragon]

do you really think is a good use of time to fix collision detection on models that don't collide?

If they are bombs, perhaps. Unless shooting bombs also uses radii.

Also if the Demon is bugged this must mean it's been bugged since retail, since the mesh has not been changed...

Actually, this problem isn't visible on retail, suggesting perhaps that somehow the issue isn't tied completely to the model...

I think that this issue may be caused by model, but surfaced in FSO due to enhanced code.
Retail FS lighting system is years behind that of FSO, so the glith may had became visible due to advanced lighting.
In that case, it could have been there since retail.