Currently how UsdGeomPoints are rendered in HdStorm is determined by lower level library and we get different results on GL vs Metal. With GL, the result is a round disk and with Metal, the result is a quad.
Another feature we’d like to have is to interpolate the ‘width’ attribute as screen space size instead of object space.
To address these issues, one solution I can figure out is to add more primitive type defined for HdStPoints in HdSt_GeometricShader (as curves and mesh), such as PRIM_POINTS_DISK, PRIM_POINTS_QUAD. Then implement different styles in a tessellation shader (no geometry shader on Metal). A token attribute, with value ‘disk’ or ‘quad’, and another with value ‘screen’ or ‘object’ might necessary for UsdGeomPoints.
Does this sounds a reasonable solution? Is there a better approach to address the issue?
Indeed, OpenGL specifies point rasterization as a disk and Metal/Vulkan/etc seem to rasterize them as quads. We’re working on a changelist to implement the disk rasterization like you say, since that’s our preference internally. We haven’t heard any requests for rasterizing them as quads, but if that’s a feature folks are interested in we could add a display style token, like you say. We’re hoping the disk rasterization lands this autumn.
Currently widths are always interpreted in world-units; I know there’s interest in screen-space widths for both points and curves, but that’s not well-specified in USD yet. It’s a relatively straightforward compensation in the shader, though.
Thanks for your reply. Glad to know Pixar is already working on the unified style for points on different platforms. By “this autumn” you mean 23.11 right?
For the screen-space widths for points and curves, since the solution is straightforward, what’s the major concern that not including it in the USD specification? Will it be specified in near future?
@gaoyUsdGeom currently specifies geometry so that they can be interpreted without the context of a camera. Computing extents, simulation, collision detection, etc.
Screen space width specification would change that, and I’d argue warrant a different set of “view dependent geometry schemas” (even if they internally shared rendering logic).
With the same scene description and multiple renderer, do we expect same or different result? To my understanding, different renderer plugin might produce different result. For example the HdEmbree renderer plugin chooses to not render UsdGeomPoints at all.
Even in one renderer, one attribute can be picked or ignored with different options. Like ‘width’ for curve, HdStorm can be configed to render with low or high complexity:
Complexity low:
For the same reason, attributes like ‘screenspace’ can be interpreted differently in different renderer plugin, or in one renderer with different render options. It doesn’t necessary to include any camera context (renderer already have this and more info like viewport size) or have another set of schemas.
I do agree that we should keep results mostly the same in different renderers.
