polies vs post-processing

multivac

I've often heard that videocards nowadays can push almost unlimited amounts of raw tris,post-processing,textures and per-pixel shaders are the expensive stuff.How much truth is there to it in your experience though?
I understand that transforming a lot of verts on a character can be expensive,but what about static geometry with lightmaps and pre-baked lighting?
Normalmapped assets tend to have simpler silhouettes and I just prefer detailed geometry over normal mapping a flat hull.
In short,can I actually model in a lot more detail into world,if I don't use full-screen pixelshaders and normalmaps?

Mark Dygert

AFAIK Most of the poly handling increases have been on the CPU side since procs are going multi core. I could be wrong tho. Also something to keep in mind games scale for hardware so often models, textures and shaders will have several "modes" they can run in to handle even crappy hardware.

As always it depends on the game, the asset, the character, the game play and the placement...

SHEPEIRO

deforming those polys is still expensive. so that puts a limit on characters

sprunghunt

I think you are confusing two different things.

Drawing static polygons takes up memory but is fairly simple to do. They usually don't increase the render time unless they're taking up all the memory they have availiable to them.

Drawing complex shaders has more to do with the fillrate of the renderer than memory. Shaders take up CPU or GPU time depending on the system. Shaders usually take up very little memory if they aren't using any textures in them.

So you can't really trade one for another. A fullscreen complex shader will slow down a scene with 2 polygons in it.

CrazyButcher

might want to look into http://boards.polycount.net/showthread.php?t=50588

its true that static geometry is less costly than animated characters, however in both cases it's a mix of both (vertex and pixel) costs affecting overall. Generally speaking, yes simple pixel shaders and more tris is possible these days.

however rasterization doesnt like it when triangles dont create any pixels at all, ie if you have very small detail that hardly shows up. Hence LOD and so on still applies today. totally depends on the viewing distances...

btw sprunghunt, I would not mix "memory" and "performance" costs. Animated character models and static geometry both can reside in VRAM as "static costs". Because vertex shader transforms the character, hence you can leave vertices of character in vram just like a building or textures.

the cpu time shaders take should be similar to all systems (depending on driver a bit and api), but its more an engine/programmer task to minimize these costs. Depending on system itself of course you will have different execution speed (ie raw performance in the shaders).

shaders always take up very little memory in vram (just a few commands), and textures typcially always reside in memory. So you got your memory cost thing a bit wrong.

you cannot afford to "load" a texture/geometry on demand for most cases today. It will create stalls. Hence engines typically have all data ready for a frame, either by streaming textures in the background or in simpler cases preload enverything.
so the textures that shader uses are in memory already independent, otherwise it would be really bad engine design.

what vig said about multicore is indirectly true as the cpu overhead created with drawing small batches, gets less and less the more power the cpu has spare for the driver/api communication prior to drawing. However if you can manage to minimize drawcalls (ie big batches) then you can draw tons of polys even on older systems & hardware.