DirectX 11.1
- Thread starter Demirug
- Start date
Our first experiences of HDR were pretty hit and miss. Don't let Crysis 2 and other mediocre implementations spoil it for you.
Tessellation has a lot of potential beyond the "hey, now I have a brick wall with a displacement map and 1m triangles!" stuff. If we use it right we should be able to be smarter about where we use our triangles, and end up with better quality without dramatically increasing the overall triangle count. There's also potential to be way more efficient with regards to memory and bandwidth for complex meshes.
My concern with it is that currently it seems like:
1) An efficient implementation lacks fidelity (sliding verts, warped artifact-ey textures)
2) A proper implementation either lacks performance (using fragment shaders to police the tessellation induced distortion is slow) or flexibility (basically, you're just hand coding an overly complicated lod system that can't be hand-tweaked), or both.
I also think it's possible to develop a tessellation solution that suffers from all of these flaws simultaneously.
I'm hoping people come up with good ways to use it, in theory it sounds fantastic (and it is good for water
). But seriously, how long until more powerful hardware renders it moot anyways. Pun intended.
That doesn't really make sense. If you opt not to use tessalation and instead render those millions of polys brute force you are going to have less processing power for everything else. What's the point? Just learn how to use tessalation.
The point is that tessellation is not really that straight-forward. Why would you introduce noise to the image by lerping and filtering verts if you have enough juice to just apply more traditional displacement mapping.
Vertices. But I haven't phrased things well, "traditional" was a funny choice of word. I was speaking specifically in terms of DX11 style adaptive edge sub-divide tessellation, and of benefits of which, I am skeptical. But I don't know, we haven't seen a big AAA developer really throw a lot of resources at the new geometry features, and it may be great. I just don't expect a magic bullet lod solution.
Tessellation is capable of so much more than just rounding off boxy edges and making brick walls look pretty. That being said, I think we won't see the true benefits of tessellation until games are made that assume tessellation is a baseline feature. Of course on PC it would be suicidal to only support DX11 hardware, so we'll have to wait for the next gen consoles before tessellation really takes off.
Tessellated DOAX3 :O
My concern with it is that currently it seems like:
1) An efficient implementation lacks fidelity (sliding verts, warped artifact-ey textures)
2) A proper implementation either lacks performance (using fragment shaders to police the tessellation induced distortion is slow) or flexibility (basically, you're just hand coding an overly complicated lod system that can't be hand-tweaked), or both.
I also think it's possible to develop a tessellation solution that suffers from all of these flaws simultaneously.
I'm hoping people come up with good ways to use it, in theory it sounds fantastic (and it is good for water
Obviously there are issues to work around, but there's no reason to think that they're insurmountable. A lot of the issues are really just on the content side of thing...you're obviously not going to get great results unless assets are authored specifically for whatever tessellation-based methods they'll used at runtime. But that's the same for just about any other graphical technique you can think of.
If you're going to wait around for more powerful hardware to solve your geometric quality issues, I think you're going to be waiting around for a long time. Bandwidth on GPU's is not scaling up at nearly the rate ALU is, which means if you're going to just keep scaling up the number of verts it's going to become more and more inefficient. It makes no sense to store 500k vertices when most of them can be generated from higher order surfaces, or can be derived from compressed, mipmapped data in a displacement map.
Is there any reading material for tessellation (aimed at idiots)
especially stuff concerning how does the gpu/game decide where to add polys
i could add triangles to a chair and turn it into a tree how is it decided what shape these new polys form
or is it just used to smooth out curves ?
edit: my little investigations show the tesselator gets its cues from a displacement map (am I right?)
especially stuff concerning how does the gpu/game decide where to add polys
i could add triangles to a chair and turn it into a tree how is it decided what shape these new polys form
or is it just used to smooth out curves ?
edit: my little investigations show the tesselator gets its cues from a displacement map (am I right?)
Yeah I don't want to sound like I'm passing judgement on it, especially in it's relatively nascent state. And I definitely didn't want to sound like I think displacement mapping in general--bump-mapping, POM, and so forth--is gimmicky. I was more speaking to the current state of DX11 hardware tessellators. So for example, I am not suggesting "brute-force", raw poly-crunching as a desirable solution. I can write a fragment shader to displace based on a fixed-resolution normal map without ever touching the tessellation units.
So what's interesting to me going ahead is do you imagine the IHVs and MS running with HW tessellation to the point where it subsumes the current geometry pipeline? Or could you imagine a scenario where by the time the next gen consoles are really being pushed hard the bigger problem will be dealing with the amount of sub-pixel triangles they can produce? I don't know, but while I agree with you that bandwidth is not scaling as fast, and will not, I still think we have yet to see what can be done with the amount of bandwidth today's higher end cards have.
Vertex based tessellation works perfectly if you are adding detail to smooth surfaces. However it's not that great for surfaces that have sharp details.
For example, it's hard to get basic cobblestone roads to work properly with just vertex based tessellation/displacement. When the road is far away you cannot render road patches with more than a few triangles. Continuous tessellation will start adding vertices and sliding them along the road when you get more near it. You will clearly notice vertices frantically going up and down as they move along the uneven road surface. Same happens if you try to use tessellation on object surfaces with sharp details (for example shipping containers in our game). To solve the crawling issue, you either have to put more vertices to the main mesh according to the bump shapes (pretty much impossible with terrain rendering) or you have to tessellate all the way down to 1:1 vertex/pixel density in screen. All GPUs render triangles in 2x2 tiles (skipping excess pixels). If you subdivide down to 1 pixel polygons, you will lose 75% of your pixel shader performance, and you will be heavily triangle setup / vertex shader bound as well. It's just a very bad way to use the hardware resources.
Pixel based tessellation techniques always result in 1:1 perfect result, no matter how near or far the surface is. No wobbling can be seen and the lod transitions are perfectly smooth with the standard hardware mipmapping. DX11 introduced conservative depth culling, so you can write the depth also from the pixel shader painlessly (without losing hi-z optimizations). The new cone step mapping variants and quadtree displacement mapping variants are really fast and provide very good image quality. Some developers have been using QDM on Xbox 360 as well, so it should be no burden for the new DX11 hardware (more than 10x shader thoughput).
Vertex tessellation is very good for loosely approximating surfaces and making object lod level changes less visible, but it requires lots of content pipeline and content creation changes. You can't just simply modify your content creation tools to do tessellation exactly the same way you programmed it in your engine. If you need some extra patch/vertex input data for your tessellation shaders, the current content creations tools are not going to provide you it. You might need some custom tools to get everything work the way you (and the artists) want it.
For example, it's hard to get basic cobblestone roads to work properly with just vertex based tessellation/displacement. When the road is far away you cannot render road patches with more than a few triangles. Continuous tessellation will start adding vertices and sliding them along the road when you get more near it. You will clearly notice vertices frantically going up and down as they move along the uneven road surface. Same happens if you try to use tessellation on object surfaces with sharp details (for example shipping containers in our game). To solve the crawling issue, you either have to put more vertices to the main mesh according to the bump shapes (pretty much impossible with terrain rendering) or you have to tessellate all the way down to 1:1 vertex/pixel density in screen. All GPUs render triangles in 2x2 tiles (skipping excess pixels). If you subdivide down to 1 pixel polygons, you will lose 75% of your pixel shader performance, and you will be heavily triangle setup / vertex shader bound as well. It's just a very bad way to use the hardware resources.
Pixel based tessellation techniques always result in 1:1 perfect result, no matter how near or far the surface is. No wobbling can be seen and the lod transitions are perfectly smooth with the standard hardware mipmapping. DX11 introduced conservative depth culling, so you can write the depth also from the pixel shader painlessly (without losing hi-z optimizations). The new cone step mapping variants and quadtree displacement mapping variants are really fast and provide very good image quality. Some developers have been using QDM on Xbox 360 as well, so it should be no burden for the new DX11 hardware (more than 10x shader thoughput).
Vertex tessellation is very good for loosely approximating surfaces and making object lod level changes less visible, but it requires lots of content pipeline and content creation changes. You can't just simply modify your content creation tools to do tessellation exactly the same way you programmed it in your engine. If you need some extra patch/vertex input data for your tessellation shaders, the current content creations tools are not going to provide you it. You might need some custom tools to get everything work the way you (and the artists) want it.
So for example with tessellation I could subdivide the rectangle below as many times as I want
But no vertices's would ever be created outside of the lines in red ?
So for example with tessellation I could subdivide the rectangle below as many times as I want
But no vertices's would ever be created outside of the lines in red ?
You can translate the additional triangles in any way you want.
well only being able to divide existing triangles means you cant add geometry doesnt it ? (doesn't matter how many time I subdivide a triangle its still going to look like a triangle)
for example I cant tessellate a cube into a sphere
no idea what topology means (although the animated coffee cup gif on wiki's topology page suggests i can) i'm confused
this is what the free disctionary says about topology
The mathematical study of the geometric properties that are not normally affected by changes in the size or shape of geometric figures. In topology, a donut and a coffee cup with a handle are equivalent shapes, because each has a single hole.
so is a human figure with a hole in their head the same as a donut because each only has a single hole (very confusing)
for example I cant tessellate a cube into a sphere
no idea what topology means
(although the animated coffee cup gif on wiki's topology page suggests i can) i'm confused this is what the free disctionary says about topology
The mathematical study of the geometric properties that are not normally affected by changes in the size or shape of geometric figures. In topology, a donut and a coffee cup with a handle are equivalent shapes, because each has a single hole.
so is a human figure with a hole in their head the same as a donut because each only has a single hole (very confusing)
