Contiguous mesh vs. Segmentation

[Gnome_AS 10]

Wondering what experiences some of you guys may have had concerning modeling practices and the BIS engine. Primarily if I should be concerned with excessive z-fighting (or anything else) using segmented penetrating meshes vs. contiguous (air-tight) meshes.

I'm not really up-to-speed on modeling for games, so I'm not sure how valid the question may or may not be, but it came up in a discussion with a buddy.

Generally speaking I model however the real world object is built/designed. My current project (Mk V SOC) boat is segmented primarily for extended detail and instancing objects. I'm not really sure what or if there is a poly count ceiling in the engine (?), so I've been cautious thus far. (15k'ish currently ... without any real effort in reduction)

Granted I could mash it all down into a contiguous mesh ... the poly count is likely to ramp up quite a bit. I'm not really concerned with the UV space, I can generally sort that out regardless modeling methods.

Anyway without further rambling ... thoughts, suggestions welcome. I've read elsewhere that z-fighting is really more of an issue with objects/segments on or near the same plane.

Apprecaite any clarification, my apologies for being rather dense on the subject matter :)

_

[PuFu 4600]

This goes for all game models/meshes

In general, it is advisable to build your mesh as a contiguous one. Or at least this is how i do it (yes, it takes more time and patience). There are pros an cons to that

Obviously, not everything is worth being modeled as a single mesh, such as nuts and bolts welded into an airframe.

What i generally do, is build all the individual parts that i will later animate as a contiguous meshes (not a subobjects of a entity, but as a single welded quad-poly mesh). I find it easier to deal with later on, when i need to subD the LowPoly.

It is also of a good practice to build it like it is built in the real life (for weapons as an example). But then you might overlap faces (which is a big no no - and the main reason for z-fighting), or increase your poly count by creating parts that would never be seen.

For soft-models(faces, characters, cloths etc), the best practice is to keep it all as a single welded mesh(easier to morph, animate and pose). For hard-surface you can have exceptions, especially where intersections between 2 different primitives would lead to more complicated geometry than what is needed (also there is a huge difference between the LP model and the HP model, since one is never used in a game engine).

Contiguous models (as i have found out):

PROs:

Easier to subdivide for LowPoly models

Easier to modify on the long term

Easier to bake (although you might need to break the model if it is too complex and the cage doesn't fit well)

CONs:

Harder intersections and geometry forms resulted.

Harder to create and use, especially when working without good refs

In the end, BIS engine will work with both methods. But i found it to be a better workflow to have as little objects to deal with and maintain.

[Gnome_AS 10]

Most excellent Pufu, that helps quite a bit :)

In cases where I decide it's just not worth the effort to cut it all to hell and back, would utilizing a 1px float above what would normally be an intersecting face be good practice?

Also, I've just gained some knowledge about how the engine handles SG's and the resulting counts after the fact. So I'm leaning towards using proxies to get over what I now understand to be a 32k count ceiling or so. Any thoughts regarding that process? Are there similar issues with utilizing the proxies? (i need to read up on that..)

_

[PuFu 4600]

In cases where I decide it's just not worth the effort to cut it all to hell and back, would utilizing a 1px float above what would normally be an intersecting face be good practice?

I am unsure of the question here. Maybe you can rephrase..

Also, I've just gained some knowledge about how the engine handles SG's and the resulting counts after the fact. So I'm leaning towards using proxies to get over what I now understand to be a 32k count ceiling or so. Any thoughts regarding that process? Are there similar issues with utilizing the proxies? (i need to read up on that..)

yes, the 32k(2^15 =32768) count is in fact the number of vertex normals rather than number of vertices(verts/points). So a hard surface model will be less likely to fit in the given number(it is hard to tell as well), than a soft surface one (in theory it would be a 32k sphere).

Proxies can be used to dismantle a model into smaller pieces, each one(.P3D) can contain a max of 32k vert normals(hence going over the limit per model). Proxies keep all the values in their p3d (LOD information, as well as animations, maps, etc..)

some info about vertex normals HERE

Edited January 1, 2011 by PuFu
rephrase

[Gnome_AS 10]

Ah ha! That makes good sense to me now on the vertex normals and counts. :)

Regarding the 1px float ... basically instead intersecting 2 objects (say stabbing a pole thru the hull of my boat) I would just stop the pole as short as possible instead of passing thru the hull.

Normally I pass thru just enough to get the terminating vert(s) thru the object. But if holding them just above could help prevent some z-fighting ... thats an easy to do.

This was mentioned to me by the same buddy. His impression was that it might be handled better by the engine and not likely to be noticed by players. Does that seem like a reasonable thought process? Perhaps not something to worry with?

Thanks again Pufu

[PuFu 4600]

Regarding the 1px float ... basically instead intersecting 2 objects (say stabbing a pole thru the hull of my boat) I would just stop the pole as short as possible instead of passing thru the hull.

Normally I pass thru just enough to get the terminating vert(s) thru the object. But if holding them just above could help prevent some z-fighting ... thats an easy to do.

Alright, thought that is what you were trying to say, but got confused about using the pixel as a measure unit for a 3d mesh :rolleyes:

