About topology for flat surfaces in the low poly

Ruflse

Hi guys,

I have a question about a topic I know there are a lot of threads about, but after some time of searching I'm still confused about what would be the most optimized form of disposing the topology in a flat surface for a low poly that's not going to be deformed. Most of the discussions I've found treat this only for the case of the high poly.

So, which of these would be the most optimized way of caping the hole if the object is supposed to be displayed in game without errors? Since it's a flat surface and it's going to be triangulated both for baking and in the engine, a huge n-gon shouldn't give too many problems, but I never see this option anywhere.

Option B comes from this article I've found in a lot of old polycount threads: http://www.humus.name/index.php?page=Comments&ID=228. It can only be used in circular surfaces, it takes time and dunno if that method still can be applied to this day, but I though it would still be good to propose it.

C it's what I used to do in a lot of situations, but after finding that poles are not optimization-friendly I'm not sure how I should use them and from which number of unions they start to give some trouble. In most of the low polys I see they are used a lot for cleaning booleans, so I don't know when a pole can really cause problems in a flat surface of a lp. In C I propose two examples: the little one, with 30 tris and 32 verts (the same for A, B and D); and the big one, with 30 tris and 33 verts. I always tend to connect the verts to another, instead of creating a new one. Again, since it's not going to be subdivided, I don't care about any poles in borders.

D can seem obviously the best solution because it's fast and clean, but I'm proposing the ideal case of a sphere with a pair number of vertices surrounding the surface, and in most instances it's not going to be like that and if you want to do it for the sake of "only quads" you will have to add a lot of innecesary edge loops. Also, it's still faster just using an n-gon if you are sure the surface is 100% planar.



I have to clarify that I'm proposing this only for the case of a hard surface low poly that's going to be used in a game engine without any kind of error, and so it's not going to be deformed. The examples proposed using this sphere are completetly hypothetical and extreme, but I want to know how much can you really push the use of n-gons or poles and which is the best way if what you want is perfomance above everything else (without visually affecting the model), or time in the case that it doesn't really matter optimization-wise.

Probably I'm just giving this too much importance and the differences are minimal in comparation with the use of textures, shaders... but I would appreciate any help so I can get this out of the way.

pior

Ruflse said:

it's still faster just using an n-gon if you are sure the surface is 100% planar.

This is incorrect, because anything that reaches an engine is triangulated anyways. If you leave it as an ngon in your authoring environment you are simply leaving the triangulation up to the exporter/importer, which is likely going to be based on shortest distance, and that would be pretty awful :

Shortest distance (yuck !) :


There are countless of better solutions.

Quad fill (fast and automatic, quite decent) :


Manual 1 :


Manual 2 :


Single pole is definitely risky if the surface is in plain view, no doubt about that. Anything that transitions in an even and logical way is pretty good in my opinion. And then of course it all depends if a normalmap is supposed to be generated from such a low, whether or not the cap is set to hard, and so on.

Obscura

There is only 2 things to consider, nothing else:

1. How does it shade w/o a normalmap applied
2. How much overdraw you create.

In both cases, D from your ones , or manual 1 or 2 from Pior's example would work the best.
These, because you don't have very tiny and long faces - on D of your's you still have some. And because manual 1 and 2 contains supportloops along a sharp edge so your baked normal would have less gradients.

Ruflse

pior said:

Ruflse said:

it's still faster just using an n-gon if you are sure the surface is 100% planar.

This is incorrect, because anything that reaches an engine is triangulated anyways. If you leave it as an ngon in your authoring environment you are simply leaving the triangulation up to the exporter/importer, which is likely going to be based on shortest distance, and that would be pretty awful :

Shortest distance (yuck !) :

Obscura said:

There is only 2 things to consider, nothing else:

1. How does it shade w/o a normalmap applied
2. How much overdraw you create.

