HtoA - Procs frequently disappear in render view

[Andrew_Wilkins1]

Hi,

While doing some render testing (with Arnold Proc rock assets and Operators) in HtoA — I've noticed that the "Arnold Procedural" are frequently disappearing (likely unloading from the cache) in the Render View which a "Render - Regenerate shadow maps and render" doesn't solve.

The only thing that fixes it is re-opening the Render View, which is highly frustrating to do this constantly.

Is this a known issue?

All the best,

Andrew

---

Houdini: 18.5.596
HtoA: 5.6.3.0
Arnold: 6.2.1.1

[Stephen.Blair]

What are the operators doing to the procedural, and what kind of procedural (alembic? ass? packed?)

[Andrew_Wilkins1]

Hi,

• Procedurals reading an ASS file
• Operators mainly Set Parameter

Sometimes you're adding assets one-by-one to a Collection and render testing, and then multiple / all the assets would disappear. Only re-opening the render view seemed to correctly refresh the cache.

I suspect this is could be relating to my other post:

https://answers.arnoldrenderer.com/questions/34365/htoa-chaining-set-parameter.html?childToView=3445...

eg. where you're disabling primary visibility on assets which you're adding to a collection one-by-one, it works until you hit a certain asset (likely the asset which is being hit by a ray first and loading in the ASS file?) which then decides to apply to all the procs. Due to "auto-instancing".

---

side-note:

Would be cool if there was a way to have a Set Parameter or a toggle on it that doesn't just modify the ASS contents at render time—which doesn't seem to play well with auto-instancing.
ie. it just modifies the actual parameter in the scene. Cause then I would assume it would work with auto-instancing (ie. like you would change the parameters manually and that works with auto-instancing)

Andrew

[Stephen.Blair]

Sounds like an issue with the IPR updates in HtoA.

In the case where all the procedurals load the same ass file...

• As you set primary visibility one-by-one, you're setting it on specific instances, so it shouldn't hide them all
• The cached, original object is the first one that is loaded

Procedurals are loaded before any rays are cast, during scene initialization.

Set parameter modifies the Arnold nodes and parameters in RAM.

[Andrew_Wilkins1]

Is it reproduce-able on your side?
Thanks yeah, the behavior you mentioned it what I'm expecting

Here's an example of disabling prim vis on one asset. Works until I re-enable auto-instancing.

• Proc rocks, same ASS file.
• Set_Rock_A_Proc_11 is in the fore-ground

Everything is working as I've intended but "auto-instancing" is disabled on that FG rock.

Turn on "auto-instancing" the rock disappears
(As I assume everything is now being "prim vis disabled" but I haven't done this with the operators)

Collections & Set Parameter nodes

I've had the same thing happen with "Set Parameter - Matte" & "Disable Operator" nodes.
Sometimes they apply to everything and sometimes they don't.

This issue is making it quite difficult to build a stable lighting workflow, as common lighting practices such as: render pass specific "matte, phantom and pruning" for example, are behaving very unpredictably.

Andrew

[Stephen.Blair]

Nope, I haven't had any problems yet. I set up a scene using the same names for the procedural nodes and the same collections.

Note that your collections are also grabbing the objects loaded by the procedural node. It's enough just to hide the procedural node, so you could do something like this:
*.(@node=='procedural') and #set and not #fg_rock

[Andrew_Wilkins1]

Interesting!
Yeah I've tried a lot of options, haha

"objects loaded by the procedural node"

Which objects are those? The nodes within "arnold_procedural_viewport1"?
Or the name of the "rock_asset_v001.ass" ?

---

Ok so using:

*.(@node=='procedural') and #set and not #fg_rock

With "auto-instancing" re-enabled on all the procedural nodes

Working a lot better! The fore-ground rock is visible while the rest are correctly prim vis disabled.

But somehow the ground geometry has decided to re-appear...

Excuse the change in lighting 😉

[Stephen.Blair]

"objects loaded by the procedural node"

Which objects are those? The nodes within "arnold_procedural_viewport1"?
Or the name of the "rock_asset_v001.ass" ?

The objects in the ass file.

[Stephen.Blair]

The ground is a polygon mesh?

With "*.(@node=='procedural') and" in the selection, the polymesh isn't selected and so isn't hidden.

[Stephen.Blair]

And is the ground part of #set ?

[am_wilkins]

Hey, still me—seems I may have lost all of my previous account with the autodesk shenanigans. Pretty sad. I'm now a "reputation 1" noob. ;]

Yeah, so the ground is a polygon mesh and part of the #set collection, so in theory I would assume it should still disable "prim vis" on it.

[Stephen.Blair]

Ok, I'll test with that setup, but it's still only 6:30 am here...

I'll check your user account and see if there's anything I can do.

[am_wilkins]

Oh, why are you awake :hot_beverage:
Thanks 🙂

I've also tried a collection with * for sel and called "all" but that also fails.

[am_wilkins]

Right...
from the .ass, the original rock

polymesh
{
 name /obj/Set_Rock_A_0/polygons
 matrix

[Stephen.Blair]

For the original issue: objects disappearing and auto-instancing

That's because the collection selection was getting the polymesh shapes and the procedural node that loads those shapes. So with auto-instancing, we were instancing hidden shapes.

The solution is to either do something with *.(@node=='procedural'), or add "/procedural" to the #fg_rock selection string (eg *Set_Rock_A_Proc_1[346]/procedural instead of *Set_Rock_A_Proc_1[346]* )

[Stephen.Blair]

It looks like andrew.wilkins@triggerfish.co.za does not have an Autodesk account, not any more (it must have had an account before, since you were able to log on to Arnold Answers with it).

[Stephen.Blair]

I think adding "/procedural" to fg_rocks should work (better than using *.(@node=='procedural')

[am_wilkins]

Hi,

Are we trying to get to the actual "procedural_file" ?

/obj/Set_TestA/Set_Rock_A_Proc_11/arnold_procedural_viewport1/procedural_file/*

Not exactly sure, so tried a few things on the #cc_fg_rock collection—such as:

/obj/Set_TestA/Set_Rock_A_Proc_11/arnold_procedural_viewport1/procedural_file/*

*Set_Rock_A_Proc_11/arnold_procedural_viewport1/procedural_file/*

*Set_Rock_A_Proc_11/*procedural*/*procedural*

*Set_Rock_A_Proc_11/*procedural*

etc.

None of these seem to work

[Stephen.Blair]

For an Arnold Procedural node in a Houdini scene, HtoA creates a node with a name like /obj/Set_Rock_A_Proc_06/procedural

So a selection like *Set_Rock_A_Proc_1[06]/procedural matches Set_Rock_A_Proc_10/procedural and Set_Rock_A_Proc_16/procedural

In a debug-verbosity log, we'd see this:

00:00:31   256MB         |  [operators] cook op: '/out/set_parameter1' | node: '/obj/Set_Rock_A_Proc_10/procedural'
00:00:31   257MB         |  [operators] cook op: '/out/set_parameter1' | node: '/obj/Set_Rock_A_Proc_16/procedural'

[am_wilkins]

Hmmm, thanks. Yeah I'm not having much luck

As a selection expression on the #fg_rock collection

*Set_Rock_A_Proc_11*/*procedural*

—this works if I disable "auto-instancing" but nothing appears in the render with "auto-instancing" enabled.

Tried some square brackets, haven't manged to get anything working using this approach

*Set_Rock_A_Proc_1[06]/procedural