Sign in to follow this  
doodo

Polygon count v texture count

Recommended Posts

Hi I have this small question that has been on the back of my mind since I’ve started doing 3D programming. Recently with a most of the new games coming out, a lot of emphasis have been put on pixel shader models 2.0 and 3. This includes bump mapping with direct shadows and new technique that are coming out. It seems a large process of the development work and also hardware is focused on improving the texture quality and the amount of memory available on graphics card with extra pipelining and optimisation. But, I haven’t seen any major increase in the amount of polygon’s cards can actually pump out these days. You have vertex processors on the GPU to lessen the effect of the CPU. Main question, why is that a large amount of work is being devoted to new texture and pixel shaders, when polygon counts are still needing to be relatively low? Is the expense of high polygon count with high texture count too large of a computational load on the cpu or gpu? The best example I have is if you look closely on new upcoming games you can identify very pointy surfaces on the model itself where it has low polygon count. But the designers use a very large hybrid of texturing technique that makes the model look high polygon. It’s my understanding that we’re using texture to substitute the low polygon crunch of gpu or cpu instead should be calculating a lot of normal maps from the polygon themselves.

Share this post


Link to post
Share on other sites
It has to do with the amount of scene complexity. When quake first came out, it was in sharp contrast with Doom in terms of the number of actual creatures that could be displayed at once.
As we add in the more objects like trees, people, we are still looking for methods that can reduce the polygon count so we can have more things happening and more different objects on the screen The normal mapping is an off-line method to take a 30,000 polygon creature and turn it down into a 10,000 polygon hit.

Share this post


Link to post
Share on other sites
Thanks for the answer ZoomBoy.

I guess its one of those questions that stair you straight in the face, but you don't notice it.

:)

Share this post


Link to post
Share on other sites
From what I've seen, we can already push quite a large number of polygons, but a couple of 2048x2048 textures are enough to choke the graphics card. From that point of view, the wanted improvement of texture handling is an understandable proposition, is it not?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Vertex processing is no longer such an important topic. Take a look at the new GPU generations:
- unified shaders (each shader can be used as fragment or vertex shader => G80,Nvidia)
- like textures, vertex information are saved in video memory

So, do some simple math:
Take a expensive fragment shader for a fullscreen render at 1024x768. It will be called 768k times. Nowadays fragment shader do the same things like vertex shader, namely processing data. So there aren't any diffenrences any longer. So if a fragment shader can process 768k pixels, a vertex shader will not have any problem to do the same,namely processing 768k vertices per frame.

Ok, to be honest, I just break it down to processing power. An additional matter you have to consider is , that this calculation only works if you leave all the necessary vertex data in GPU memory. But games like doom/quake uses volume shadows which needs a lot of vertex processing on the CPU. They limit the number of vertices to reduce the impact on the CPU.
Other matters have to be considered: Once a unreal developer said, that they reached the upper polygon limit, why should I render a 10000 tri model if 4 tris shares one pixel on screen ?
The next generation of DX10 GPUs will introduce programmable geometry which will result in displacement maps. When this happens, vertex shaders will be more important and that's the reason you will need more of them(what will be no problem cause of unified shaders).



Share this post


Link to post
Share on other sites
Currently batch numbers are somewhat more important than raw polygon counts--10,000 1-triangle models are much slower than 1 10,000-triangle model.

About displacement mapping: i dont see any real use for this in real-time games except for certain special effects.. normally it is better to make an optimzed model with any displacement done in the modelling package. I think it wrong-headed to assume that displacement mapping will have a big impact.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Displacementmapping will have a big impact:

Today bump,normal,parallax mapping is used on consumer hardware. The result is good as long as you have the right view angle to the surface you are looking at, else it still looks flat. And there's the problem of shadow casting, bump/normal/parallax mapping can't cast shadows (in a easy and performance way).
Displacementmapping will get rid of these problems, introducing high level of geometry detail with good lod management and low memory consumption.

Share this post


Link to post
Share on other sites
I still doubt it, because you seem to suppose that all models will be made of dynamically tesselated patches, right? This just doesnt seem like a good solution anytime soon.

Because for displacement mapping to work you need a very high tesselation, and to me this doesnt seem any better than using high poly meshes, because ultimatly they need to tesselated and sent into the pipeline. Also they will only work on more or less regular surfaces.

Am I being pig-headed here? I do think displacement mapping could work with some kind of terrain LOD system. But still you need dynamic tesselations.



Share this post


