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()

AndyW
Ok this one is new and I'm not sure why I haven't run into this before. I'm able to set my $JOB variable for the current session of Houdini only, it always defaults back to the location it was launched from next time I open my hip file, so all my file dependencies break.

I noticed if I open the hip file in a text editor there's a set -l JOB and a set -g JOB. The local JOB variable is correct, the -g one sees to be causing problems. Also, I'm not able to edit (change) the JOB path in the Aliases and Variables dialogue. Any clues on what's going on here? Thanks!

jason_iversen
There is no way right now to set viewport background images (nor associate them with a camera as you can in Objects|cameras) except by manual entry into the Display Options > Background feature. There are RFE's for this existing already

Specific renderers may have their own background-image support, but I couldn't tell you which ones do.

BrandonA

FFD

BrandonA
3) This is a known issue with the expressions. I agree that at the minimum, all parameters should be accessible. I will make this change

Any update on this? I have some hdas that already extensively use hidden and disabled parameter expressions for usability reasons.
I was going to use the hda processor on them but decided to avoid it and use another PDG workflow.

Yes, this has been fixed and recent H18 daily builds will have the fix.

mtucker
That file still works fine for me.

Is the scene graph tree definitely showing the stage after applying the configure primitives LOP? And the box isn't showing up in the viewport?

What version of Houdini are you running?

mtucker
That file still works fine for me.

Is the scene graph tree definitely showing the stage after applying the configure primitives LOP? And the box isn't showing up in the viewport?

What version of Houdini are you running?

mtucker
I'm not able to replicate the original problem. The Configure Primitives LOP works fine for me in a similar hierarchy. Can you attach a hip file that doesn't rely on your source alembic data?

“s@visibility = ‘visible’;” doesn't work because “visible” isn't a valid token for the visibility attribue. See https://graphics.pixar.com/usd/docs/api/class_usd_geom_imageable.html#aa0dfa061a65be443436288f7406ba3db [graphics.pixar.com] and https://graphics.pixar.com/usd/docs/api/class_usd_geom_imageable.html#af47f609f24c8023ddacc6d216eaef0f3 [graphics.pixar.com]

That second method, MakeVisible, is what the Configure Primitive LOP is doing to make the child primitive visible even if some ancestor primitives are invisible.