![]() or use tessellation to a certain point, then replace it with a high detail mesh. So when smooth LOD is a big concern then definitely go with tessellation. One big thing to consider however is that slowly turning up the tessellation as an object gets closer, looks way better than instantly replacing a low detail mesh with a high detail mesh. But a high detail mesh in the foreground takes up less compute time than a tessellated mesh with tessellation turned up. A high detail mesh in the distance is burning up more compute time then a tessellated mesh with tessellation turned off. So tessellation is always a good idea for improving detail on dynamic/instanced meshes.īut for static meshes or singleton meshes, its a trade off between LOD capability and pipeline complexity. ![]() However if you turn the tessellation down or off for LOD purposes it SAVES shader time for objects that don't need detail, compared to a high detail static mesh. This eats up shader time that would not be needed if you used static mesh. But this calculation is performed every frame for each tessellated vertex. So it calculates the extra data on the fly. Because the displacement map is normalized against adjacent vertices. But sampling a displacement map uses 1 coordinate of fixed point data to be useful. Because vertices need 3 coordinates of floating point to be understood by the gpu. There is a slight memory bandwidth perk you get by using tessellation for static meshes. Tessellation would just add complexity and eat up cycles in the pipeline. If you have a high detail static mesh that never moves and only have one instance of it on the screen, then it is faster to upload the geometry in full detail. The major distinction you need to watch out for is that this only helps you when you are instancing and/or animating geometry. Why you should not use tessellation: To add this detail on the fly the gpu has to burn up processing power in order to calculate the 3d position of each tessellated vertex before it starts running all the other shaders. Now imagine you have 20-30 of these sprites on screen at a time. The end result is that you get 2-4x the mesh detail with 1/20th the memory bandwidth. you update the 50k mesh for animation and reload significantly less mesh each frame, then the GPU tessellates up to 4-5 million virts using the displacement map which is already loaded. Then you store the displacement map on the gpu once. However if you use a low detail model (50-100k vertices) with tessellation and displacement. If the sprite is a high detail (1 million plus vertices) then each time the animation routine moves/deforms the mesh, all 1 million vertices are transformed and reloaded to the GPU each frame. Lets say you have a sprite that is running across the screen. But its not very useful for static single objects. Tessellation with displacement maps significantly reduces memory bandwidth for animated or multi-instance objects in the scene. Tessellation is a way that you can save memory and bandwidth but at the cost of GPU performance. You shouldn’t be able to see any difference.There's always a trade off between processor and memory. Then replace the ocean out after something close to 50m to a solid slice with texturing. On low end systems make the last LOD a single vertex. ![]() OBVIOUSLY you have to use instancing, if you create non-instanced assets the rendering pipeline will get shredded by draw calls. On top of having something that will work on any engine regardless.Īs sizing goes, I suggest 10m^3 tiles with 30 sub divisions for a total of 120tris each tile. You balance an overall number of tris out with the rendering budget and you get decent to great results without any issues. Provided the edge vertex count is the same, your lowest LOD will have:įor example, a square with 2 subdivisions, 4 vert on edge, will have 16 tris. They aren’t necessarily the best possible break-down, it’s all variations on a theme anyway. You can see all the LODs in the shared clip. You create the lower level LOD first, then you add more and more divisions intelligently so that your edges of ALL lod(s) have the same number of vertices. The idea is to reduce the overall tris count of distant LODs without compromising quality or creating seams during transitions. ![]()
0 Comments
Leave a Reply. |