mtucker
If you want a separate USD file per frame, value clips is the only way to combine them back into a single animated clip at composition time. I would like at some point to have the Value Clip LOP capable of doing the “stitching” step automatically as part of the USD ROP save step, but that's probably a ways off.

If you don't specifically want a separate USD file per frame, you can create a massive single USD file which is very efficient to read in (USD only loads the data for the time samples that it needs at any given time). This is much easier than working with value clips.

jsmack

guilhermecasagrandi

jsmack

guilhermecasagrandi

jsmack
Sequences have to be combined with usd stitch clips or with a valueclip prim.

Hi jsmack, thanks for the reply. But can´t I do that in the same LOP network, right? (so Solaris would and up creating all the necessary dependencies when generating the resulting usd file)
In my understanding, I need to do that manually, and then get the stitched usd back to LOPs, right?

Correct, it has to be a two-step process. Mark, maybe you can clarify? Value clips are a dark art that eludes my understanding.

The (two step) process is ok for me, but It would be really usefull if we could set up this kind of info in the network (with nodes) and solaris would end up building the “correct” usd file. This “two-step” process makes the workflow not so procedural when we are getting geo from SOPs, because we must bake the sequence of usds before rendering (or adding switchers in the network) to test the render befor creating the “final” usd file.

It has to be two step because creating the manifest or stitching requires opening all of the frames, whereas the usd rop operates frame-by-frame.

jsmack

guilhermecasagrandi

jsmack
Sequences have to be combined with usd stitch clips or with a valueclip prim.

Hi jsmack, thanks for the reply. But can´t I do that in the same LOP network, right? (so Solaris would and up creating all the necessary dependencies when generating the resulting usd file)
In my understanding, I need to do that manually, and then get the stitched usd back to LOPs, right?

Correct, it has to be a two-step process. Mark, maybe you can clarify? Value clips are a dark art that eludes my understanding.

jsmack
Sequences have to be combined with usd stitch clips or with a valueclip prim.

brians
Hi guys
The spotlight transform-scaling bug has been fixed and will be out in the next nightly build.
Thanks!

mtucker
The bug is that there is any scale being set at all. This is happening because we are doing some internal orientation calculations at half-float precision in the Instancer LOP. This problem will be fixed in tomorrow's build.

I don't know how to judge if karma is responding “correctly” to these scale values…

jsmack
That's really strange. I modified the pointxform side to see if putting the transform on the reference instead of the light produced the same result but it was still normal. The matrices are slightly different, but only after the 5th or 6th sig fig.

rafal

guilhermecasagrandi
Changing the setup to 1 assign material doesn´t solve the problem,

That was fixed just a few days ago, so should work in a daily build.

Also, both `@foo` and `usd_attrib('foo')` read the attribute value directly from the primitive. We may need `usd_primvar()` to evaluate the inherited primvar from parents.

Assign Material LOP creates new Material prims (that specialize the base material) and authors new parm values (overrides) on it, and this ability makes it suitable for overriding parameters of materials that don't have a primvar reader to drive the variation. But, since you are using principled shader, you should be able to use primvars directly on the geoemtry to drive the variation. In this case, you can use Wrangle LOP to author the `primvars:baseColor_texture` on skin of the agents (I think).

mtucker
mat_overrides.hipnc (1.5 MB)

jsmack
What is the reason for targeting the child prim, instead of the level where the primvar is located?

It doesn't matter where the material is assigned, as the inheritance is a material property.

Tim Crowson
I have used this approach before and it seems to work, for primvars at least:

from pxr import UsdGeom
stage = hou.pwd().editableStage()
prim = stage.GetPrimAtPath("/path/to/some/prim")
pvAPI = UsdGeom.PrimvarsAPI(prim)
primvar = pvAPI.FindPrimvarWithInheritance("some:attribute:name")
primvarValue = primvar.ComputeFlattened()