tamte

it always makes me nervous when pipeline allows pushing changes onto unsuspecting artists or onto live renders on the farm
changing symlinks is source of major headache, even though I see the appeal of not looking back and just power through and hoping nothing breaks and if it does then fix later

but in such workflow if someone asks to go back to old version of the scene, which used to assemble hundreads of versions of different assets and you open your file and everything is different than it was just because the assets resolved in different versions you will never piece it back together unless you have very good pipe in place which will allow you to know the state of that file at the time of render or so

I very much prefer resolving and updating versions consciously, you still can have tools in place that warn user or ask about old versions in the files , but that let it up to user to decide whether to update or not, and automatize that as much as you want

in any case I prefer artist submitting a render, caching a sim or simply doing their work to know that something has updated to be able to double check that it still works if they are ready to ingest that version, sometimes you simply need to get stuff out and new version would require change in your setup so you just output you new work using older version and work on update for new one next

I know I derailed from purely .usd asset versioning to the actual production assets, but I think it's a very similar situation and requires very robust and transparent tools

jsmack
Could this be solved on the USD side with the creation of a geometry relationship on material prims? Sort of the opposite of a material relationship on GPrims.

not sure, anything else than direct access to the .usd handle that already exists as an efficiently composited and resolved usd stage somewhere in memory sounds like just cherrypicking subset of information to send to shader and also locks the shader to use just that binding, while I may need it to be reaching for completely different data based on object it is assigned to

but also what use would be relatioship binding to GPrim if shader will still not be able to access that GPrim and do pointcloud lookup to it for example as we currently can do against geo in the .ifd?
or also just to get any property value of currently shaded object (not the granular ones that we can use primvars: for but any, like transform) also transform or properties to compute projection matrix of currently used camera or any camera in usd if I want to do camera mapping shader, simply in theory all I need is access to that stage in memory, rather than cherrypicking data for each object and shader and trying to pass it as primvars: or any other way
also there was a talk about coordinate systems, but that's the same thing, just subset of the information I may need

When I requested shaders in Karma to be able to use existing usd_* functions (once they can take .usd file handle as an argument) to access the data from .usd being rendered
the answer was, that this is unlikely because “The architecture of karma puts a thin layer between USD and the actual renderer implementation. The rendering library (and shaders) don't actually know that USD is the front-end”

Which was a big disappointment and while it doesn't answer any questions whether Karma parses usd directly and that thin layer is part of Karma or whether it is the actual Hydra they are talking about it certainly shows that shaders don't have access to the .usd which to me sounds like a wasted opportunity, since all the information is already there and access to it would open a great potential

and it actually brings up the question how will Karma handle access to such information which in very limited sense Mantra handles using op: references to the geometry in .ifd for example