Hi !

I'd like to start today a topic on Modeling workflow in Houdini.
I've started a project with a lot of vehicles, fully modeled in houdini. But I'm facing several questions about the modeling workflow.

Houdini offers artists a lot of ways to manage objects, scenes, organization. And I'd like to have feedbacks on the way you guys, creates objects.

Basically, the question is :

:: Do you prefer dealing with :

1- One geometry object, everything inside (subnetworks) :



2- One subnet with a lot a geometry objects inside linked together



Both have advantages and inconvenients. Both could have consequences on the rest of the pipeline (texturing, shading, rigging).

Here is a list of what I've noticed

## All inside Geometry object
—————————–
:: Advantages ::
1) Don't need to navigate through serveral objects.
2) Don't need to deal with object merges and the merge methods (None, Into this object, Into Specified Object)
3) You can use wrangles to create tools and expressions
4) You can instance objects with copy to points and edit them later
5) You can template any part of your model
6) You can edit all the geometry at once (Lattice for example or Edit on everything)

:: Inconvenients ::
1) You can be lost with huge tree
2) You can loose initial object orientations
3) Come back later on object parts can be painfull
4) You need to make a lot a groups
5) Maybe need to split object later for rigging ?


## Lot of geometry objects
—————————
:: Advantages ::
1) Smaller trees by objects
2) Don't need to manage to many groups
3) You can keep initial object position (usefull for export kitbashing for example)
4) You can link object together with constraints, easy to rig

:: Inconvenients ::
1) The instance node can't be edited
2) You need to navigate through objects to adjust them, show them, show parts of them
3) Need to manage object merge method (None, Into this object, Into Specified Object)
4) You need to use python for tools instead of vex
5) Can't edit whole geometry (lattice, create common groups)

So this is just few things I've noticed, but I know in every cases, we have solutions to do what we want.

I use to work with the first solution, but this mean to be organized :
- create subnetworks with objects inside (and keep initial poses)
- create hda tools (for example align tool, scatter tools…)
- create groups and subgroups per object (inside subnetworks)
- create python tools to split objects if needed (per group name, per connected elements, etc)

So, now, what about you ?

Both of those approaches have the downside that they leave a lot of complexity either at the object or geometry level. Since vehicles typically have lots more geometry than articulation, have you considered baking the model down to bgeo (or abc or usd) along with the required artic inputs (pivots, coordinate frames etc) and then reimporting that back into houdini to apply rigging?

When you are talking about the modeling as your message suggests, the first method is the only method in Houdini, because the modeling means that you are operating on some geometry/surface using Surface OPerators (SOP-s). Putting objects in the hierarchy is not modeling, that is, I don't know, kitbashing or rigging? Modeling is manipulating geometry, not rearranging already modeled geometry containers in hierarchy. I prefer that method since it is more logical to have all the elements of one object inside of one object. Jumping up and down from node to node is sometimes tedious task and my operations are hidden. Working in sops is more intuitive, like a circuit board, you can see all your operations laid in front of you. That is why we love Houdini, no? The problems you list under the first method are the rigging problems, not modeling. If you have problems in figuring the orientation or you are worried about making a lot of groups, that is only when you start to think how the thing is going to move, and with that we are going into the rigging territory. Btw, using python tools instead of vex is also confusing statement. Vex is vector operating expression used to manipulate geometry, shaders, attributes in general and the biggest advantage is that most of the operations in houdini are already vex based so it is easy to adopt new algorithms or ideas in manipulating data on a fly. On the other hand, python is a scripting language which you can use to optimize certain user interface scenarios and automate lot of your tasks, but the python script is not the same as performing a multithreaded expression which operates in parallel on every point of your geometry, for example. So even comparing python and vex is misunderstanding, since it is not the same context.

Good question
I used to use first method: all meshes all together.
You described many downsides of this method similar to what I encountered.

I kinda like method 2 now where each mesh is in its own object container, only downside for me is unable to quickly edit multiple meshes, latices etc just as you said.
But python eliminates this issue. I also find this method more convenient for navigation because it allows me select geos right in the view port. For the first method i had to use references, not so convenient.
I'd say method 2 in general works faster for me.

Very good Question! I was just wondering about this just yesterday. Snapping a pivot of an OBJ to a point on that same OBJ doesn't seem to be possible (except by cloning it first and then snapping to the clone then deleting the clone!). It made me wonder about when to work on the OBJ level and when to jump inside. Thanks

I usually like to have everything inside of one tree. The main issue I have with this is transform speed. You will inevitably end up merging many of those objects together and positioning them.

Unfortunately, since everything is inside of one geometry, these transforms happen on the vertex level, which is very very slow. Obviously, because you transform e.g. 100K vertices rather than 1 object.

I'd say if the objects don't need to interact closely, it's preferrable to split them up into multiple objects. I must get used to this myself..

Another problem with a single tree is that showing and hiding different objects is inconvenient.