Firstly, there shouldn't be any faces left to over-pose (in your example, there should be no back face on that stabbing pole).

Secondly, depending on the software used, you could move the verts right on the surface, but that is not sufficient to remove the z-fighting, unless you actually connect them with the rest of the geometry.

Your best solution(unless welding) is exactly the opposite: to actually stab the existing geometry further down into, so no matter of the LOD used, it will still be inside, not close enough to z-switch.

This was mentioned to me by the same buddy. His impression was that it might be handled better by the engine and not likely to be noticed by players. Does that seem like a reasonable thought process? Perhaps not something to worry with?

It shouldn't be much of a worry, but as i said, floating geometry shouldn't be used at all (unless you wanna bake normals from Hp to PL, and the said geo is in the HP model). The result you might get , although not z-fighting, might be similar though

Edited January 2, 2011 by PuFu

[[aps]gnat 28]

As mentioned, theres no point intergrating the pole into the hull, because that would actually dramaticly increase your poly could. Making the pole separate *might* create a z-fight issue, but from my experience it doesnt seem to be a problem whether you "go through" or "come up short".

Contiguous models also have the advantage that they become easy to use as Shadow LODs.

ie. Its costs a little extra on poly count, but make sure your "pole" has end-caps on it. That way its a breeze to use for a shadow.

On poly count, the biggest issue I see people missing on is the "round stuff".

They make a vehicle model, the main body looks nice/fine and only has a count of maybe 3000, then they go add six wheels or a radar disk or a gun barrel and suddenly the poly count is 26,000 !!

People need to pull back from the "perfectly round wheel" or the "perfectly round and smooth cannon barrel" ! ...... the poly count for such items can be dropped by a huge amount and with good textures and lighting, ingame you will barely notice the difference.

For me the main issue tends to be getting the faces right so the lighting isnt a mess.

And accidental double-facing can be a killer and hard to find.

The other related thing I find a little amusing, land contact points.

Most addon roll around on tyres that barely touch the ground, look at the real vehicles, the tyres are flat at the bottom! :rolleyes:

Raise your landcontacts! ;)

Edited January 2, 2011 by [APS]Gnat

[soul_assassin 1750]

On the poly count: I'm not entirely sure it's to do with a hard point/normal count but rather a fixed amount of bytes assigned per object. Thus ergo my final conclusion is as follows: both a vert and a normal take 12 bytes each (afaik). Add all the verts + all the normals * 12 = total byte size. If byte size > then the d3d byte cap then the model won't work. What got me thinking about this is that I actually managed to make a test model with > 32k normals. Before u ask I don't know what the byte cap is but my gut feeling tells me a quick d3d ref search could answer that question.

About the way to model. I would say there is no right way. I'd say the more you do it the more you get a feel for what is the right way for you. While u model u just look and I will make perfect sense: a box sticking out of a larger box : cut and extrude, a cylinder sticking out of a box: probably better to just have them separate. However remember the simple fact that what the guys here said is only partially true. Yes you will have a few more polies if you merge BUT a poly is simply an array of vertex IDs and texture info. Most bytes come from verts since they have position, uv and normal data. If u merge a cylinder with a box the total number of verts STAYS the SAME!

Edited January 2, 2011 by Soul_Assassin

[Gnome_AS 10]

@Pufu

Your best solution(unless welding) is exactly the opposite: to actually stab the existing geometry further down into, so no matter of the LOD used, it will still be inside, not close enough to z-switch.

This makes sense once again :) Sorry about the pixel reference, that was my all pro move for the day..

@Gnat

On poly count, the biggest issue I see people missing on is the "round stuff".

They make a vehicle model, the main body looks nice/fine and only has a count of maybe 3000, then they go add six wheels or a radar disk or a gun barrel and suddenly the poly count is 26,000 !!

quality. I suffer from low poly achievement syndrome personally.

@Soul Assassin

While I'm fairly lacking in d3d education here, that all makes reasonable sense. Awesomely helpful max tool btw, that and the videos clarified a lot of the process for me. Probably wouldn't be humoring myself with this without it ;)

---

@All

Really helpful guys, appreciate the experienced input. I feel a lot more confident in my approach now. Having a good workflow is one of my larger goals, so I think I'll go ahead and make the extra investment to model contiguously except where it really just doesn't make sense. Seems that will be more productive at the end of the day.

Good stuff, I'm slightly more educated and about twice as dangerous.

:coop:

_

[PuFu 4600]

On the poly count: I'm not entirely sure it's to do with a hard point/normal count but rather a fixed amount of bytes assigned per object. Thus ergo my final conclusion is as follows: both a vert and a normal take 12 bytes each (afaik). Add all the verts + all the normals * 12 = total byte size. If byte size > then the d3d byte cap then the model won't work. What got me thinking about this is that I actually managed to make a test model with > 32k normals. Before u ask I don't know what the byte cap is but my gut feeling tells me a quick d3d ref search could answer that question.

What you are saying there sound odd mate, but might as well be possible. I have searched the google up and down for this information, as well as M$ website. Found nothing about DX or D3D either way.