Search - User list
Full Version: HDAprocessor with Geometry Attribute as input and output?
Root » PDG/TOPs » HDAprocessor with Geometry Attribute as input and output?
Andr
I'm using a hdaprocessor inside a Top Geometry Node, and I need to execute it without writing or loading any file to disk.
The Top Geometry Node should display the geometry from memory.

My setup:
a geometry import node stores the input geometry as Geometry Attribute, than feed it to the hdaprocessor.
I don't know how to tell the hdaprocessor to use Geometry Attribute as asset inputs.
And I don't know either how to tel the processor to save the processed workitems as Geometry Attribute.

Do you have any hint?
Thanks a lot!
tpetrick
The Geometry Attribute type can only be used with nodes that cook in-process, such as the Geometry Import and Invoke TOP. It cannot be used with an HDA processor because work items in the HDA processor cook out of process, and therefore have to load/save geometry to disk.
Andr
Oh I see, thanks.

With the Invoke Sop will the workitems be processed in parallel?

When I cook the Invoke Top, I always see running 47 cooking workitems (I have a 24 cores machine).
No matter what number I set for the total available slots in the local scheduler, It seems to be enforced the "Equal amount of cores less one" setting.
tpetrick
The Invoke TOP creates in process work items, so won't be affect by the settings on the local scheduler (which runs work items out of process).

By default, PDG evaluates in process work items directly inline with the graph evaluation. If you want to configure the number of concurrent in process items, you can create an In Process Scheduler instance (https://www.sidefx.com/docs/houdini/nodes/top/inprocessscheduler.html) and assign to the Invoke TOP.
Andr
AH, thanks for clarifying!
cheers
Andr
I see that the Invoke Top will run anyway even when 'Enable Compiling' in the Compile End node is left unchecked.
Will the Invoke Top enforce the compiling of the block anyway?

I'm asking because it turns out that some nodes run very slow when inside a compile block.
In my case, I need to invoke a feedback loop, because that's where the heaviest operations happen in my Sop Network and I want to split the geometry in pieces to be processed in parallel during the feedback loop.

I've found that a compiled feedback loop runs significantly slower than a non-compiled feedback loop, and increasingly slower if you feed into it a bigger geometry or run more iterations.

So at the end it might be not worth to invoke a feedback loop from Sop into a top network...
Andr
I did some testing with a feedback loop inside a compiled block, trying both 'Enable Compiling' On and Off.
The Invoke TOP would cook in both cases in same amount of time.
Whether it enforces the compiling or not, it seems to be anyway faster than just running a feedback loop in the Sop Network.


However the INVOKE TOP does not seem to be very stable or reliable with more complex feedback loops.
I experienced few crashes with Houdini suddenly closing without notice; another time it couldn't proceed over the beginning "EXECUTING VEX". Another time it simply could not finish the cook, and tried to cook last workitem forever so that I had to interrupt it manually.

The sudden closing down of Houdini seems to occur when the feedback loop has many iterations.


I attached an example file that reproduce the crash and submitted a bug report to the support.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB