Paolo Oliverio

I have an issue when stacking up multiple independent modification in a sop network.
when done in the most simple streightforward way, it makes every modification dependent on every other on top of it and I need to exit this forced dependency with some kind of caching strategy and possibly dirty flagging just the modified node while adding its contribution live to the rest of the cached stack.
First removing the old contribution from the cache if present.

Let me explain it with a simple use case.
Say I have a mesh I want to add multiple displacements on it by attribute wranglers.
every wrangler calculates a displacement vector and doesn't depend on the displaced position of the wrangler before it they just depend on the original P of the undisplaced mesh.
naively I can link these wranglers together and apply the displacement to P in every node and pass the original P in the second input.
This naive link forces the cascade dependency with undesired cooking times.

Probably this use case can be optimized specifically, but I'm looking for a general solution as I need it for few similar use cases and possibly reuse it as a valuable tool during further R&D.

I immagined this pseudo design in steps:

• save displacement vectors somewhere.
  
• have a node to collect reference to these data, calculate and cache the displacement.
  
• on parameter modification take the cached mesh and remove the old contribution flagging this node to dirt(in detail attribute) and make its modification live(view node = cache + live displacement).
  

Naturally if there was a previous live node collapse its vectors and unset the dirty flag before to set the new one to dirt/live and process it.

A key feature for this setup seems to be the Stash node that can be used to break the dependency loop and I guess you may put Python callbacks on parameters to track changes.
Sadly putting callbacks on all the parameters is suboptimal in my use cases.
I would love to have a general solution the more plug and play the better i.e. just specifying how and where to store, apply and revert a specific modification.

Please help me figure out as this is a key feature in a couple of tools I have trivially implemented that would improve a lot with this optimization becoming very interactive even in presence of a massive amount of “modifiers”.

mark
A 17 second start up time is outrageous and shouldn't be happening.
a) When you turn on verbosity in the render, what does the timing report?
b) Do you get the same behaviour if you render directly to disk files (i.e. render from the ROP)?
c) How long does it take for Houdini itself to start up?
d) What happens if you set the engine mode on mantra to “none”?

when I set verbosity from ui it shows nothing in the houdini console is there a different console for mantra?
I also tryed mantra -o consolewait in command.if so How can I show it?and to show houdini console I do an actual printf in vex as I didn't find any other way to show it up.
houdini takes more or less the same time it took to start the first render.
I tryed to switch to standalone license but it takes the same time for both starting houdini and rendering.
how can I set the engine mode on mantra to none?In rendering engine I just find the “normal ones” ie pbr.
Today it went from 18 to 9 seconds for whatever rendering even just a plane.

kahuna031
On windows, I once found that I could speed up the render startup significantly when running as admin.

thanks, I have tested it and I get 18 sec in Mplay with both standard and admin.

twod
The Render View keeps a mantra session running and processes new frames on the fly, whereas rendering to disk spawns a new mantra for each frame you render.

Doesn't it make sense to make an option to force the “listening/interactive” behaviour?
I wonder if it can be made in scripting.

I guess that also other renderers do the same, but Mantra with 17 seconda of warmup per frame is out of any trivial sequential task.
Do you know a renderer I can couple with houdini with faster warmup times?