Link to post
Share on other sites
Ok, I was the anonymous poster.

Let's take a look at mega textures (terrain rendering with unique and really large texture). It will consume a few gbytes of memory so dynamic loading is a must have. To improve the visual depth of the terrain you could use the following techniques:

1. Use a higher geometry tessalation level, but this will consume enormous amounts of memory for geometry data (position data, tangent space data for normal mapping).

2. Use normal/parallax/bump mapping, but this looks only good if you got the right view angle to the surface, else it still looks flat.

3. Use displacementmaps instead of normal/parallax/bump maps, it will only consume little amount of memory (a height value stored in a texture), casts shaodows (!) and could be used with a very high level of detail.

--
Ashaman

Share this post


Link to post
Share on other sites
Bump Self Shadow can be quite simply emulated by Horizon Mapping. At least for wall textures such as the common "rough stone" texture. Even a four directions approach did a good job for us and used only about 30% more rendering time than a parallax mapped fullscreen without it. I can supply a little testapp, if you want to see for yourself wether it fits your aims. For my personal taste, this is enough.

Parallax Occlusion Mapping is a horrible waste of resources. If you have objects which need this method, you propably go for real displacement mapping instead. DX10 and its limited subdivision capabilities might be able to help there.

Bye, Thomas

Share this post


Link to post
Share on other sites
Quote:
Original post by Ashaman73

3. Use displacementmaps instead of normal/parallax/bump maps, it will only consume little amount of memory (a height value stored in a texture), casts shaodows (!) and could be used with a very high level of detail.

--
Ashaman


But the terrain still has to be very highly tesselated for displacement mapping to work, its not magic right?

In any case, geometry doesnt take up much memory at all anyway, textures take up far more, so in fact the giant displacement map you would need is probably more memory than the hihg poly model...

Share this post


Link to post
Share on other sites
Quote:
Original post by Matt Aufderheide
But the terrain still has to be very highly tesselated for displacement mapping to work, its not magic right?

Why do you need a very highly tesselated terrain for displacement mapping ? Terrain as 2d plane with height information would be perfectly fitting for displacement mapping, wouldn't it ?

Quote:
Original post by Matt Aufderheide
In any case, geometry doesnt take up much memory at all anyway, textures take up far more, so in fact the giant displacement map you would need is probably more memory than the hihg poly model...


No, I think you're wrong here. It's a matter of detail. Yes, a displacement map which has 10x more detail like a tessalated terrain will require more memory, but in a situation where you have the same level of detail, a vertex will consume more memory (you need data for x,y,z) compared to a heighmap value(only 'y' is needed).

Simplified example:
1. Terrain with displacement map:
- 1 quad: 4 vertices = 4*3 floats
- heighmap, 16x16: 256 floats
- memory consumption: 268 floats

2. High poly terrain with same level of detail !
- 16x16 vertices = 256 * 3 floats
- memory consumption: 768 floats

--
Ashaman


Share this post


Link to post
Share on other sites
Displacement mapping can only displace existing vertices, so if a mesh doesnt have enough vertices, the displacement mapping wont be useful...You cant generate vertices from nowhere (unless you use use some dynamic tesselation, which has a whole host of problems).. DX10 will be great but I doubt it is magical..

Share this post


Link to post
Share on other sites
Sorry to barge in, but one of the biggest features of Direct3D 10 is in fact the combination of the geoshader + stream output. nVidia demonstrates this immense power with a low poly model that gets tessalated into a highly detailed object (go see the tech on their new G80s). So in your view, D3D10 is clearly magical :-).

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
@matt:

the geometry-shader can add new vertices. thats the great thing of d3d10.
and the added vertices are even faster than the others.
this is because they "appear" right before the pixel shader executes, they are not pushed through the whole pipe.
and the additional vertices dont need too much memory: they "spawn" and "die", every frame.

Share this post


Link to post
Share on other sites
Quote:
Original post by Matt Aufderheide
Displacement mapping can only displace existing vertices, so if a mesh doesnt have enough vertices, the displacement mapping wont be useful...You cant generate vertices from nowhere (unless you use use some dynamic tesselation, which has a whole host of problems).. DX10 will be great but I doubt it is magical..


Yes, you're right and I'm right too ;-). The problem is the term 'displacement mapping'. There isn't a clear definition of 'displacement mapping' in CG (wikipedia).

What I mean is, like the two previous posters already said, that the new generation of GPU is capable to create vertices on-the-fly. This could be used to do the following:
- Create a low-poly model and a texture containing height data.
- Let the GPU create a high-poly model from this low-poly model and the given texture.

