Jon Parker
jparker
About Me
EXPERTISE
Technical Director
Houdini Skills
ADVANCED
Procedural Modeling | Digital Assets | Mantra | Lighting | PDG | VEX | Python
Availability
Not Specified
Recent Forum Posts
retiming value clips Dec. 16, 2024, 11:21 p.m.
Also somewhat related to this, is there a way to cache time samples on only *specific* prims, rather than the entire stage?
The scenario I have is that I am using the timeshift LOP on a particular prim, but there are no parameters to re-calculate the full frame range so I end up with a time dependency in the node graph. If I attempt a cache node afterwards, any value clips are cached in full per-frame which I don't want.
The scenario I have is that I am using the timeshift LOP on a particular prim, but there are no parameters to re-calculate the full frame range so I end up with a time dependency in the node graph. If I attempt a cache node afterwards, any value clips are cached in full per-frame which I don't want.
retiming value clips Dec. 15, 2024, 12:10 a.m.
Is there an efficient way in Solaris to alter the timing of value clips?
Using "timeshift" + "cache" does not alter the clip metadata but the actual primitive attributes, which makes sense.
But if I know I can retime the clip information only and change the metadata it would be much more efficient. I have already been able to do this via a VEX script but it's lots of code that seems like it should be wrapped up somewhere in a node.
Here is some example VEX that I wrote to change clip metadata (we have internal examples that use spline lookups for more complicated retimes):
Using "timeshift" + "cache" does not alter the clip metadata but the actual primitive attributes, which makes sense.
But if I know I can retime the clip information only and change the metadata it would be much more efficient. I have already been able to do this via a VEX script but it's lots of code that seems like it should be wrapped up somewhere in a node.
Here is some example VEX that I wrote to change clip metadata (we have internal examples that use spline lookups for more complicated retimes):
int stride = 3000; string clips[] = {"default"}; foreach (string clip; clips) { string assets[] = usd_metadata(0, @primpath, "clips:" + clip + ":assetPaths"); vector2 times[] = usd_metadata(0, @primpath, "clips:" + clip + ":times"); vector2 active_out[]; vector2 times_out[]; for (int i=0; i<len(assets); i++) { append(times_out, set(i*stride, times[i][1])); append(active_out, set(i*stride, i)); } usd_setmetadata(0, @primpath, "clips:" + clip + ":times", times_out); usd_setmetadata(0, @primpath, "clips:" + clip + ":active", active_out); usd_setmetadata(0, @primpath, "clips:" + clip + ":interpolateMissingClipValues", 1); }
LPE for emission of specific object (Karma MtlX Unlit) Nov. 20, 2024, 3:10 a.m.
I'm trying to extract some AOVs from particles that are partially transparent and constant shaded. For mattes, for example.
Unfortunately it seems that AOVs are multiplied by the opacity no matter what... which seems wrong and difficult to work with, since... they're AOVs and theoretically should be able to do anything.
Maybe I'm getting old but I seem to remember doing this easily enough in Mantra.
So I now want to try the LPE approach and make an AOV for each subset of my particles' shader emission. Ideally a prim for each particle group, and tag them with a LPE tag and make a different render var for each.
Does that work?
Unfortunately it seems that AOVs are multiplied by the opacity no matter what... which seems wrong and difficult to work with, since... they're AOVs and theoretically should be able to do anything.
Maybe I'm getting old but I seem to remember doing this easily enough in Mantra.
So I now want to try the LPE approach and make an AOV for each subset of my particles' shader emission. Ideally a prim for each particle group, and tag them with a LPE tag and make a different render var for each.
Does that work?