what is roughly the maximum acceptable tri count for a huge hero asset in a game environment?

Travis C

Was wondering what the tri count would be for lets say a huge sci fi door, 3 stories tall, with mechanisms and stuff on it, in a first person shooter.

I know similar questions have been asked to the death in the past, but they are usually for characters or guns. If anyone can say some specific examples in games today, that would be really helpful. Like for example those huge Destiny Cabal metal doors or something similar. 

thanks!

oglu

its hard to see the silhouette on doors... with good planning and ace normalmaps you could do that really low... like 10k.... if there are a lot of round elements and pipes you need more... if its the only thing on screen go crazy up to 200k or more.... its hard to say without to know more about the project...

Travis C

oglu said:

its hard to see the silhouette on doors... with good planning and ace normalmaps you could do that really low... like 10k.... if there are a lot of round elements and pipes you need more... if its the only thing on screen go crazy up to 200k or more.... its hard to say without to know more about the project...

thanks, that helps abit. it is for a third person shooter game made in ue4. i guess there are like 10-20 enemies out at any given time.

defragger

as many tris as needed and no more than necessary for a good silhouette.
Could be done with 5k or 50k depending on the look.
Maybe you can post some concept art of that door?

0xffff

How long is a piece of string? 

Joopson

defragger said:

as many tris as needed and no more than necessary for a good silhouette.

I want to bring up something here that I think is important. It isn't all about silhouette anymore.

What I mean is, when working with normal maps, the polygon distribution is important if you want good shading. So while you need enough tris to make a good silhouette, you also need enough that are properly placed to get good shading.

This may mean you need more than you'd need just to get a good silhouette. A door for instance; sure, you could use a 6 quad box, but you'll probably need more than that if you want a nice clean bake from a high-poly.

0xffff

Or you could just put the effort in to do your bakes properly, ala "using a synced pipeline" or whatever people like to call it. There's no reason you should need to add geo to a lowpoly just to make it shade better if you're doing everything correctly.

Joopson

Synced workflow is a little more complicated than that. It doesn't just make the normal map work automatically. There are still proper and improper techniques.

Adding geometry limits the strength of gradients within the normal map (because the map doesn't have to compensate so much for the mesh's built in tangents), even in a synced workflow. This means less obvious banding in the resulting normal map, especially if the engine puts it through some intense compression.

I'm sure someone else could go further in depth, from the tech perspective.

But I know my own experience, even when using a synced workflow, is that you do still have to pay attention to the geometry if you want the best results.

defragger

Joopson said:

Adding geometry limits the strength of gradients within the normal map (because the map doesn't have to compensate so much for the mesh's built in tangents), even in a synced workflow. This means less obvious banding in the resulting normal map, especially if the engine puts it through some intense compression.

adding extra geo is the easy way.

There really is no need for extra geo. Make sure the silhouette of your low-poly and high-poly are matching. Not just turbosmooth the HP. And use custom vertex normals on your LP.

0xffff

And/or use split smoothing groups / UVs etc

Joopson

Use all those things in addition to extra geometry, is what I'm saying (except, maybe, custom vertex normals, because those take more time, in my experience, to set up, and can break much easier when bringing it between programs (which isn't so much an issue for personal work, but can be a huge problem in production)).

Quack!

Adding geometry via chamfers, like Joopson has been saying, is by far the best way. You get a very nice silhouette and a similar vert cost to splitting edges. Letting your 90-ish degree corners go on 1 smoothing group because of a synched workflow is fine, but causes horrible gradations that compress very, very poorly.
And again, seconding what Joopson has said, unless you have some nice tools, custom vertex normals are hell to deal with. This is remedied with good tools though.

The difference in using workflows from production and personal work is huge.

defragger

well its not like the world will stop spinning when extra geo is used. True!
The increase in Vertex count by chamfers is not significant. Also true!

Spoon

@Joopson
I totally see where you are coming from. I just want to chime in, that with split normals you can add support loops, bake, then remove support loops - and win!
The support loops will kill gradients in the normal map, and the mesh will still look the same when you remove the support loops, if it is for example a 90 degree corner with a smoothing grp split.
So you get best of both worlds, low poly count, AND no gradients in the normal map.
If you add these loops in a new edit poly modifer and rename it "Support loops YOLO" its easy to just kill it again, once you baked.

I was scanning the thread quickly, might have missed this was being said.

0xffff

To be fair I think if you end up with huge gradients in your normalmaps you've probably done something wrong anyway. 

Obscura

Well... To be clear, if you add supportloops to reduce gradients, and bake with that, then your normal will be baked compared to the shading of that so basically if you remove them, youll get errors. You know, when you bake, your baker will take the vertex normals of the lp into account ...For me, adding bevels works fine. It gives better silhouette and increases the tri-count just a bit, and nowadays geometry is cheap so i don't see the point to not add more geo if it gives better result. And it does give...

A hero asset poly-count can vary based on size, distance from camera etc.  On vehicles, sometimes you can even see hundred thousands of polygons nowadays, which still doesn't mean that you should do this on every single mesh, but you can obviously do it on very important things.

Also DX12 should bring a bit change in this question.