USES modules performance consideration
Performance issues are interconnected but having general models for approaching an issue helps isolate key variables.
Remember your effect is not the only thing consuming your system GPU’s resources.
Debugging models to think about
- Shader Complexity vs Geometry Complexity
- Reducing draw calls
- Model having less hierarchy with submeshes (ideally it should only be a complete mesh)
- Memory footprint
Shader Complexity vs Geometry Complexity
- Quick check: try different resolutions:
- if the performance drops considerably on higher resolution that might indicate shader complexity.
- Take e.g, the volumetric galaxy in uniview.
- Generally what this means is that more work is done per fragment.
- The more geometry there is, the more work done per vertex and subsequently per fragment.
- Case in point: compare the performance of Hubble vs ISS in Uniview
Reducing draw calls
- GPU receives a drawcall from the system with a primitive (triangles), shader to use on them, GL states attached to that draw call. That has an overhead.
- USES draw call means a substantial overhead on top of it (with various marshalling of parameters that are required in the specified shader).
- The more submeshes a 3D model has, the more USES draw calls, the more overhead.
- Case in point, ISS used to have approx. 700 submeshes and in domeview, the model was drawn 4 times plus a shadow pass resulting in 2800 or so drawcalls. Now it has only 16 submeshes and the performance is noticeably fast.
- Try to make meshes with fewer submeshes. Why not only 1, with Texture Atlases for materials.
Memory footprint
- Texture Memory
- Use .dds files for textures.
- It has compressed formats.
- The size on disk is what you get in memory.
- .jpg maybe compressed on disk but it is not compressed on the GPU! So a 2kx2k RGBA texture might be a few KB on disk but will be 16 MB in memory (and that is assuming there are no mipmaps!)
- Use .dds files for textures.
- Vertex Memory
- Try to have less vertices in your mesh.
- By default USES, optimizes the mesh (that might lead to more memory)
- Have it disabled with the keyword “disablepostProcessing” when it makes sense.
Try the following browser tool when Uniview is running:
http://127.0.0.1:20080/tools/usesstats/
This tool would be helpful in knowing the resource usage of USES modules in Uniview.
Click on the info icon in the top right for more information.
Servicio de atención al cliente por UserEcho