I´ve found a solution, but still don´t know what has caused the problem.

In the python shell u must set JOB in the environment before opening the hipfile, using:

import os
os.environ = “path/to/project/folder”
and then
hou.allowEnvironmentToOverwriteVariable(“JOB”,True)

And then you open the hip file.

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!

I´m having the same problem and my file has the “SET -g JOB” overriding the variable.
Have you found a solution?

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.

Any news or roadmap to that feature?

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.

Yes, I´ve seen in the journals. Thanks Brandon!

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?

Just confirming that, on build 473 the configure primitive LOP is working and changing the prim visibility.

Thanks!

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?

Yes, the scene graph shows that the prims are invisible (attached file).
I´m on build 456. I´ll update to see if it was the problem.

Hi, I´me exporting a scene through PDG using the ROP USD Output. But I don´t know why the first frame is exported without a time-stamped value (attached image).
I´ve got the same result when exporting through solaris USD ROP.

Thanks!

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.

Thanks for the fast reply! For the config prim LOP, can you test with the attached alembic? It´s the alembic exported from the hiplc file I´ve attached in the first post. There is a LOP net in that file too.

I managed to fix with a wrangle and the function: “usd_setvisible(0, s@primpath, 1);”
One question on that: why “s@visibility = ‘visible’;” don´t work?

Hi,

I have an alembic with objects hidden. Is the correct workflow to use the “configure primitive” LOP to change the visibility back to visible? (attached images)
I tried that without sucess…

Hi,

I´m rendering a scene using a baked .usd file on disk, through PDG (USD Render). It works well if I have 1 frame per batch, but if I increase it or use “all frames in one batch”, I get the error: “Output file #### should have variables”. The task completes but karma doesn´t save any image.
Is that a bug?

BrandonA
Hi there! Do you have the Input File Source set to “Upstream Output Files”? This option can be used to provide a variable number of inputs.

Yes, I have. I´m using the “upstream outputs” as my geo source for the hdas. As you can see in the attached image, I have two brunches, the left one is for the hdas that have inputs and the right one is for the hdas that don´t have inputs. If merged, I´ve got errors.
But I can´t override “Create Input Files” with attributes, and that is a problem.

(1) It makes sense for you that parameter overrides (with attributes) only works if the hda processor is set to dynamic?
(2) Is the “hda service pool” working fine? In the same setup I´ve got errors with the pool, but without it works fine.
(3) The parameters created on the hda processor´s “HDA Parameters” tab don´t append the prefix to the “disable when” expression. Would it be better to have blanc expression and we have access to the parameters than (current) don´t have access at all

As a side note, the previous version of the node (without the need of “hdaparms_int” and so on) was far easier (don´t know if better) to work with. In the current state, we have to use python (AFAIK) to create the array attributes to make the overrides.

BrandonA
Currently, it would require the second method (using an attribute in the Hda Path parameter on the Hda Processor node). Do you have a case where it requires the first method (recognizing the @hda attribute automatically)?

Brandon, as I said, I don´t need to recognize the hda path automatically, because referencing the path attribute in the parameter works fine. But other problems arise: since I´m using one hda processor to process several hdas, some of them don´t have inputs and other have, and the node errors out for the hdas that don´t have inputs.

One possible solution would be overriding the hda processor´s parameters with attributes with the same name, but that doesn´t seem to work now.
This kind of workflow would be far more procedural than using several hda processors to account for those problems.

thanks.

BrandonA
Currently, it would require the second method (using an attribute in the Hda Path parameter on the Hda Processor node). Do you have a case where it require the first method (recognizing the @hda attribute automatically)?

No, I don´t have. I thing using the attribute in the parameter would be the same. Was just a question… just to know if the fix would change that behavior too.

But I´m using the hda path attribute in the parameter to process a different hda on each task. I just needed the fix to control each hda parameter with attributes.

Thanks Brandon!

Brandon, one more question: could we use the @hda attrib to set the hda path automatically or should we use an attribute in the hda path parameter, on the HDA Processor node?

BrandonA
It looks like something changed recently that caused this workflow to no longer work (HDA Processor was clearing the hdaparms_* attributes). I've updated the node so it will no longer clear those attributes if you have disabled all of the HDA's parameters. This fix is available in tomorrow's build!

Thanks Brandon! That was driving me nuts! I thought that I was doing something wrong!

Did someone manage to make It work? (the attributes override HDA parameters)

1. I disabled all the HDA´s parameters (they don´t appear in the HDA Parameters tab anymore).
2. I create a “type” int attrib with values 0 to 3.
3. I create a string attrib “hdaparams_ints” and set it to “type” - tried single string attrib and string array attrib.

Never works, It only cooks with the HDA´s default values.

Soothsayer
The Logo is gone from the renders in .309. Now I don't know if this is a bug or a feature but the render size seems limited to 1024*540. I use the renderproduct LOP to set the size (for prman23).

Edit: And Karma STILL has the logo on renders.

do you still have houdini logo on renders? I´m having this problem with 431 here…

Hi guys,

I thought that the license problems with Karma on indie were resolved, but I´m getting watermarks on my renders, on build 418. Is that a problem at all or Karma needs another license for indie users?


Found that Indie comes with only 1 Karma license.

johnmather
Hi Guilherme,

Yes - that is the correct solution for this problem. Since the work items are dynamic, you must use dynamic partitioning.

Ok John, thanks for the info!