PixarAnimationStudios
NdrTokenMap : function to flush particular cache entry
Description of Issue
The NdrTokenMap seems to be cached, for a given identifier. We don't get updated metadata if the shader node changed under the hood.
Steps to Reproduce
assetPath = "/path/to/shader.ext" sdrShdNode = Sdr.Registry.GetNodeFromAsset(Sdr.Registry(), Sdf.AssetPath( assetPath )) meta = sdrShdNode.GetMetadata()
In the snippet above, the python dictionary 'meta' will not update to the new asset metadata, if I overwrite the shader content.
System Information (OS, Hardware)
Kubuntu 18
Package Versions
This is usd-21.08
Build Flags
Hi Eric, Although we don't much use it that way in our pipeline, we do understand that some interactive lookDev workflows would really benefit from being able to not just eject asset-based shader defs, but also "reload" the registry. Internally, the registry is in decent shape to support that. The primary issue is that it returns SdrShaderNodes by raw pointer, banking on the fact that they are eternal. So to ensure client safety, we'd need to turn that return type into a weak pointer, and follow up with known clients to ensure they check for validity before before using a cached Node.
Small bit of a project... I know the MDL/OV folks would be happy to see this happen, also.
Hi Sebastian, you're exactly right. This is how we are trying to do interactive lookdev, basically reloading the registry for a given asset-based shader, that keeps on changing. The ability to flush the cache would be amazing. I can pass on the info about the return type to the teams we have in-house :) ..
Would you have any kind of estimate for this feature ?
Hi @egvezinet ,
Although no part of Hydra hangs onto Sdr pointers (good for this purpose, though could become a performance thing at some point), it looks like our internal "enhanced" shader registry (which helps perform shader upgrades) does hang onto SdrShaderNodeConstPtr s, and it looks like mayaUsd's UFE framework has also adopted this pattern.
... so we'll need to decide which set of smart pointers to use and ensure the registry maintains threadsafe integrity, and fix up the access pattern in both of those clients, so it's not a trivial project. We'll try to keep this Issue in mind, but for sure we won't be able to get to it for 22.11. If someone there wants to tackle the work, with PR's to both USD and usdMaya, let us know and we can talk smart pointers (e.g. choosing between Tf and std strong/weak), which would help move this along.
Hi @spiffmon , just checking in regarding this request. Am I correct in assuming it's been left as is ? We are still hitting this case almost every day in production (23.08), so I think we will need to prioritise alternative pathways.
Apologies, @egvezinet ... there's actually been a ton of unrelated work going into Sdr recently, and we're going to need to move onto other areas in more urgent need of attention soon. Thanks for the ping - I've added this issue to our roadmap backlog, but can't say yet when we will be able to tackle it.