I’m new to USD so let me know if I’m posting under the wrong category.
I’m currently trying to port a procedural mesh generator to use USD/Hydra (targeting usd-23.08). Essentially, we have a procedural engine capable of generating geometry in the form of meshes (points + topology + point attributes). The engine takes in a set of parameters and outputs a mesh. The meshes can be fairly large, so we currently use an Arnold procedural plug-in to create the meshes at render-time, saving the need to transfer huge files to the render farm. However, this approach is obviously DCC-specific (to Arnold in this case), which is why we are looking to implement something similar for USD/Hydra.
Two different approaches have been tried so far:
(1) Inspired by Paolo Emilio Selva’s Siggraph 2023 presentation (starts at 0:52:00) we implemented a custom
UsdGeomGprim since we want to provide extent as well as represent our procedural parameters. This follows the examples,
https://github.com/wetadigital/USDPluginExamples, provided by Weta. Next, we implemented a custom
UsdImagingGprimAdapter with the idea that our adapter can read the parameters from our custom prim and generate a suitable mesh. While this works in theory, there are some practical issues. For instance, we need to implement both
GetTopology on our adapter. In our case this means that our engine generates the procedural mesh twice, once to provide points and a second time to provide topology. The question here is: Is there a way to generate our procedural mesh only once and have it cached somewhere so that we can answer point/topology queries using the cached data? My understanding of the
UsdImagingGprimAdapter interface is rudimentary at this time so I’m hoping there is a solution to this problem, since generating points together with topology is a common strategy.
(2) Our second approach has been to use the more modern
HdGpGenerativeProcedural method, based on this article (translated to English). Here we don’t have the issues of having to generate points/topology separately, since we are free to build our
HdSceneIndexPrim however we like in the
GetChildPrim method. What worries us here is that
HDGP_INCLUDE_DEFAULT_RESOLVER must be defined in order for this to work, meaning that existing DCC’s might not be able to handle
HdGpGenerativeProcedural just yet.
Any input on best practices or suggested strategies are highly welcomed at this point. (sorry for inlining one of the links above, as a new user I am only allowed to use two links)