Some renderes can do this in software. Instead of rendering the low-poly version, these renderers create a high-poly version from the low-poly model and a given 'displacement map' on-the-fly. This approach is not adequate for real-time rendering systems, because it is slow or it consumes too much memory (you have to keep a high-poly version of your model in memory).
But the new generation of GPUs can do this 'pre-processing' on-the-fly and much faster than a traditional CPU+GPU combo.

Share this post


Link to post
Share on other sites
Thats interesting, thanks for the clarification.

I wonder how this geometry shader can actually work, it seems like Meshes will have to be stroed/cread as a new tpy eof data, perhaps for it to work they need to use patches or nurbs or some such?

Or can it really take a polygonal(triangles only) mesh and create new vertices without damaging skins and animations, and ALSO generate tangent data on the fly? This is remarkable if so...

Share this post


Link to post
Share on other sites
As far as I know there will be a new shader in the pipeline:

application => vertex stage => geometry stage (NEW) => fragment stage

The geometry shader can do the following things:
- Works on primitives (i.e. tris)
- Can create additional vertices/primitives.
- Streaming

It is a very powerful feature, i.e. "displacing mapping" or "fur shader" could be implemented more easier and with hardware support.
Currently only DirectX10 supports this new kind of shader. NVidia/ATI will probably introduce new extensions to access it through OpenGL.
At the moment only the new G80 (NVidia 8xxx) supports this in hardware, ATI will release hardware support next year.

In combination with unified shaders the next generation of GPUs will be wonderful toys ...

--
Ashaman

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
and another new thing is, that you can communicate with the memory.
you have access to the textures in all shaders.
and you can go backwards in the pipe:
nowadays you would e.g. render sth to a texture and then begin another pass to use the result. with d3d10, the geo-shader can access memory directly (streaming), and the result can be "reinserted" into the pipe without concerning the cpu.
also, calls to the api are faster: a draw call e.g. takes only about a tenth of the time it took in dx9.
and of course, there are more instructions you can use (64000 i think), and more constant and temp registers.
not to forget the new instancing: when you have 1 model, the geoshader can make 100 of it and they all can have different animation states, positions, and much more. think of all the rts-units that you can duplicate, thousands of units can be rendered, all highly detailed and fighting each other.
or nature scenes with ten thousands of grass and leaf objects, all seperately animated.
thats gonna rock !

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
nowadays you would e.g. render sth to a texture and then begin another pass to use the result. with d3d10, the geo-shader can access memory directly (streaming), and the result can be "reinserted" into the pipe without concerning the cpu.


Wrong. The streamed out geometry goes into a seperate buffer, but the CPU still needs to bind that buffer and issue and new rendering call after its done issuing the stream out pass. Re-circulating data will still involve another API call.

Quote:

also, calls to the api are faster: a draw call e.g. takes only about a tenth of the time it took in dx9.


This is primarily due to moving the fact that the graphics driver has been moved into user-mode from kernel mode. This will make DX9 draw calls faster as well.
EDIT: Also, though I haven't tested it myself, I seriously doubt that MS will acheive the 10x speedup that they're promising. I'm guessing it will be more like 3-5x.

Quote:

not to forget the new instancing: when you have 1 model, the geoshader can make 100 of it and they all can have different animation states, positions, and much more. think of all the rts-units that you can duplicate, thousands of units can be rendered, all highly detailed and fighting each other.
or nature scenes with ten thousands of grass and leaf objects, all seperately animated.
thats gonna rock !


There are dedicated instancing APIs in D3D10 for this purpose, which are much more efficient than doing it in a GS (D3D9 had them too).

Duplicating geometry in a GS and applying seperate transforms, for any reason, is a bad thing, because you won't be taking advantage of the post-transform vertex cache. This means that every vertex on every instance will be transformed once for EVERY triangle that references it (probably about 4-6 times). This is one of the major problems with Microsoft's single-pass cube map idea.


JB

Share this post


Link to post
Share on other sites
Quote:
Original post by Ashaman73
Currently only DirectX10 supports this new kind of shader. NVidia/ATI will probably introduce new extensions to access it through OpenGL.


NVidia already support it though OpenGL - even under XP. Additionally, if you've got a pre-G80 NVidia card you can use NVEmulate to enable software emulation of geometry shading - so you can play about with them whilst you're getting a second mortgage/selling your first born child/etc to get the money together to afford a G80 card. [grin]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this