KhronosGroup / glTF-Sample-Assets

To store all models and other assets related to glTF
382 stars 39 forks source link

Drawing order of the meshes of the MosquitoInAmber.glb model #131

Closed emadurandal closed 5 months ago

emadurandal commented 5 months ago

What should determine the order in which each mesh in MosquitoInAmber.glb is drawn? In order to draw it correctly, the mosquitoes inside should be drawn first, and then the amber, I think. My renderer is also Z-sorting with respect to Opaque meshes, so it seems to fulfil this order and render well. However, when Opaque meshes were sorted by material ID to improve renderer performance, the drawing order changed and they could not be drawn correctly (mosquitoes disappeared).

Does glTF have any provisions for determining the order in which opaque meshes are drawn? (This MosquitoInAmber.glb clearly assumes that they are drawn in a specific drawing order.)

emadurandal commented 5 months ago

I found the following description in the KHR_materials_transmission extension. https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_materials_transmission/README.md#implementation-notes

Rendering transparency in a real-time rasterizer in an efficient manner is a difficult problem, especially when an arbitrary number of transparent polygons may be overlapping in view. This is because rendering transparency is order-dependent (i.e. we see background objects through foreground objects) and also because the rendering of absorption and reflections involves two distinct blend operations. Consequently, it may not be possible on the target platform to render every transparent polygon in the correct order, in a reasonable time, and with the correct blending. Therefore, correct ordering is not an absolute requirement when implementing this extension in realtime renderers, nor is rendering all potentially overlapping layers. Various techniques are available to trade off physical accuracy against realtime performance requirements in client implementations. This extension does not mandate any particular technique. However, be aware that the simplest such technique — transmitting only the IBL and no scene objects — will often fall short of what a model's author intended. We recommend that client implementations aim to display at least opaque objects through a transmissive material. When that is not feasible, it may be preferable to fall back to simple alpha blending with 0 < alpha < 1.

Does this mean that meshes for which the KHR_materials_transmission extension is defined should be treated as transparent meshes (drawn after opaque meshes) even if the alphaMode is "OPAQUE"?

If so, my current implementation of the renderer seems to miss that point.

emadurandal commented 5 months ago

I have modified the renderer and this model is now rendered without problems. Self resolved, this Issue is closed. Thank you.