Hi,

I'm writing a paper for school trying to explain the organization of networks and context, and I'm wondering about the logic behind the folder in /
It didn't really make sense when I first started using Houdini, and it still doesn't.

Here's what I've come up with :

/ch : in which one can only create CHOP networks
/img : in which one can only create COP networks
/obj : in which one can create all types of networks, except obj network, and which manages geometry display and parenting
/out : in which one can create ROPs directly, but every type of networks as well, except a ROP network
/part : in which one can create only POP networks
/shop : in which one can create materials and shaders, but every type of networks as well, except a SHOP network
/vex : in which one can create VOPs and subnet but no other network


/ch and /img seem logical enough, to tidy things up, /part and /vex as well, though I tend to use popnets in sops and vops where I need them.

Now, for /out and /shop, you don't have to create or ROP or SHOP network first and can directly create OPs, why not.

/obj is special since it manages display, parenting and one has to create geometry in it, which are SOP networks, that's ok.


But I don't really understand why one would want to create a SOP network in /out or in /shop, and why it's possible there and not in /ch, /img and /part.

As far as logic goes I thought there's should also be a /dyn for DOP networks, much like the /part.


Well, just my thoughts, maybe this has already been discussed before, but I find it quite confusing.

It won't prevent me to write about the greatness of Houdini next, though!
Vincent

A few releases ago, these networks were the only way to access the different contexts of Houdini. If you wanted a particle network you would set it up in /pop then reference it into a sop network using a pop_merge. vops and shops were also created just below the root level then referenced to the appropriate node when needed.

Once network managers were introduced, it made it easier to encapsulate the different network types into a single network path. This was important when digital assets were first introduced because it was important that an asset could contain any kind of node and keep relationships within the node relative instead of based on “/” - this allows digital assets to encapsulate all aspects of a particular asset in a way that is easier to share.

A Russian doll approach is also starting to take shape with more nodes being set up as containers. For instance instead of pop_merge we now have the pop_net sop which is part of the sop chain but also “contains” the particle network.

With H9, VOP networks can now be contained inside a SHOP which can then be contained inside a material. This packages things up much nicer and helps prevent broken relationships between vopnets and shaders.

Therefore the various contexts you find under / are in many ways a part of Houdini's history that may or may not be needed now that network managers and “container” nodes are being used.

Robert

Everything Rob said is correct, and in addition:

Being able to put things where you want them gives you flexibility and consistency. For example, having all your shaders in /shop gives you a global location for all your shaders. Instead of trying to find the various SHOPs and/or Materials scattered around inside each object, having them all in /shop makes them dead simple to find for someone who maybe didn't build the scene file.

Likewise ROPs, IMO it's essential to have them all in one standard location (i.e. /out) or it becomes a bit of a nightmare to manage. Yes, you can filter them out in the Tree view etc but then you can't wire them together easily for dependencies etc.

I have to be honest, I don't really use /part anymore however it still does have some use. There is a little used but very powerful feature in POPs where you can have a single POPnet (usually in /part) but use it multiple times with different geometry.

As for creating SOPs in /out or /img etc, I have done both these things for various reasons that I've forgotten now, but likely had to do with encapsulating things as Rob mentions.

Oh, and I believe that DOPs live in /obj because DOPs are actually Objects just with special properties, i.e. dynamics. Though I agree it does seem inconsistent but ultimately works fine. Since you can create an OBJ network wherever you want, it shouldn't be too restrictive.

Cheers,

Peter B

Ok, thanks for the explanation, I started with H9 ops:

edit : didn't see your answer before I post mine, Peter, thanks for the added information