3 ms·

They Python part just generates Blender procgen specifications (compute graphs), that is probably relatively fast. But apparently the output graphs are huge and

They Python part just generates Blender procgen specifications (compute graphs), that is probably relatively fast. But apparently the output graphs are huge and unoptimized, so generating the geometry takes a lot of resources (CPU bound). Rendering might also take a while if they don't have good ways to limit detail (something like Nanite would come in very handy here).

Animats 3y ago
With Nanite, if you have a sidewalk with occasional cracks, and all the cracks are the same, those get combined into a single submesh. This is recursive; if you have multiple instances of that sidewalk, those get combined at a higher level. It's a form of compression for mesh data with redundancy. This only works if the data contains such redundancy. That depends on how it's generated. Not clear if this type of generator creates such redundancy. Something using random processes for content generation won't do that. Nanite is optimized for large areas of content generated by a team of people working together, as in a major game project. There's a lot of asset reuse. Nanite exploits that. It's not a good fit for randomly generated assets, or for assets generated by a large community, as in a serious metaverse. The redundancy isn't there to be exploited.
- oersted 3y ago
  You seem to know more about it than I do. But isn't Nanite also about automatic and continuous LOD adjustment? A big selling point is to be able to drop-in extremely detailed unoptimized meshes made by artists, and have it perform well by dynamically reducing the polygon count based on the screen real-state they take up. I guess you could call this compression too, but it is lossy compression (automatic mesh downscaling) and doesn't depend on redundancy that much. Many of these artist-made high-fidelity meshes make heavy use of Z-brush style sculpting and procedural materials, which have similar characteristics to these randomly generated assets.
  - Veedrac 3y ago
    You are correct, and the parent comment is confused. Nanite does support faster instancing but its unique advantage is being a fast software renderer for assets with very large polygon counts.

Animats 3y ago

With Nanite, if you have a sidewalk with occasional cracks, and all the cracks are the same, those get combined into a single submesh. This is recursive; if you have multiple instances of that sidewalk, those get combined at a higher level. It's a form of compression for mesh data with redundancy. This only works if the data contains such redundancy. That depends on how it's generated. Not clear if this type of generator creates such redundancy. Something using random processes for content generation won't do that. Nanite is optimized for large areas of content generated by a team of people working together, as in a major game project. There's a lot of asset reuse. Nanite exploits that. It's not a good fit for randomly generated assets, or for assets generated by a large community, as in a serious metaverse. The redundancy isn't there to be exploited.

oersted 3y ago
You seem to know more about it than I do. But isn't Nanite also about automatic and continuous LOD adjustment? A big selling point is to be able to drop-in extremely detailed unoptimized meshes made by artists, and have it perform well by dynamically reducing the polygon count based on the screen real-state they take up. I guess you could call this compression too, but it is lossy compression (automatic mesh downscaling) and doesn't depend on redundancy that much. Many of these artist-made high-fidelity meshes make heavy use of Z-brush style sculpting and procedural materials, which have similar characteristics to these randomly generated assets.
- Veedrac 3y ago
  You are correct, and the parent comment is confused. Nanite does support faster instancing but its unique advantage is being a fast software renderer for assets with very large polygon counts.