Open atteneder opened 3 years ago
Perhaps this should be the responsibility of the file producer to use KHR_materials_unlit
? The same applies for using primitiveMode
LINES
When present, the extension indicates that a material should be unlit and use available baseColor values, alpha values, and vertex colors while ignoring all properties of the default PBR model related to lighting or color.
Perhaps this should be the responsibility of the file producer to use
KHR_materials_unlit
? The same applies for usingprimitiveMode
LINES
I'd certainly recommend that as well, but the spec says the following in a non-normative section about shading points/lines:
POINTS and LINES should have widths of 1px in viewport space. For LINES with NORMAL and TANGENT properties, render with standard lighting including normal maps. For POINTS or LINES with no TANGENT property, render with standard lighting but ignore any normal maps on the material. For POINTS or LINES with no NORMAL property, don't calculate lighting and instead output the COLOR value for each pixel drawn.
TIL: Shader Graph (at least the URP target) does not generate point cloud compatible shaders. The only viable option is to write a custom shader.
Ah. Does this mean normal HLSL shaders? If so, here are two that might be a useful starting point: https://gist.github.com/camnewnham/290fd777d7b04775f7ad98bbd3ced40f
The basic vertex shader is of course much faster to run than the geometry shader.
I've also found that for points to render they seem to need an identity index buffer [ 0, 1, 2, 3, 4, 5, ... ].
Ah. Does this mean normal HLSL shaders?
Yes!
If so, here are two that might be a useful starting point: https://gist.github.com/camnewnham/290fd777d7b04775f7ad98bbd3ced40f
* Billboard geometry shader that renders uniform screen size points and vertex colors * Basic vertex color shader that renders pixel sized points on the platforms I've tested; but since gl_PointSize is not supported and generally seems to be considered legacy this size doesn't appear modifiable.
The basic vertex shader is of course much faster to run than the geometry shader.
Thanks for the reference. Those won't work on platforms without geometry shader support though. Also it's just a solution for Unlit materials (glTF spec says full pbrMetallicRougness should work with points/lines as well).
I've also found that for points to render they seem to need an identity index buffer [ 0, 1, 2, 3, 4, 5, ... ].
True, if you use the shaders you proposed.
Step one would be to extend IMaterialGenerator.GenerateMaterial
with a parameter that depicts the targeted mesh topology (or alternatively add a IMaterialGenerator.GeneratePointMaterial
). The respective MaterialGenerator can then pick another shader, based on platform. Now this is a bit impure, as primitive to material is a many-to-one relation (you could theoretically use a glTF material on both a triangluar primitive and a point primitive), but I'd ignore this special case. Its a rare corner-case and one can easily sail around it by not re-using materials in that way.
I'll schedule this API change, but not sure when/if I'll find time to implement and test the shaders.
I'm wondering if the IMaterialGenerator should be able to inform GltfImport
that indices are not required for points. Probably pre-mature optimization, but a breaking API change nonetheless.
Update: PR #495 brought the necessary API change to create material generators with point cloud material support!
Although primitives with mode
POINTS
(point clouds) are loaded properly, the materials created (for URP, HDRP and BiRP) do not render points properly.Points should be rendered as mentioned in the glTF spec.