Make Quads out of a Ngon flat face on a static game mesh, yes or no ? ( No Subd, no bake )

Andreicus

I tend to have all quads where possible on my meshes especially if i know that i will subdivide them but i was wondering in the case of a real time asset like this: 



As you can clearly see i have a flat face with ngons. This is already the final mesh, i won't do any bake or smoothing ( subd ) and i know that the engine will triangulate the face anyway.

So the question is: Should i quad out the face even if i'm not going to do any smoothing or baking or can i leave it as it is and just triangulate on export ?
If the ngon was on a curved face i would probably quad it out to prevent shading issues but with a flat face i don't know if it's going to make a difference.

musashidan

The engine will triangulate it anyway so just retriangulate it before export with some manual input to ensure there are no shading artifacts. Often times with large n-gons with many verts you will get undesired results with auto-trianulate so it's best to put a few strategic edges in yourself to guide the process. This is what I do for all my hard-surface assets as my method relies heavily on n-gons.

Andreicus

musashidan said:

The engine will triangulate it anyway so just retriangulate it before export with some manual input to ensure there are no shading artifacts. Often times with large n-gons with many verts you will get undesired results with auto-trianulate so it's best to put a few strategic edges in yourself to guide the process. This is what I do for all my hard-surface assets as my method relies heavily on n-gons.

I see, thanks for the feedback

poopipe

I'd recommend adding edges to contain the bevelled corners - that will ensure you don't get long, thin triangles across the surface (which are bad) 

Eric Chadwick

They're getting long thinnies along all the sides tho.

Best to cut up those long quads while you're in there adding those edges to the top.

Yes it'll add vertices, but they aren't the bottleneck.

Alex_J

where does the bad shading related to long thinnies come from? Any reading about this? Or is it so complex it's better for the average joe to just know that long thin tri's = bad?

zachagreg

@BIGTIMEMASTER they basically cause "pixel shader overdraw".

https://blog.selfshadow.com/2012/11/12/counting-quads/

Alex_J

thanks @zachagreg.

I got a little ways into that and yeah, I'll just resign with "it's bad." haha. bit deep into the technical side of things. Pretty intersting read even though a lot of it's over my head anyhow.

zachagreg

The way I understand it is that any triangle is rendered 2x2 pixel quads at a time. So you if you have a long skinny triangle those 2x2 quads are going to hit maybe one pixel the entire length of the hypotenuse of the long skinny while overdrawing 3 pixels for each quad. Kind of like estimating a limit going to infinity. Imagine the jaggies on aliased graphics had to be packed into 2x2 squares along an entire edge you'd get a shit ton of wasted space along it. The image below is for a different thing but number 3 kind of illustrates the concept.

musashidan

Also, long thins(and bad triangulation in general) can cause shading errors that carry across to the normal map if baking.

Sadly, the knowledge and understanding of triangle topology is a dying artform. As triangle budgets have gone up the it has led to sloppiness or just plain ignorance of something that used to be a greatly admired skill in the heady days of 3 edge segment shoulder pads.....

Eric Chadwick

Alex_J

I've never even heard of triangle topology. Does this mean building a mesh with triangles only?

sprunghunt

BIGTIMEMASTER said:

I've never even heard of triangle topology. Does this mean building a mesh with triangles only?

I think what he means is creating meshes to have good triangulation. This means avoiding fans and long thin polygons. 

Back in the old days polygons were sorted using their centers. Not using a per pixel depth buffer. So you would get something called z-fighting where polygons would 'pop' and draw in front of polygons they used to be behind. You can see this if you find an old virtua fighter arcade game. So you had to build models that had even sized triangles (and not many of them). It's still a good idea to do this.

Eric Chadwick

No, the issue is all game engines render their meshes as triangles.

http://wiki.polycount.com/wiki/Polygon_Count

We use quads when modeling because the tools are easier with quads. But in the end, it's still just triangles.

So, it's best to triangulate before export, make sure it's the topology you want.



In the past (and currently on low-end devices) you had very few triangles to work with, so careful topology was (is!) important.

Z-fighting is still an issue. I just ran into it today, with pre-baked shadow-planes under meshes... if those are at the same height as the floor mesh, you get z-fighting. You have to raise the shadow planes slightly above the floor to prevent this. It's not about triangle size.

poopipe

zachagreg said:

The way I understand it is that any triangle is rendered 2x2 pixel quads at a time. So you if you have a long skinny triangle those 2x2 quads are going to hit maybe one pixel the entire length of the hypotenuse of the long skinny while overdrawing 3 pixels for each quad. Kind of like estimating a limit going to infinity. Imagine the jaggies on aliased graphics had to be packed into 2x2 squares along an entire edge you'd get a shit ton of wasted space along it. The image below is for a different thing but number 3 kind of illustrates the concept.

Sort of.  

What you describe is wasteful but inevitable so not an issue in itself, what you're missing is that any other triangle covered by those quads causes the quads to be processed again.
Long thin triangles mean more chance of a quad covering many triangles.

sacboi

Man! "Z-fighting" it's been a while since I'd seen or heard mention of it.

Andreicus

This thread went on fire in 1 day, eheh. Anyway for all the people out there that are interested in optimization i was reading this article here: https://jesshiderue4.wordpress.com/real-time-rendering-an-overview-for-artists/ it is clearly explained and helped me out clearing some things.

Thanks for all the feedbacks.

sprunghunt

Eric Chadwick said:

No, the issue is all game engines render their meshes as triangles.

http://wiki.polycount.com/wiki/Polygon_Count

We use quads when modeling because the tools are easier with quads. But in the end, it's still just triangles.

So, it's best to triangulate before export, make sure it's the topology you want.



In the past (and currently on low-end devices) you had very few triangles to work with, so careful topology was (is!) important.

Z-fighting is still an issue. I just ran into it today, with pre-baked shadow-planes under meshes... if those are at the same height as the floor mesh, you get z-fighting. You have to raise the shadow planes slightly above the floor to prevent this. It's not about triangle size.

The kind of z-fighting you get in modern engines isn't the same thing since the zbuffer is per-pixel. The old problem was where entire polygons would draw in front of the other polygon. Now you might get a checkerboard type of z-fighting - it was impossible for only half a polygon to sort badly.

poopipe

sacboi said:

Man! "Z-fighting" it's been a while since I'd seen or heard mention of it.

It's still very much an issue, we've just got more tools to handle it -  depth biasing would solve Eric's problem for example 

Eric Chadwick

Well. I'm dealing with web and mobile. Where precision is generally poorer. It's best I find to not always assume highest end hardware.