Hello ;)

Before all, sorry for my poor english !

With DirectX 11, i'm trying to create a random map full with GPU.

Using Hull shader stage, I'm managing LOD with tessellation.

Using Domain shader stage, I'm generating the map (based on perlin noise).

Now my goal, is to compute normals in the geometry shader (normal on vertex). For that, I must use vertex adjency, like geometry is capable of.

But here is the problem... For tessellation, my primitives must be D3D11_PRIMITIVE_TOPOLOGY_3_CONTROL_POINT_PATCHLIST.

But for geometry shader with 6 vertices(triangle primitive and adjency), I must use : D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST_ADJ.

Think I'm missing something... It must be possible to tessellate and use the results in the geometry shader...

However, it's working with 3 points, but I cannot use the 3 others (they are 0.0, 0.0, 0.0)....

Thank you in advance for any help ;)

The domain shader can only (as of D3D 11.0) output points, lines and triangles - without adjacency information, so I don't think this is possible. Even if, I think it would get tricky at patch edges.

So: you need to do your normals in the domain shader.

Thank you !

Do you think, what is the best (if possible) :

1- Computing normals in Domain Shader, which is slow because I must call the noise function multiple times (adjency vertex based on x offset/delta)

2- Using the stream output from Geometry Shader, and in the second pass, passing the buffer data with "TRIANGLE_ADJ" and computing normals in the Geometry shader

Or any other suggestion ?

1- Computing normals in Domain Shader, which is slow because I must call the noise function multiple times (adjency vertex based on x offset/delta)

2- Using the stream output from Geometry Shader, and in the second pass, passing the buffer data with "TRIANGLE_ADJ" and computing normals in the Geometry shader

Thank you Jason for your answer ;)

Actualy, I load a fixed icosphere to the vertex shader. Which hasn't lot of vertices...

If we think about it as a planet, there wil be only 1 vertex for hundreds of kilometers (or miles :-)) !

So, if the noise is applied in this stage, the interpolation after the tesselator will be too large, no details...

I can load a much more detailed sphere, but, if the camera is very close, there will be the same problem, leak of details (or if far away, much more work for the GPU)..

My goal is to have the same amount of vertices (and noise details), whether the camera is very very close or far away.

Sorry for my poor english, don't know if you understand what I mean...

Again, thank you ;)

Ok, I understand part of what you explain...

Juste one thing I don't understand totaly :

Instead of having a fixed resolution icosphere, why not start with a screen space set of vertices which would be generated based on the current view location?

Can you tell me more about what you mean ?

Don't know if it's the same process.. But in an earlier project, I was using a projective grid.. Some good results but lot artefacts and problems when camera was too close...

[EDITED]

My proposal, have first pass only to tessellate, and the second, using Vertex Shader for computing noise, would not be too much slower I think.. ? And could resolve totaly the problem ? (with a much more detailed sphere as base model to avoid tessellator limits)