[QUESTION] Why no point size extension?

[Gpinchon]

Having no way of specifying point size is kind of a problem when using GLTF to share datasets. When we want to use points to render a "surface" or "volumetric" surface there is no way to adjust for point density in order to get consistent rendering. A good example of the issue I'm facing with point clouds would be the difference you get in term of rendering with this model with high density vs this model with low density.

[lexaknyazev]

Why no point size extension?

Because there were no specific proposals. It's likely that apps that need to better define point rendering use their private extensions or other means to deliver that information.

To make it a "proper" KHR extension, many non-obvious issues would need to be addressed. What works for one application may be too much or not enough for others. For example:

• Point size granularity: per-vertex / per-mesh / per-node / etc
• Point size units: real screen pixels / DPI-aware screen pixels / meters / etc
• Whether point size is affected by node / camera transforms
• Point shapes: square / circle / soft edges / etc

[Gpinchon]

I could be interrested by making such proposal specifically for points size, but I don't know where to start... As for the issues you raised, here are my suggestions

• Point size granularity could have 2 levels, per primitive and per vertex with an optional buffer view, then gl_PointSize=perPrimitive*perVertex
• Shouldn't it be in pixels like explained in gl_PointSize ref page ?
• I would be tempted to say no, maybe this kind of behavior should be left for an other extension relative to "impostors" ? Though I see how such extensions could maybe collide...
• Again, default is square so it could be left for another extension ? It doesn't really have to do with gl_PointSize

[emackey]

Some random suggestions here:

1. The point shape could always be square (like OpenGL, WebGL) with an implicit TEXCOORD_0 that comes from gl_PointCoord or similar, such that the points can be textured.
2. A full PBR material could then be applied to the point. Geometric normal always faces camera, tangent vector always faces screen-right. The point could carry a texturemap of a full sphere, with a bulge in the normal map and alpha masking to round off the edges. The point could essentially be a full PBR billboard of almost any shape.
3. The point size extension (and its parameters) could be a material extension, not a mesh or node extension. This would place it in proximity to other PBR settings applied to the point, and of course the point size settings affect the shaders in ways similar to material settings.

[Gpinchon]

1. That sounds about right, using the face tangents wouldn't make much sense for points.
2. This would mean that the texture map would be fully displayed on each point thanks to gl_PointCoord.
3. Conceptually I would find it kind of strange since point drawing is specified via VkPolygonMode for Vulkan, D3DPRIMITIVETYPE for DirectX and draw modes for OpenGL... Though now that I'm talking about other APIs I realize that glPointSize is quite unique and has no equivalents on VK or DX, DirectX not even allowing variable point size AFAIK (though that can be "fixed" via geometry shaders). Nevertheless, point size seems to be a vertex property, having materials influence vertex shaders seems intuitively kind of odd to me.