Hi,

I´ve attached a file in which I want to prune the primitives based on a primvar.
When I use keyframes on the prune LOP, It authors the time samples on the usd file.
When I use VEX with the prune LOP with an animated primvar to prune, the resulting usd file doesn´t have the time samples in the visibility attribute.

I´ve searched the docs and I didn´t find a way to force the creation of time samples in the attribute. I believe LOPs does this automatically, right?

Anyway, are there problems with my approach or It is a bug?

I´ve updated the file with some tests with VEX.
I believe there is an odd behavior with the “usd_setvisible” VEX function. It creates the time sample when the visibility is “invisible”, but not for when It should be “inherited”.
I´ve forced the values on the string attrib “visibility” (inherited/invisible) and It works fine.

As a side note: The reason I´m doing this is for crowd rendering, since pruning the agents that are not in the camera seams to decrease render time. If there is any other way to make this kind of workflow, please share the knowledge!

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.

Thanks Rafal, but shouldn´t Prune LOP be able to create the time samples when in VEX “mode”?
Because It does create´em when used with keyframes.

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.

Another “thing” with VEX: I´ve tried using the “usd_setactive” function and It doesn´t create time samples too. Can this function be used this way?

shouldn´t Prune LOP be able to create the time samples when in VEX “mode”?

It sounds like it should, but I did not look into that yet, so did not comment on it yet.

I´ve tried using the “usd_setactive” function and It doesn´t create time samples too

`usd_setactive()` corresponds to `UsdPrim:etActive()`, which sets a metadata on the primitive. And metadata is not animateable, so can't have time samples.

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!

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!

Sure, thanks mtucker!

hi, sorry to dig up an old post but having a hard time figuring out whats the best way to prune agents out of a moving alembic camera frustrum now as the prune lop has had an update.

im using the autocollection %bound on the primitive pattern of the prune lop:
/crowd/agent* - %bound(/cam/Cam_mainShape, dolly=2)
it works but does not force an update as the camera moves.

reading up on the prune parameter field - The Prune LOP now evaluates the Prune parameter separately for each primitive that will be modified, allowing the use of local variables to access information about each primitive to decide how it will be modified.

Putting a random timevarying expression in the field like min(@Frame, 1) works but what could be a better(intended) solution in this case?

frostfx
hi, sorry to dig up an old post but having a hard time figuring out whats the best way to prune agents out of a moving alembic camera frustrum now as the prune lop has had an update.

im using the autocollection %bound on the primitive pattern of the prune lop:
/crowd/agent* - %bound(/cam/Cam_mainShape, dolly=2)
it works but does not force an update as the camera moves.

reading up on the prune parameter field - The Prune LOP now evaluates the Prune parameter separately for each primitive that will be modified, allowing the use of local variables to access information about each primitive to decide how it will be modified.

Putting a random timevarying expression in the field like min(@Frame, 1) works but what could be a better(intended) solution in this case?

Until now I've been putting everything I need into attributes to use in LOPs, since I still think Its hard to do that kind of think in Solaris.
I've never used collections properly, so I don't have a better suggestion now... Hopefully, someone from SESI will help again.

Primitive patterns do not currently flag the nodes that use them as (possibly) time varying when the USD data involved in calculating the pattern results are animated. This is something that should be addressed, and a bug submission would be appreciated.

However in the meantime you can force the prune LOP to re-evaluate the pattern on each frame by ensuring that some parameter on the node, or some node connected as an input to the prune node is time dependent. I'd suggest something simple like an Edit Properties LOP creating an attribute called "currentTime" on an unused primitive, and set its value to $T.

hi, just to follow up on that one. from the changelog:

"USD Primitive patterns using auto-collections can now introduce a timedependency if the auto-collection evaluation may depend on stage datathat is time varying. This time dependency is displayed in the primpattern and selection rule editor dialogs. The bound, fartherthan, andcloser than auto-collections also gained a time range optional argumentto eliminate this time dependency and allow a primitive's bounding boxto be evaluated over a time range with a single pattern (if the timesamples are all simultaneously available on the stage)."

been trying to test that but cant seem to figure it out. Ideally id like to prune agents outside the moving alembic camera frustrum and even more ideally the prune would happen only at rendertime.
thanks.

Can't figure what out?

The render time pruning you could do yourself with a pre-frame python script. But if you want to use a prune node, that has to happen in Houdini.

The bound pattern doesn't _have to_ evaluate over a frame range. That's simply an option if you want to avoid introducing a time dependency in your LOP graph due to a pattern that refers to an animated camera. If you want per-frame pruning based on the camera frustum at each frame, than just keep using the same old bound pattern. The only effect of the change mentioned above is that the Prune LOP should now be marked time dependant based solely on the pattern, instead of requiring hacks to force the time dependency.

misunderstood the changelog. was hoping we can add the camera bound autocollection in a single frame usd and it would get evaluated on each frame as it renders. will check out the preframe python script option. thanks.