Planning the optimal connections of OPs

[magneto]

Hi,

If you have a relatively complex network for instance a geometry network, does it matter if some other OPs are connected at the end of the OP stream or midstream, when the incoming OP doesn't care about what comes after this midstream OP?

I mean something like:

[ grid ] ---------------> [ mountain ]

[ attribCreate ]

[ attribCreate ]

[ attribCreate ]

[ color ]

So the Color SOP uses the 3 attributes but the Mountain SOP doesn't care about the attributes.

In this care if the mountain was coming after the Color SOP vs the Grid SOP, does it matter performance wise?

[ehsan parizi]

Hi,

If you have a relatively complex network for instance a geometry network, does it matter if some other OPs are connected at the end of the OP stream or midstream, when the incoming OP doesn't care about what comes after this midstream OP?

I mean something like:

[ grid ] ---------------> [ mountain ]

[ attribCreate ]

[ attribCreate ]

[ attribCreate ]

[ color ]

So the Color SOP uses the 3 attributes but the Mountain SOP doesn't care about the attributes.

In this care if the mountain was coming after the Color SOP vs the Grid SOP, does it matter performance wise?

it doesn't matter as long as you're not using those attributes in your mountain sop! Although it's a good idea ( if you have too many attributes) to add your attributes when you need them, I've seen some people deleting the attributes when they don't need it, and it makes perfect sense, because you'll have less data.

but the other thing is, if your mountain sop comes after the color sop, and your color type is set to bounding box, then you'll get different result, than the current setup with color type of bounding box.

Edited November 16, 2011 by ehsan parizi

[symek]

Actually it does, but it's really hardly noticeable unless you deal with very heavy geometry. The nature of SOPs is that every nodes pushes forward (actually pulls from above), a bgeo file kept in memory. Bgeo, the same as the one on disk, is sent via wires there, so the smaller data amount the better. This doesn't mean nuking every attribute after usage is good, since deleting it may take longer than keeping it untouched. Groups are particularly heavy prior H12.

So there are no clear answers here. Some tips is to reuse attributes (use Cd or N as temp containers unless you need them untouched), strip away all but necessary attributes for rendering, use float[3] not vector, if you don't need an attribs to be transformed in space.

Note though, Houdini is really good at handling big networks of operators with lots' of loads (it slows down displaying it, but computing networks is usually efficient unless you use some node, which by itself is slow).

cheers,

skk.

[magneto]

Thanks guys very informative responses. And Symek love your detailed knowledge my friend. I will use these tricks