Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: zookeeper on June 01, 2012, 05:13:41 pm
-
Note: this very likely applies to other formats than pof, and to other apps than 3ds Max. However, since this is the combination I'm familiar with, I'll talk only about them and let you decide where else this is applicable.
In the pof format (and I imagine quite a few other model formats as well), the number of vertices isn't going to be the same as the one you'll see in Max. In pofs, a model will be split into groups according to the smoothing groups of the model so that a single vertex can only share triangles which have the same smoothing group. If a vertex borders a face with smoothing group 1 as well as a face with smoothing group 2, the vertex will get duplicated, exactly as if you had actually detached those faces from each other in Max.
This means that the vertex count of any given model will actually be a lot higher than the "real" vertex count of the source model. A model where every face has the same smoothing group would be unaffected, but that's not something you're going to see on a typical model. For example, a cube with a single smoothing group applied to it will end up using up 8 vertices (as you'd expect), whereas a cube with "normal" angular smoothing (or no smoothing at all; it's the same thing) will actually take up a whopping 24 vertices.
So... I just thought that people would like to know that.
[attachment deleted by a ninja]
-
Reminder: vertex reduction is NOT an excuse to "pillowsmooth"!!!!
-
it all gets converted to vbos anyway (i think) so it really doesn't matter. polycount, surface area, and texture resolution is what determines rendering performance, as it directly affects fill rate, where as vertex counts do not.
-
Unless I'm mistaken, however, vertex limits do exist. So, if your surface is of great complexity, and is high poly (thus requiring lighting differences, aka edge splits), you may thus encounter an issue, however unlikely.
Moreover... would this potentially cause collission detection issues? Duplicate, unwelded verticies needed to cause the split would result in a mesh which would be broken up into many pieces, which would not be enclosed. What happens then?
-
Duplicate, unwelded verticies needed to cause the split would result in a mesh which would be broken up into many pieces, which would not be enclosed. What happens then?
Well seeing as it was this way in retail, and the way the engine is built, I would presume Absolutely Nothing happens? Because that's the way it was always intended to be for use in the game anyway?
-
Moreover... would this potentially cause collission detection issues? Duplicate, unwelded verticies needed to cause the split would result in a mesh which would be broken up into many pieces, which would not be enclosed. What happens then?
Droid is right - nothing happens. I have plenty of working unenclosed meshes ingame.
-
Well, I am a victim of misinformation, then. I recall reading several reports of non-manifold meshes performing badly with collision detection, etc. I realize there have been counter-arguments since, but from working on other teams, I can note that open meshes were indeed a source of some problems, or at least seemed to be.
In any sense, thank you for the clarification.
-
Yep, all my models are non-manifold, see if I give a ****, they work fine.
At least now this is well-reasoned, since the POF format essentially makes it non-manifold surfaces anyway, and its inherent to the format, meaning that it was present since retail, and thus inherent to how the FreeSpace engine works.
Thus, I conclude that whoever said that models have to be manifold to work in FreeSpace is spouting bull****, based on this information, and my own personal experiences with non-manifold models. :P I'm willing to bet that there were plenty of other things wrong with those "problematic" models, and its non-manifold-ness had (inherently) nothing to do with it.
-
they had to be manifold in the olden days when the model converters werent too good. theese days pcs2 is so damn good that you dont need to make stuff manifold anymore. you can actually save a ****ton of polygons because of this, because you dont have to break up the hull for every single protrusion, such as wings, guns and antennas and good ol' shivan spikes.
really i think its a fallback to when we used cob as the primary conversion format, truespace had this annoying thing where if a mesh was not solid you really couldn't do anything with it. so if you worked in truespace you absolutely required a manifold mesh, even if you modeled in something else you would need to put it into truespace to set up hierarchy (****ing lights). early alternatives to cob had issues generating collision detection info. collada has pretty much resolved all of these issues.
-
Note: this very likely applies to other formats than pof, and to other apps than 3ds Max. However, since this is the combination I'm familiar with, I'll talk only about them and let you decide where else this is applicable.
In the pof format (and I imagine quite a few other model formats as well), the number of vertices isn't going to be the same as the one you'll see in Max. In pofs, a model will be split into groups according to the smoothing groups of the model so that a single vertex can only share triangles which have the same smoothing group. If a vertex borders a face with smoothing group 1 as well as a face with smoothing group 2, the vertex will get duplicated, exactly as if you had actually detached those faces from each other in Max.
This means that the vertex count of any given model will actually be a lot higher than the "real" vertex count of the source model. A model where every face has the same smoothing group would be unaffected, but that's not something you're going to see on a typical model. For example, a cube with a single smoothing group applied to it will end up using up 8 vertices (as you'd expect), whereas a cube with "normal" angular smoothing (or no smoothing at all; it's the same thing) will actually take up a whopping 24 vertices.
So... I just thought that people would like to know that.
This makes me think it has to do with something related to the original graphics API (DirectX), because I noticed a major slowdown in Max 9 whenever I removed all the shader groups. Instead of each polygon/tri being sent to the GPU, the API might've sent all poly/tri that belongs in a shader group as one distinct mesh. Therefore, this phenomenon seen in the pof format may be due to optimizations, intended or not. :confused:
-
Unless I'm mistaken, however, vertex limits do exist. So, if your surface is of great complexity, and is high poly (thus requiring lighting differences, aka edge splits), you may thus encounter an issue, however unlikely.
Yeah, that's how I found out about this. I had a model which, according to the vertex count in Max, did fit within the vertex limit of 65536 just fine. However, in-game I got a very messed up model, with the normals of vertices past 65536 getting overwritten by garbage. It took quite a while to figure out what was really going on.
-
Is this the main reason why duplicate vertexes cause problems when converting to POF?
-
Unless I'm mistaken, however, vertex limits do exist.
at somewhere around 4 billion
Moreover... would this potentially cause collission detection issues? Duplicate, unwelded verticies needed to cause the split would result in a mesh which would be broken up into many pieces, which would not be enclosed. What happens then?
IIRC the points, are stored separate from their verts specifically for collision detection, so this is a non issue.
Fun Fact: differences in UV space also cause a split when the model is loaded.