Really? I don't recall that. Only remember discussing this with GMN.Warlord Zsinj wrote:I remember having a big discussion with flozi about this a long time ago on the TAU forums. Can't seem to find the thread though.
Partially hidden faces
Moderators: MR.D, Moderators
Re: Partially hidden faces
-
Wolf-In-Exile
- Posts: 497
- Joined: 21 Nov 2005, 13:40
Re: Partially hidden faces
Which one to choose really depends on the amount of intersecting edges, and the amount of "wasted" texture space.
In the case of simple intersections like the example posted, the measly few polies added won't have a really big impact on its memory footprint.
If your intersecting geometry is more complex however, its worth the sacrifice of texture space, although you can still use that space for other, smaller geometry that fit inside it (or simply overlap bits of other UVs, just make sure it doesn't bleed on the visible area).
Of course, if the geometry is small, its better to put it into the texture anyway, as the others pointed out.
In the case of simple intersections like the example posted, the measly few polies added won't have a really big impact on its memory footprint.
If your intersecting geometry is more complex however, its worth the sacrifice of texture space, although you can still use that space for other, smaller geometry that fit inside it (or simply overlap bits of other UVs, just make sure it doesn't bleed on the visible area).
Of course, if the geometry is small, its better to put it into the texture anyway, as the others pointed out.
Re: Partially hidden faces
Good question. Here's my $0.02.
The TL:DNR version:
1. If the object poking out is going to be large and potentially waste a lot of uv space on the object it projects from, it should be modeled.
2. If it's a repeating object that's going to be cloned, it should cut.
3. If the area involves transitions from curves to hard edges, then you should probably cut.
4. There are other exceptions, including tricks to speed production time, but they're either marginal or are sloppy.
Generally speaking, my experience is that other than the occasional shadow rendering artifact due to Spring's z-ordering when rendering the shadow pass, it's not a really big deal to use cut facets, in terms of rendering problems per se. The rest of it is a matter of making good calls about how you want your geometry structured, and weighing the possible benefits in polycount reduction vs. the loss of resolution that's inherent to the process.
Since the engine doesn't natively support mesh deformation animation (ok, technically, it does, but only through instructions at a per-vertex level, but meh, that's so slow in BOS I don't even wanna talk about it) there's no reason not to cut facets to save on polycount, where appropriate.
You won't see much uvmap wastage, if you're mapping well- things like the small edge of a protruding cuboid, for example, don't need a lot of space generally, and should be aggressively reduced in resolution so that you're not wasting space for big facets that show.
In some engines, keeping the entire mesh as one piece matters more, because of the way that objects are tristripped. IIRC, Spring tristrips the objects piece by piece, and the display lists are static, so this isn't a big deal.
The biggest issue with this technique, as Wolf pointed out, is that you're potentially wasting a lot of texture space- to cite that first example, that cube facet's uv space would be 90%+ wasted, because players are only really going to see the cutout. That's a lot of fill-rate wasted per pass, and it should have been modeled as a whole mesh.
But it's a judgment call. There are no fixed rules for this. If that quad behind that square can be safely dropped in resolution vs. the other facets (after all, you can hide the lack of resolution with something showing very little pretty easily with some airbrush) then why not- the polygon savings are worth it.
I tend to use this for repeating patterns of shapes that are going to be used all over the geometry, like Snipa's tank. That's actually a really good use of this idea, if all of the cuboids of a given color share the same uv space. Why not use them to create bumps at a fairly low polycount?
GMN does a lot of cut-facet stuff to build very complex geometry with a series of smaller objects mixed with complex, larger geometry. This makes his models fairly difficult to get uvmapped reasonably efficiently sometimes, but most of the smaller bits can be put into very low texture resolutions without any noticeable problems at typical zooms, and look all right even in a render, and the resulting polycount savings do add up, quite quickly. There are places on some models where this means a fair amount of texture space was wasted- for example, the LightMech's rear "reactor" greeble wastes a lot of space with faces that are nearly hidden, but were left on to keep the geometry reasonably simple to unwrap. We could have gotten that space "back" by upping the polycount, but that would have been a waste of production time. You just have to call that as you go.
And, finally, there are a lot of places where I always cut facets, because of polycount considerations. On gun barrels, for example, the number of polygons required to transition from a "round" shape to a cuboid or other geometry is quite expensive, and pure waste, considering you probably can't see most of the shape and the resulting triangles will almost certainly be smaller than the resolution of the monitor. GMN does a lot of stuff where he has complex curvature mixed with cut-facet low-poly bits that are cut, and that trades some UV space for simpler unwrapping and far lower polycount. As the guy who ends up unwrapping it and painting it, it makes the initial part harder, but it doesn't make painting any more difficult- the little stuff, or stuff hidden by a cut, is kept small on the map, and airbrush fudged. And when you're talking about shaving hundreds of triangles, which is almost always the case... well, it certainly makes sense.
Lastly, in terms of "when should it just be textured"... my feeling on this is that anything that is going to be seen from fairly narrow angles (for example, the "engine" greebles on the back of the Resistance Advance Base) or is small enough that the lack of real lighting won't be terribly noticeable should always be a texture greeble. Anything large enough and exposed to a lot of angles should generally be modeled. If you want a big bumpy thing on a leg, for example, it should probably get modeled, and given that a leg tends to involve some large facets, you may very well want to keep it one piece, and simply accept the resulting time-cost of unwrapping it.
Lastly... as we've already discussed, at length elsewhere... the chief issues with Spring models aren't so much raw polycount as complexity, since each Piece is a display list. I keep thinking I need to sit down and finish my mesh-deformation demo, to actually see some real numbers about the costs associated with having lots of "pieces" (really, just frames) in memory, but not being drawn, vs. all of the transforms involved in multi-piece animation...
The TL:DNR version:
1. If the object poking out is going to be large and potentially waste a lot of uv space on the object it projects from, it should be modeled.
2. If it's a repeating object that's going to be cloned, it should cut.
3. If the area involves transitions from curves to hard edges, then you should probably cut.
4. There are other exceptions, including tricks to speed production time, but they're either marginal or are sloppy.
Generally speaking, my experience is that other than the occasional shadow rendering artifact due to Spring's z-ordering when rendering the shadow pass, it's not a really big deal to use cut facets, in terms of rendering problems per se. The rest of it is a matter of making good calls about how you want your geometry structured, and weighing the possible benefits in polycount reduction vs. the loss of resolution that's inherent to the process.
Since the engine doesn't natively support mesh deformation animation (ok, technically, it does, but only through instructions at a per-vertex level, but meh, that's so slow in BOS I don't even wanna talk about it) there's no reason not to cut facets to save on polycount, where appropriate.
You won't see much uvmap wastage, if you're mapping well- things like the small edge of a protruding cuboid, for example, don't need a lot of space generally, and should be aggressively reduced in resolution so that you're not wasting space for big facets that show.
In some engines, keeping the entire mesh as one piece matters more, because of the way that objects are tristripped. IIRC, Spring tristrips the objects piece by piece, and the display lists are static, so this isn't a big deal.
The biggest issue with this technique, as Wolf pointed out, is that you're potentially wasting a lot of texture space- to cite that first example, that cube facet's uv space would be 90%+ wasted, because players are only really going to see the cutout. That's a lot of fill-rate wasted per pass, and it should have been modeled as a whole mesh.
But it's a judgment call. There are no fixed rules for this. If that quad behind that square can be safely dropped in resolution vs. the other facets (after all, you can hide the lack of resolution with something showing very little pretty easily with some airbrush) then why not- the polygon savings are worth it.
I tend to use this for repeating patterns of shapes that are going to be used all over the geometry, like Snipa's tank. That's actually a really good use of this idea, if all of the cuboids of a given color share the same uv space. Why not use them to create bumps at a fairly low polycount?
GMN does a lot of cut-facet stuff to build very complex geometry with a series of smaller objects mixed with complex, larger geometry. This makes his models fairly difficult to get uvmapped reasonably efficiently sometimes, but most of the smaller bits can be put into very low texture resolutions without any noticeable problems at typical zooms, and look all right even in a render, and the resulting polycount savings do add up, quite quickly. There are places on some models where this means a fair amount of texture space was wasted- for example, the LightMech's rear "reactor" greeble wastes a lot of space with faces that are nearly hidden, but were left on to keep the geometry reasonably simple to unwrap. We could have gotten that space "back" by upping the polycount, but that would have been a waste of production time. You just have to call that as you go.
And, finally, there are a lot of places where I always cut facets, because of polycount considerations. On gun barrels, for example, the number of polygons required to transition from a "round" shape to a cuboid or other geometry is quite expensive, and pure waste, considering you probably can't see most of the shape and the resulting triangles will almost certainly be smaller than the resolution of the monitor. GMN does a lot of stuff where he has complex curvature mixed with cut-facet low-poly bits that are cut, and that trades some UV space for simpler unwrapping and far lower polycount. As the guy who ends up unwrapping it and painting it, it makes the initial part harder, but it doesn't make painting any more difficult- the little stuff, or stuff hidden by a cut, is kept small on the map, and airbrush fudged. And when you're talking about shaving hundreds of triangles, which is almost always the case... well, it certainly makes sense.
Lastly, in terms of "when should it just be textured"... my feeling on this is that anything that is going to be seen from fairly narrow angles (for example, the "engine" greebles on the back of the Resistance Advance Base) or is small enough that the lack of real lighting won't be terribly noticeable should always be a texture greeble. Anything large enough and exposed to a lot of angles should generally be modeled. If you want a big bumpy thing on a leg, for example, it should probably get modeled, and given that a leg tends to involve some large facets, you may very well want to keep it one piece, and simply accept the resulting time-cost of unwrapping it.
Lastly... as we've already discussed, at length elsewhere... the chief issues with Spring models aren't so much raw polycount as complexity, since each Piece is a display list. I keep thinking I need to sit down and finish my mesh-deformation demo, to actually see some real numbers about the costs associated with having lots of "pieces" (really, just frames) in memory, but not being drawn, vs. all of the transforms involved in multi-piece animation...
Re: Partially hidden faces
Yeah, I guess not many would opt for this:
Re: Partially hidden faces
there are times where I am sure someone might but most of the time no