multithreading volumes/foreach

[freaq]

Hello people,

I'm working on a system that heavily uses volumes, and I notice that the Iso offset node takes abou 60% of the total comuptation time.

also I noticed it is using only a single thread on my quadcore PC, so I would like to multithread...

one way I thought of doing this was using a foreach sop, and splitting the task into 4 eaqual parts, and combining afterwards,

however it seems to be that it is still completing one part at a time combining it with the previous,

this makes sense as I blend the result into the previous one, (thus requiring it to be complete)

however is there no way to let these compute at the smae time and combine the results later?

using a foreach inside a foreach, or am I overengineering this system altogehter and is there a better way to multithread the IsoOffset node.

all thoughts are appreciated.

[graham]

Houdini does not support cooking multiple chains at once. It will cook each input chain one after another. The vast majority of SOPs do not support threading so unfortunately you aren't going to be able to really do much to increase performance.

[freaq]

Houdini does not support cooking multiple chains at once. It will cook each input chain one after another. The vast majority of SOPs do not support threading so unfortunately you aren't going to be able to really do much to increase performance.

so what you are saying is that even if I were to split up the work into say 4 chains,

and then purely combine the resulting meshes in a Foreach, they would still be calculated at the same time?

if that is the case that would be rather sad, I truly hope there is some way around this.

[Klockworks]

so what you are saying is that even if I were to split up the work into say 4 chains,

and then purely combine the resulting meshes in a Foreach, they would still be calculated at the same time?

if that is the case that would be rather sad, I truly hope there is some way around this.

Foreach, for the foreseeable future, will probably remain single threaded. As Graham said, Houdini only cooks one chain at a time, so it's a no go there either. What are you doing that requires an isoOffset?

[freaq]

I need to add/substract several volumes and generate a surface from that,

but to make the volumes I need to generate a volume from some basic geometry first.

the volumes themselves aren't even that slow, it's just converting to and from that takes a lot of CPU time,

and this is mostly because it only uses 12 % of my core i7 (1 thread over an 8 thread cpu...)

[gaurav]

but to make the volumes I need to generate a volume from some basic geometry first.

If you are using simple geo primitives to generate the volume than why not generate the voulme directly using isosurface and use volumemix to mix them.

If i understand isosurface generation correctly, The values are only computed as needed internally during the surface generation.

This means that we could extract an extremely high resolution surface or volume without using much memory to store the scalar field.

Lets say if we are generating a sphere via extracting the isosurface from a scalarfield at a given resolution defined by the divisions and bounds, It is created without ever explicitly computing the scalarfield and and storing it in a 3d grid.

Also if uniform volume density is not an issue, why not generate shapes first, merge them and at once convert them to sdf using isooffset.

Cheers!!

[pclaes]

If you do want to make better use of your multiple cpu's, perhaps consider caching your isooffset to disk. You can split it in 4 pieces and cache each piece seperatly with a rop output driver. You will need to have hqueue or another type of manager running to submit the jobs to - or you launch the hrender commands yourself from a shell.

-- that way it will run 4 non-graphical houdini's. Houdini does not thread yet for stuff like the foreach, but you can launch multiple processes on your local machine.

When the farm is really busy I often have a graphical houdini sessions open and also a few batches that are running locally. I tend to trade disk IO for threading. But with a fast network or a fast hard disk this should be less of a problem. Often the processes are very cpu intensive - but are limited by the lack of threading, so perhaps you can consider this as an alternative workflow. Once it is set up it is quite nice to use your own machine as a small render farm. The stuff just runs in the background and you limit the amount of cores it can take per process.