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

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.

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

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