jsmack

guilhermecasagrandi

mtucker
Hi Mark,

Mark Wallman
If I save out a usda file using a usdRop my paths are relative so I would not be able to load this file in another package.

I would have to dispute this claim… What makes you think that relative paths wouldn't work in other packages? It's possible that there are bugs in the relativizing of paths that Houdini does, but everybody uses the USD library to load USD files, and the USD library has always been perfectly happy with relative paths.

As to the having this on by default, relative paths are almost always a better option than absolute paths because they allow you to relocate your USD files (as long as you copy/move the whole directory) without re-authoring every USD file in the directory.

I couldn´t agree more.

On the same topic, Is It possible to bind textures to the materials using relative paths? (like when using the assign material LOP)

I'm pretty sure the output processor handles texture asset paths in the same fashion as layer paths–they will become relative too.

mtucker
Hi Mark,

Mark Wallman
If I save out a usda file using a usdRop my paths are relative so I would not be able to load this file in another package.

I would have to dispute this claim… What makes you think that relative paths wouldn't work in other packages? It's possible that there are bugs in the relativizing of paths that Houdini does, but everybody uses the USD library to load USD files, and the USD library has always been perfectly happy with relative paths.

As to the having this on by default, relative paths are almost always a better option than absolute paths because they allow you to relocate your USD files (as long as you copy/move the whole directory) without re-authoring every USD file in the directory.

mtucker
Generally speaking LOPs will author time sampled values if the value being specified varies over time. In the simplest case, this means testing if the parameter driving the attribute value is animated. So if you animate the Prune parameter with an expression or keyframes, the Prune LOP will author time samples for the visibility attribute.

However, if the primitive pattern varies from frame to frame, this does not indicate that the visibility attribute should be time varying. Because you aren't varying the value of the attribute for any primitive over time. You are always setting the attribute to “invisible”. You are just setting that fixed “invisible” value on a different set of primitive each frame. So whether you authored this value as a default value or a time sampled value, the resulting behavior of the stage will be unchanged. The attribute would have value of “invisible” for all time.

What I believe you want is to have the prune lop set prims a,b,c invisible on frame 1, then on frame 2 set c,d,e invisible, but explicitly make a and b visible again. But the way you want the Prune LOP to work is to remember that it sent a and b invisible on frame 1, and because they aren't mentioned in the primitive pattern on frame 2, but they were in the primitive pattern on frame 1, set them to be explicitly visible on frame 2. But (except for simulation nodes and some other special exceptions), Houdini nodes don't use history. They are expected to be able to cook frame 2 without ever having cooked frame 1.

So the Houdini way to accomplish what is described above is for the primitive pattern to be a,b,c,d,e for all frames, but then have an expression in the Prune parameter that varies over time, and which is evaluated separately for each primitive. This is not currently the way the Prune LOP behaves, but it probably should be. Just as you can use @prim and @primpath in expressions in an Edit Properties LOP, you should be able to use those same local variables in the Prune LOP.

If you could submit an RFE to this effect that would be very helpful. Thanks!

rafal
Regarding `usd_setvisible()` VEX function, as its argument, it currently takes one of two values: 0 (set invisible) or 1 (set visible). Ie, it can't set “inherited” behaviour.

so `usd_setvisible(1)` ends up calling the USD API function `UsdGeomImageable::MakeVisible()`, which does not explicitly set the `visibility` attribute value, most likely because the prim is already visible.

However, this shows that perhaps `usd_setvisible()` VEX function should take another value to set prim visibility to “inherited”. This is now RFE 109097.

rafal
Regarding `usd_setvisible()` VEX function, as its argument, it currently takes one of two values: 0 (set invisible) or 1 (set visible). Ie, it can't set “inherited” behaviour.

so `usd_setvisible(1)` ends up calling the USD API function `UsdGeomImageable::MakeVisible()`, which does not explicitly set the `visibility` attribute value, most likely because the prim is already visible.

However, this shows that perhaps `usd_setvisible()` VEX function should take another value to set prim visibility to “inherited”. This is now RFE 109097.

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.