I have a looping volume which I want to make a choice in a variant. If I loop the volume in a ‘simple’ way with a expression on the filename its fine, but if I loop it with a value clip, it doesn't work.
In the attached hip you can see I have a vdb sequence on disk, one of which is loaded with an expression
$HIP/cloudloop.`padzero(4,1+$F4%41)`.vdb
The other method writes a short 42 clip usd file, that is sublayered in, and looped with a value clip. If I run both of those to an add variant lop, the simple one works, the valueclip one doesn't.
If I inspect the usd code, at the valueclip lop its using explicit paths to the vdb and is set to the full framrange I expect. After creating variants and setting to the valueclip, the framerange is back to a single loop, and is using relative references.
Any ideas what might be wrong here?
variants and value clips
3034 4 2- mestela
- Member
- 1795 posts
- Joined: May 2006
- Online
- mtucker
- Staff
- 4521 posts
- Joined: July 2005
- Offline
The absolute paths are, I believe, caused by your choice of “Inspect Flattened Stage”. Whenever you flatten a stage all asset paths get converted to absolute paths. I don't think it's relevant to any of the problems you're having.
The real problem here is that you are authoring the value clip variant as a sublayer (which loads the usd_vol.usd file, which has an animated value for the volume file path), and then you have the value clip LOP which (in a stronger sublayer) defines the looping value clip. I don't totally understand how value clips fit into the LIVRPS composition hierarchy, but I guess when the clip definition is stronger than the animated time samples, the clips win. So when you view the vol_with_valueclip node, you see the extended loop defined by the value clip metadata.
When you feed that node into an Add Variant node, the layers get flattened. You can see the result of this flattening operation by appending a Merge LOP to vol_with_valueclip set to “flatten layers” mode and inspect the active layer. You'll see in the flattened layer the value clip metadata and the time sampled asset paths both live in the same layer. In this case, the presence of the existing time sampled asset path stops the value clips from contributing to this attribute value. So you just get the 41 time sampled values from the file on disk.
What you really need is for that first sublayer from disk to not load the time sampled data. In the attached files I've used a Stage Manager and a Primitive LOP to replace the density field prim with an empty prim of the same time. And then feeding it into the Add Variant works as expected because only the value clip opinions of the file paths exist.
This shouldn't be this hard. The problem here is that the usdstitchclips operation is needed not just to author the value clip metadata (which the Value Clip LOP can do), but to also author the “topology” layer, that contains only the hierarhcy and non-timesampled data from the value clip files. There is currently no way to author this topology file directly in a LOP network, making any use of value clips a multi-step process. But it is on the todo list to add the ability to generate a topology file to the Value Clip LOP. For now I'd recommend using the usdstitchclips ROP to author the topology file on top of which you can safely load your value clips. And make sure you're on the latest version of Houdini because there were some major fixes to the Value Clip LOP in recent weeks. Though I suspect you're already using it given how far you got already.
I hope that all makes sense.
The real problem here is that you are authoring the value clip variant as a sublayer (which loads the usd_vol.usd file, which has an animated value for the volume file path), and then you have the value clip LOP which (in a stronger sublayer) defines the looping value clip. I don't totally understand how value clips fit into the LIVRPS composition hierarchy, but I guess when the clip definition is stronger than the animated time samples, the clips win. So when you view the vol_with_valueclip node, you see the extended loop defined by the value clip metadata.
When you feed that node into an Add Variant node, the layers get flattened. You can see the result of this flattening operation by appending a Merge LOP to vol_with_valueclip set to “flatten layers” mode and inspect the active layer. You'll see in the flattened layer the value clip metadata and the time sampled asset paths both live in the same layer. In this case, the presence of the existing time sampled asset path stops the value clips from contributing to this attribute value. So you just get the 41 time sampled values from the file on disk.
What you really need is for that first sublayer from disk to not load the time sampled data. In the attached files I've used a Stage Manager and a Primitive LOP to replace the density field prim with an empty prim of the same time. And then feeding it into the Add Variant works as expected because only the value clip opinions of the file paths exist.
This shouldn't be this hard. The problem here is that the usdstitchclips operation is needed not just to author the value clip metadata (which the Value Clip LOP can do), but to also author the “topology” layer, that contains only the hierarhcy and non-timesampled data from the value clip files. There is currently no way to author this topology file directly in a LOP network, making any use of value clips a multi-step process. But it is on the todo list to add the ability to generate a topology file to the Value Clip LOP. For now I'd recommend using the usdstitchclips ROP to author the topology file on top of which you can safely load your value clips. And make sure you're on the latest version of Houdini because there were some major fixes to the Value Clip LOP in recent weeks. Though I suspect you're already using it given how far you got already.
I hope that all makes sense.
- mestela
- Member
- 1795 posts
- Joined: May 2006
- Online
- mtucker
- Staff
- 4521 posts
- Joined: July 2005
- Offline
I'm not having any problem with it in 18.0.469… But I realize now that the changes I'm referring to aren't in 18.0 at all, in any version, and my changes wouldn't have fixed any crashing issues that I'm aware of anyway. Do you have a crash log? It might also be worth testing with a daily build just in case the crash isn't really variant or value clip related and got fixed recently…
- Bretislav Kaspar
- Member
- 20 posts
- Joined: May 2014
- Offline
-
- Quick Links