Hello,

Are there any rules/style guides or best practices for organizing a Network View, such as using specific colors or shapes for nodes/groups?

For instance, in programming, there are always best practices for naming and structure.
You can check an example here:
https://google.github.io/styleguide/ [google.github.io]

However, I can't find anything related to Network View.
Is there any standard for it?

Could you please share your organizational style with others and explain why you choose to organize in this particular way rather than another?

Thank you for your attention.

When I have a long chain of nodes ill organize them via subnetworks. I group all nodes that contribute to a specific task and label the subnetwork accordingly. For example all nodes that give or alter scale on some points are grouped to a subnet called scale. I color code animated nodes green, cashes yellow and so on. I also prefer to use a object merge to connect nodes that are far away. Long noodles can be distracting. Ill guess it really depends on your Kind of setups and workflow. There a many ways to do it. I try to evade giagantic node structures if possible.

Cheers
CYTE

Hello CYTE,

Could I kindly ask you to share some screenshots? I recently started using Houdini and would like to see how others organize their work. I haven't been able to find any articles on this topic. It seems that everyone is focused on achieving quick results and often overlooks the importance of organization. When working on a project for days or weeks, having a proper structure is crucial to avoid getting lost and wasting time trying to find or add elements.

I would appreciate seeing how others manage their setups.

Thank you very much CYTE.

In general, improving the readability of your Houdini networks is a good practice, but there are no strict, universal rules. We all develop our own styles.

Here are some of the guidelines I follow to make my networks easier to navigate:

1. Distinct Colors: I use different colors for input and output nodes (yellow for input, green for output) to quickly identify the flow of data. smth like: OUT_name_of_the_output
   
2. Framed Logic Blocks: I like to put a frame around each logical grouping of nodes and add a very short note (1-5 words max) that describes what that section does.
   
3. Numbered Notes: I find it helpful to leave notes with numbered steps (1, 2, 3...) that guide someone through the setup process.
   
4. Single Object Node (Usually): I generally prefer to keep everything within a single object node. Jumping between multiple object nodes can get messy quickly.
   
5. +1 for the above: Use a object merge to connect nodes that are far away.
   
6. All materials to start from "M_" when I'm not lazy
   
7. If you have 3+ similar blocks of code please make an OTL out of it
   

you can check out my hip file here [houdinitools.gumroad.com] to get a sense of what I'm saying

also somewhat related, I hate the UE style of nodes and I rant [www.sidefx.com] about it here:

"Are there any rules/style guides or best practices for organizing a Network View"

I would say don't bother thinking about it.

I would suggest first learing how to use Houdini for your specific purposes and workflows;
Then consider how to organize your Network View and other associated organizing schemes.

Overtime your workflows are likely to change along with how you organize too to support those changes.

Looking at organization first is like putting the cart before the horse IMHO when it comes to Houdini; Unless of course you already have somewhat of an idea of what you are planning to do specificly, then in such a case thinking about Organizing can save you some time.

I have some vague advice in this video at this time offset, you might find the rest of the video useful too:

https://youtu.be/KONIvmOELu8?list=PLXNFA1EysfYk5TFPBvlqKw5fx2tij4cPw&t=1074 [youtu.be]

Hello Ivan L,
Thank you for your response.

I greatly appreciate the HIP file you provided. After reviewing how you structure a project, I can confidently say that I am very pleased with my purchase. The project indeed has a very well-organized structure. I truly like it! Everything appears to be excellently structured. It is definitely a good reference. Thank you once again.



Hello BabaJ,
Thank you for your response.

You are absolutely right. It is crucial to get started, and as experience and project complexity grow, the need for an efficient structure becomes evident. For example, when starting a web development project involving multiple teams, it is essential to create a clear structure and code conduct. Without these, the project can become difficult to manage. Everyone needs to be on the same page. Even if you initially code in your own style, eventually you will need to refactor your code to align with the corporate style guide. This is why I am very interested in these aspects. Node organization is very important to me because I want to avoid future headaches. Thank you again for your response.



Hello mestela,
Thank you for your response.

The video is good, and I am grateful for it and will watch these series this weekend.
Thank you again for your response.

It's very personal though studios tend to have some rough guidelines.

I personally prefer flat hierarchies inside fewer Obj containers and less subnets to minimize diving in and out frequently.

One thing I like is to use Object Merge inside the same Obj container with proper null refs, colors, etc. But it can make debugging the network a bit harder if they are very far from where the source nodes are.

Some good tips and advice here, as always. You'll find your own preferences and style, which will be very much dependent on you and the nature of your work. An analogous question might be : "How to organise the files and folders on my computer?" Houdini has that level of flexibility. Each of us will do that differently and, while there are some useful points to note - above, there is no 'right answer'; it's something you'll feel your way into over time.

Hello animatrix_,
Thank you for your response.

I will keep an eye on your Pragmatic course because I truly appreciate everything that is pragmatic. Achieving extraordinary results requires a pragmatic plan.



Hello Mike_A,
Thank you for your response.

I completely agree with you. Just as when I worked in 3DS Max, every layer had its name, and every group had its proper name. Everything needs to be organized at least to a minimal level to avoid headaches.



I would like people to share their Network Views more often, as Ivan L, Mestela, and Animatrix_ did. It will help more people, especially beginners like me, to understand how professionals work in the world of Houdini.

Thank you all very much.

Does anyone have any suggestions or tips on nesting different types of networks? It's bending my brain a little that you can have different types of networks inside other types of networks. When is it best to use the default networks and when is it best to nest?

I wouldn't recommend using the default root level networks

I tend to use just /obj and then have all other network types nested there like /obj/matnet1, /obj/ropnet1, /obj/lopnet1, ...

Sometimes nested even deeper depending on what the scene file contains

I tend to think about what belongs together and try to keep it that way, it makes for much easier copy/paste experience as you can select everything and copy at the same time than having to hunt for things in multiple root level networks
Also encapsulating the whole multi-context setup into subnets or hdas is much easier as you can't really do that if using multiple root level networks

Thanks, Tamte. That's really helpful.