Hey, im developing a 1st person game for the PC and i can't seem to find anything online that would really help me in figuring out where my poly counts should be.

• Engine: Unity.
• Platform: PC stand alone.
• Genre: Puzzle Adventure.

One of the core goals is to immerse the player into the atmosphere of the game, so graphics is a priority we're trying to keep.

While we were modeling props we thought are 300 polys really fine for a single door that would be multiplied over the environment?

or a 200 poly window? or if the House the player is going to play in is 5,200?

You did not make a typo ? Did you perhaps mean 300 thousands tris ? Wow, talk about a trip back to the past long gone...

A scene of 5,200 tris, is something that an nVidia TNT2 32 MB card can do. How can I know that number exactly ? Because over 10 yrs ago I had to create a series of 3D screensavers (C++/DirectX) that had to run - emphasis being on the word- fluently on an nVidia TNT 2. Do you have any idea how old that card is ? It was released in 1999. That's ~15 yrs ago !

Hell, even GF2 GTS, that was released mere 13 yrs ago, was giving me fluent framerate for scenes consisting of over 120,000 tris - though I gotta admit,that terrain renderer had some pretty neat optimizations - but still - scene of over 100k tris on GF2.

I can't talk about Unity's renderer performance, so you will have to test that one out, assuming you can even lay your hands on a properly ancient (& still working!) HW of sorts(not implying Unity'd run on TNT, but you get my point).

Now, I know very well it is very easy to write renderers that waste performance.

But to write a renderer that has a problem with a primitive scene of 5000 tris and a couple textures , even on a gfx card 5 yrs old, now that would be a truly icredible feat.

I don't remember the exact model of my gfx card that I have in my computer, it is GF 4XX-series, so it's best yrs are at least 3-4 yrs behind us.

But few days ago, when I was testing some hi-poly meshes, I got myself a scene consisting of over 4 million tris, yet I still got over 50 fps.

And that's with zero optimization - 200 Mil tris per second. I did not play with proper caching of indices, or proper vertex size or proper configuration of multiple vertex streams or anything. It was just a simple brute-force for a short test.

Who, in this day and age, spreads the rumors that a 300-poly mesh could possibly be a problem ? If someone has a phone that can't handle 5000 tris, he sure as hell ain't gonna play your game on it for a very simple reason - 'cause he ain't playing games on his phone at all...

Now, I'm just waiting for the first person to bring the integrated gfx "argument" to this discussion...

Since you are using Unity, and do not have anyone on team who is well-versed with rendering techniques from their implementation standpoint, you just have to experiment with each effect to see what kind of performance implications it has.

Just try to do the benchmarking using the same scene and only disable one effect at a time to get at least remotely reasonable estimate of the costs of given effect.

Don't forget that 5 fps drop at 15 fps is much, much more severe than 5 fps drop at 60 fps (think about the frame-time length and you'll see what I mean).

Another thing worth noting is that adding polys to the scene which is heavy on postprocessing effects is going to have minimal effect on performance, especially at the border fps value as, say, 30 fps - since there is a set threshold of XX% vs YY%, where XX% of shader units are reserved for pixel shaders and YY% of shader units (on your gfx card) are reserved for vertex shaders.

Meaning, you are probably not using the vertex shaders units now - like - at all (the 5% load you're giving them right now does not even count), but you are totally abusing those poor pixel shader units (it is, after all, drop-dead easy to enable a checkbox in Unity)...

Also, there is a big performance difference in adding a single object with 100.000 tris and 1000 objects with 100 tris each. Not sure what kind of a batching Unity does, but it is worth noting.