5 replies to this topic

[SyntaxError]

Hi guys. I'm finally being forced (I think) to go to DX10 from DX9. What I'm wondering is if it's worth it to go straight to DX11. I think I would have to get a new graphics card. Is there anything really definitive DX11 gives you? For instance DX10 gives you the geometry shader which I need. All I see in googling DX11 is some improved threading capability. Is there anything much else?

Secondly the reason I have to go to DX10 in the first place is to fix Phong shading anomalies. What happens is when I have faces with vertexes that go from roughly concave to roughly convex, the normals for those vertexes end up being close and the face in-between tends to look more flat shaded. I had this idea that I could split each edge in half (i.e. each face into four new faces) but don't move the new vertexes. Then for each new vertex I would generate a temporary normal (call it N1) which is the average of the two faces on either side of it. Finally I would take the normals of the old vertexes on either side of the new vertex, average those to get another temporary normal (call it N2). Then to get the final normal NF of a new vertex I would flip N2 to the other side of N1 such that the angle between NF and N1 is the same as between N2 and N1; only NF just sits on the other side.

When I draw this out in 2D it seems to give me what I want. For flat, fully convex or fully concave areas it gives me normals similar to the average that you would expect, but for zig zaggys areas it kind of simulates a compound curve (at least shading wise) . However before I try this I was wondering is there some standard way people handle this problem? I'm not looking to do some computationally expensive perfect solution; just some approximation that will get rid of the anomalies reasonably cheap.

[Reedbeta]

The other two major features of D3D11 are dynamic tesselation on the GPU, and compute shaders. You can read about these on the web. However, it sounds like your problem can be solved by preprocessing the geometry. It will take some extra memory for the additional verts you add but will also be faster than doing the fixup dynamically in the geometry shader.

[Nick]

DX11 also features DX10 and DX9 profiles. So aside from requiring at least Windows Vista, it's backward compatible with older hardware. This means there's no reason not to go with DX11 if you need DX10 features.

Anyway, if you don't really need DX10 or DX11 features, stick to DX9 to maximize the market and/or save yourself the work of writing two implementations.

It looks like your problem can be solved with just DX9, using a normal map. By storing the normals in a texture instead of at the vertices, you get full control over the curve used for lighting. You can even implement a bump mapping effect this way.

[SyntaxError]

My problem is I’m doing this for terrain which is generated and LODed in real time using fractals. The terrain can get very large; in fact it’s a whole planet so there are several unusual issues. First I generate everything in double precision and copy it to the graphics card in single. This insures I don’t have any tiny gaps between terrain chunks due to rounding errors since vertexes on the edges of chunks that are doubled up go though the exact same calculation. I have heard other people who are doing this strictly on the GPU complain about this problem. It also lets me match the collision model with the graphics model exactly because the algorithm is the same and all calculations are IEEE.

In any case the upshot is there is a lot of copying already going on and it isn’t particularly cheap (I benchmarked it). I do a lot of little tricks to cull the copying of tris. For instance the back sides if mountains and hills aren’t copied and there is a predictions algorithm that determines when to start copying them as the player moves around. Quadrupling my tris is a big hit especially since I’m not going to release this any time soon. My guess is DX9 will be a distant memory for most gamers. On the other hand since the graphics card has a lot of power this seems like the perfect place to do this. Compared to procedural shading (which I’m also implementing) it’s a tiny fraction of the calculation.

[imerso]

Better using normalmaps for lighting.

Another thing, generating the fractal in GPU is a lot faster than in CPU. That is dozens and more faster. As always, this is the reality for today, and does not mean will be this way in the future.

[SyntaxError]

I’m not sure I understand. I thought normal maps were more like a texturing detail. I need to generate the normals for the basic terrain.

Also Fractals may be faster on the GPU but there are a myriad of reasons why this seems more problematic for me. A lot of them have to do with matching the graphics engine to the physics engine. In practice I find the CPU fractals are fast enough. LOD doesn’t have to happen every frame. Even once a second is fine for typical MMO applications. In fact I need time to alpha fade in the new terrain so I’m not even sure it gets me much doing it faster and it takes time away from GPU texture fractals.