Hi, great looking shots, and a very interesting idea!

I have some questions about this technique, if anyone would be kind enough to discuss them. Apologies if I''ve misunderstood anything - I had never heard of it until I read this thread.

First, am I right in thinking that it''s essentially an adaptive tesellation technique, which uses the projections implicit knowledge of the scaling due to perspective to provide the ''right'' density of vertices at a given depth (after tranformation back to world space)?

Second, if this is the case then while the technique could be expected to produce meshes with an optimum ''vertex density'' at a given distance, it cannot be expected to select a truly representative vertex from the heightmap. EG if the vert''s actual position comes from a simple sampling / interpolation of the heightmap, then the selection is essentially similar to a very simple LOD technique like geomipmapping - nothing is there to make sure the selected vertex is the most representative in the area. This could lead to some bad pops with fast motion, I think.

I can see how this is not too much of a problem for water, as it is always in motion anyway, so the pops wouldn''t be as noticeable (if at all), but for terrain I think it might be too much. That said if it''s fast enough that you can have a good level of detail into the distance, it may be hard to notice it anyway. Maybe there''s scope for a hybrid method which uses the projected grid to get a distribution of vertices, then matches them to close vertices from an appropriate LOD heightmap (ok, I need to think this through more)

Next, I''m fairly sure glslang (and probably other shading languages) allow vert shaders to read from a texture. I can see that this may be too basic for nice water (as you''re doing more than just displacing a mesh by a precalculated heightfield, you''re actually generating the heightfield too, right?) but it would work fine for terrain I think. That way it''s essentially displacement mapping with the projected grid controlling tesselation.

Again, appologies if ignorance has lead to me talking gibberish ;¬)

Dan Groom

Hi Claes,

You''re right about the hybrid idea. I would indeed pop anyway, but would maybe give a more representative vert. Probably not worth it.

Further reading revealed that texture reads in a vertex shader aren''t mipmapped (eg you just get the base texture) so it wouldn''t work in a vertex shader without manually selecting mipmap levels anyway.

I''ve no idea if the texture read is done solely in hardware, but you''re probably right - I haven''t found any evidence of people using texture reads in vertex shaders in a while''s googling so chances are it''s a wait for the next gen thing, as you said before. Funny though, I thought matrox had pushed hardware displacement mapping a few yearts ago, which I would have thought would be done as a texture read.

Thanks,

Dan

Just as an aside. I started getting into GLSlang recently, and had a look through the specs. At this point, vertex shaders CAN read textures, but they ALWAYS use the base level. You cannot set them to read other mipmap levels. Of course fragment shaders use the correct mipmap level.

quote:Original post by rick_appleton
Just as an aside. I started getting into GLSlang recently, and had a look through the specs. At this point, vertex shaders CAN read textures, but they ALWAYS use the base level. You cannot set them to read other mipmap levels. Of course fragment shaders use the correct mipmap level.

Quite right, but I didn''t mean setting them to use different driver generated mipmap levels, but creating your own in a pre process and just binding them as 3 (or so) seperate textures. Any idea if the texture reads are done in the current pass or if it''s a readback thing? From what people have been saying (and lack of evidence to the contrary), it sounds like a slow copy.

quote:Original post by vember
I see. But this wouldn''t have to be a problem if a generated heightmap is rendered (with mipmapping an post-blurring) to a texture first and read on the vertex-shader in another pass. If the vertexbuffer is of the same resolution as the texture it would be a perfect match and no filtering would be required. The upcoming OpenGL extension überbuffers should allow writing into vertexbuffers as if it were a texture, which would make it all possible on the current hardware generation.

Yes, definately. I suppose I keep looking for ways to use it for pregenerated heightmaps in a vert shader, expecting there to be a nice fast way to do it in one pass (materials notwithstanding). Looks like my instinct is wrong

Ah, right so uberbuffers imply there is a hardware path for a texture read for vertex shaders (even if it''s done per vertex buffer / heightmap, rather than per vertex in a vert shader)? Roll on the next gen of drivers then

Anyway, I''m off to read the ARB notes for hints

thanks guys