Hi everyone, first of all, I apologize for the length of this post..

I've been reading the manual for a few days now, and am trying to come to an understanding of the network in H9. I think I'm getting it, but I wanted to confirm my interpretations into a real life template that I downloaded from the internet to make sure I'm on the right path. From these network views (attached below) I can see that the author:

OBJ Context:

1.) Created a Deforming Rigid Body in the object container. This is done to organize the project and was accomplished via the TAB menu??? Not sure of which pane “Deforming RBD” sits. This might just be a label the author used to describe some other node he/she created in the object container. (Disregard error for now, still troubleshooting that as the scene aparently still works regardless of this condition)

And disregard the nodes on the bottom, I've been tinkering.


OBJ/DeformingRBD Context:

2.) In the Deforming RBD node, the author created a DOPNetwork from the TAB menu -> DOPNetwork. This is done to create an organization system to hold dynamic nodes, as dynamic nodes (Such as Gravity) could not be held in the Object container natively.
2.1) Not sure why the Sub-Network icons are here. Don't seem relevant at this time.


OBJ/DeformingRBD/DopNetwork Context:


3.) In the DopNetwork node, groundplane and torus and added to the scene. They were added here so that dynamic nodes could be applied to them, such as gravity.
3.1) torus node is a RBD object which has a SOP path (a path to Simple Operator like the torus) which is in the deformineggo node, which you can't tell from the screen cap. This is done to allow transformations to be applied to the Torus out of band, and take the resultant geometry and apply it as if it were a native torus SOP added in the network. similar to a symbolic link in unix-speak.


4.) Added a merge object to tie any behaviors (correct term?) below the merge node to each of the nodes attached to the North side of the merge.
4.1) In this case, gravity is applied to both the groundplane and torus.


5.) Then added an rbdsolver from the TAB menu to give H9 the ability to do the math for the variables the northbound behaviors added (in this case only Gravity). Without the rbdsolver node, gravity would seem to be useless I believe.


6.) The deforminggeo is some custom node the author created. Used TAB -> SOP Network to create this container for SOP Geometry pieces. Within this node is a Deform-Twist function beneath a torus object.


Thanks for any comments. I think I'm on the right path but I'm not sure if my understanding is entirely correct on all of the details. I'm trying to reverse-engineer other people's projects to learn the ins/outs of H9, and without a trainer, it's really all about reading the manual and working to gain an understanding.

1) Tab>subnet

2.1) They refer to the inputs a level up. They show up even if nothing comes in.

3.1) Dive in and inspect the parameters window. There should be clues as to what it is and what it refers to.


It's a bit of a long post to get through :wink: , good effort though and in general you understood it correctly.

Middle-click stuff and check the parameters window (press ? )

steve.gaas
From these network views (attached below) I can see that the author:

The file you are looking at is a pre-H9 file, so the layout is a bit confusing.

OBJ Context:

1.) Created a Deforming Rigid Body in the object container. This is done to organize the project and was accomplished via the TAB menu??? Not sure of which pane “Deforming RBD” sits. This might just be a label the author used to describe some other node he/she created in the object container. (Disregard error for now, still troubleshooting that as the scene aparently still works regardless of this condition)

And disregard the nodes on the bottom, I've been tinkering.

Yes, the “Deforming …” name is just that.

To make things much clearer for you, RMB on that node and “Extract Contents”, that will expand the sub-network out to it's original network.
You can organize multiple nodes by collapsing them into a subnetwork, Shift-C.
Since there is only the Dop node in the sub-network, the process was redundant.


OBJ/DeformingRBD Context:

2.) In the Deforming RBD node, the author created a DOPNetwork from the TAB menu -> DOPNetwork. This is done to create an organization system to hold dynamic nodes, as dynamic nodes (Such as Gravity) could not be held in the Object container natively.
2.1) Not sure why the Sub-Network icons are here. Don't seem relevant at this time.

Each “type” of editing interface processes data differently. Thus the Dops (Dynamic operators), processes dynamic data. Sops (Surface operations, not simple operators) is an editing interface to generate and deform surface geometry. Each editor is optimized to process data in the given context.


OBJ/DeformingRBD/DopNetwork Context:


3.) In the DopNetwork node, groundplane and torus and added to the scene. They were added here so that dynamic nodes could be applied to them, such as gravity.
3.1) torus node is a RBD object which has a SOP path (a path to Simple Operator like the torus) which is in the deformineggo node, which you can't tell from the screen cap. This is done to allow transformations to be applied to the Torus out of band, and take the resultant geometry and apply it as if it were a native torus SOP added in the network. similar to a symbolic link in unix-speak.

All geometry starts out life as some network of Sops. This geometry is referenced into Dops, and the reference must come from Sop space since the geometry is going to be deformed. Yes it is RBD but the geometry is undergoing a deformation. You don't do deformations at Object/World space level.
Each Object has its own sop space (its own coordinate space), you use Object merge to reference in geometry from their own coordinate space and have it agree with the space the Object merge is used.


4.) Added a merge object to tie any behaviors (correct term?) below the merge node to each of the nodes attached to the North side of the merge.
4.1) In this case, gravity is applied to both the groundplane and torus.


5.) Then added an rbdsolver from the TAB menu to give H9 the ability to do the math for the variables the northbound behaviors added (in this case only Gravity). Without the rbdsolver node, gravity would seem to be useless I believe.

No, Gravity can be used for other things and will work without the RBD solver. Conversely you can have an RBD solution without gravity. They are two different tasks and there is no dependencies between them.
This is one of the fundamental features of Houdini and proceduralism. Each node is usually reduced to a specific, simple function and these are assembled together to achieve the end you want.

6.) The deforminggeo is some custom node the author created. Used TAB -> SOP Network to create this container for SOP Geometry pieces. Within this node is a Deform-Twist function beneath a torus object.


Thanks for any comments. I think I'm on the right path but I'm not sure if my understanding is entirely correct on all of the details. I'm trying to reverse-engineer other people's projects to learn the ins/outs of H9, and without a trainer, it's really all about reading the manual and working to gain an understanding.

My comments are generalities, particularly in houdini there are lots of exceptions. That's the fun part.