4 ms·
I didn't mean to say they should tailor the file format to the graphics API. I more meant, when a scene format becomes popular, usually you see multiple engines
by softfalcon 3y ago
I didn't mean to say they should tailor the file format to the graphics API. I more meant, when a scene format becomes popular, usually you see multiple engines/pipelines/libraries support the underlying scene descriptors like material files, physically based rendering profiles, animation keying, etc.
I wouldn't want the file format dictated by the graphics API, but I would like consistent rendering output in multiple places for the same file. That'd be cool.
In case you're wondering where this "conformance" idea came from, check nVidia's 2023 Siggraph talk. Jensen will buzz word OpenUSD and conformity across products until your ears bleed.
Siggraph 2023 nVidia: https://www.youtube.com/watch?v=Z2VBKerS63A https://www.youtube.com/watch?v=Z2VBKerS63A
(in case it wasn't obvious, I am skeptical this will ever really happen, I imagine this is all marketing speak)
- meindnoch 3y agoConsistent rendering is only possible when the material models used by the various engines are similar enough. Physically-based renderers produce pretty similar results for basic diffuse-metallic-clearcoat, etc. materials. Where things become hairy are more advanced effects like refraction, subsurface scattering, ambient occlusion etc., where different engines use different techniques with different tradeoffs, because there's no easy one-size-fits-all implementation. The UsdPreviewSurface part of the USD spec doesn't even support many of these advanced effects. If your scene uses these effects a lot, then consistent rendering is less likely.