In both cases, D from your ones , or manual 1 or 2 from Pior's example would work the best.
These, because you don't have very tiny and long faces - on D of your's you still have some. And because manual 1 and 2 contains supportloops along a sharp edge so your baked normal would have less gradients.

But does that ugly triangulation of the n-gon really matter tho? The shape is the same, and I know for this thread (http://polycount.com/discussion/81154/understanding-averaged-normals-and-ray-projection-who-put-waviness-in-my-normal-map/p1) that support loops can help avoiding waviness in the normal map, but for flat surfaces I think what matters the most it the fidelity of the silhouette, so would adding s. loops do much in that case? It would still be more geo than the necesary for capping a cylinder, and if the results arent going to be noticeable I wouldn't do it. Also, as I said the sphere is an ideal example where you have clean topology surrounding the surface and you can close the hole in a lot of ways, but most of the time those three solutions Pior proposed are not posible (and spend too much geo).
 
This is and example I have where I let the n-gon there and it didn't really give any problems: http://imgur.com/a/odLu2 (the highpoly is really bad and I didn't asigned the smoothing groups in the most beatiful way, but I hope you can see what I mean more or less).

And why would a huge pole be bad and from when can it be trouble? They tend to be avoided for the creation of the high poly, but I see them a lot in hard surface. Is there a point where they can start to give optimization or shading problems if the surface is flat or it's just totally dependant of the engine?

pior

Poles and thin triangles can behave quite badly once the normalmap starts mipping down - because pixels become much bigger than the triangles very quickly, hence accurate math/shading cannot be maintained.

But does that ugly triangulation of the n-gon really matter tho?

There is no good reason to do something ugly when something nice and clean can be done instead. Not only is it better for the reasons mentionned above but that's also better for UVs, better for later optimisations, potential edits showing up unexpectedly under a deadline ... and it's also better for the sanity of your coworkers You don't want to end up being known as "the guy who triangulates at random". Random edges would also behave pretty badly with Face Weighted normals.

Note that I am not saying that the "manual" methods I mentioned should be used at all times. But *if* the model in question is exactly of the shape you mention (clipped sphere) and in need of high shading accuracy in plain sight, *then* yes you will be better off with something clean and even. It all depends on very specific contexts really.

Ruflse

pior said:

Poles and thin triangles can behave quite badly once the normalmap starts mipping down - because pixels become much bigger than the triangles very quickly, hence accurate math/shading cannot be maintained.

Didn't know that reason about why thin triangles are bad in the low poly. But what about if the triangles of the pole are equilateral or not as thin? Are they still a general problem for an engine? Or to put it another way, should the union of more than 4 edges to a single vertex be avoided independently of the size of the polygons that are connected to that vertex (considering that it's a flat surface that's not going to be deformed)?

This may be a pretty redundant question, but just to be sure.

pior

At this point this is really just theorizing it. You'll have to practically try the various setups in the very specific context you are working with to see what works best, what behaves best under texture scaling, and so on.

Joopson

Personally, this is usually how I lean. I find the support edge of quads helps with shading, etc, and that capping it the way a cylinder is capped saves time.

AtticusMars

Ruflse said:

Option B comes from this article I've found in a lot of old polycount threads: http://www.humus.name/index.php?page=Comments&ID=228. It can only be used in circular surfaces, it takes time and dunno if that method still can be applied to this day, but I though it would still be good to propose it.

If you're concerned specifically about performance, just thought I'd quote this post by Perna re: this website. It's from 2014 but I'm going to guess things haven't changed much.

While an interesting historical/academic read, the info on that page has zero relevance for current-day asset production. Just thought I'd make this clear so beginners don't start wasting time making awkward geo thinking that it will in any way help performance.

Make the geometry that is easiest for you to work with[...] and don't worry about triangulation performance for modern day games unless you're dealing with extremely specialized cases like particles etc.

Ruflse

Yeah I'm probably looking too deep into this.

Thanks guys, I understand this better now. Maybe I'll test this and post the result here if I get something out of it.