Usually I do fx stuff with ICE, but from time to time I have to shade and light a car…
As these tend to have 1000+ objects I am asking myself how to organize this stuff.
Say the car comes in as an alembic file. In the best case all objects are named properly, maybe its a very special day and they are named after the material, usually they are not. (operators converting cad to something usable are some lazy bastards), but lets pretend they are named like this:
tire_rubber, tire_brushed_steel, tire_plastic, light_glass, light_chrome…

So there I sit with an unpacked alembic archive and have to set up the materials.

I could write a script that reads all group names, set up materials inside a shopnetwork named after the primitive groups inside that abc file and plug in a dozen material nodes or just one material node with dozens groups inside. fill in parameters values and could start to dive into shading.

I am pretty sure that you guys do this in a more houdinish way.

I am pretty sure that you guys do this in a more houdinish way.

Except for patterns matching [sidefx.com] not really. So, for example, you usually do one tab per material in MaterialSOP specifying that anything with glass at the end should go with glass material:

Group: *_glass
Material: /shop/glass

Alternatively you could go fancy with AttributeCreateSOP. If you create an attribute shop_materialpath pointing to your materials, you can apply them without MaterialSOP. How you derive string attribute from a group/object/other attribute/database, that's another topic.

You could for example use ForeachSOP: add AttributeCreateSOP inside, make above attribute of class primitive, type string with an expression like this:

`{
string groupname = stamps(“../..”, “FORVALUE”, “”);
string splitname = strreplace(groupname, “_”, “ ”);
string material = arg(splitname, argc(splitname)-1);
return strcat(“/shop/”, material);
}`

This will set shop_materialpath with values like: /shop/rubber for a group named like: what_ever_rubber.


ps I actually don't remember when I used last time such an expression, but I should make nostalgia HDA from it .

So I need to have proper name conventions for having things accessible in a somewhat easy way.
If not, traversing the geometry networks holding all that data is fubar..
that is really bad news.

Which concepts could be applied to such scenarios? I am sure you guys are fumbling with some heavy assets.
Procedural geometry created via Houdini is set up properly, but assets coming from elsewhere need some heavy authoring. Inside another package?
I refuse to believe that.

Don't get me wrong, I am not bashing. I really need to know how to handle such assets.

Well, you need something, some naming convention isnt't that bad

I work occasionally with fbx consisting with +20.000 pieces scattered in separate subnets. Pattern matching, objects mergres and group renames and combining (see Group Sop last tab) are common idioms, and they usually do the trick. I don't think there another application allowing me to deal with such vast network without scripting… From time to time I have to write 5 lines of Python if things are particulary hairy, but that is all.

I also constantly have to deal with group changing during production and an even topology changes in character meshes. In latter case it's enough for an animator to select different meshes under a single animated model in a wrong order and Xsi won't keep point ordering. Without MatchTopologySOP I would be lost.

Your alembic can be split across different objects with patterns ans Object Merge Sop or combined, groups canbe renamed or merged based on pattern matching too. I see it as extremely powerful toolkit for complicated objects. At least I have no idea how would I do the same in Maya or Xsi :shock:


Post your nightmare once you encounter it!

thanks for the insight.
Ive started yesterday with an old alembic file and stumble upon the question how to deal with this kind of problem.

naming conventions are essential to everything. but thats just in my book. as freelancer, one is rarely in the positions to dictate conventions

so basically you have an alembic import sitting on obj or sop level.
then you object merge elements in different geometry networks, separate stuff by grouping names. makes sense.

I imaging one would encounter some performance issues when unpacking into several geo networks. Speculating right now, I really have to go thru it.

I always make sure naming conventions are set up. Working as a freelance and small shops of less than 5 with engineers/clients, it's crucial. Time is more critical. With engineers it's even harder, and that's why include Clean Up time in cost quotes. I mean if you can't name your stuff, logically it'll take me more time to get it going.

But I agree, with a Material SOP, setting up materials for objects that have even over a dozen different unique items/groups gets tedious. If group selection allowed multiple selection at one time with live updates of said selections, that'd be a great way to make it more efficient. Wildcards are great but sometimes not enough.

Even if Group Selection mimic'd bundle selection in the Mantra ROP.

Gyroscope
Even if Group Selection mimic'd bundle selection in the Mantra ROP.

That's actually very wise suggestion. RFE it!

Cars ! . Id have the modeller merge by material type, then use a UDIM workflow , that way you cut down on the amount of parts and material shop nodes !

Rob

I did use a method in the past that was quite successful and was based on analysing the geometry shape.

The thinking goes like this, small square pieces are bolts, big flat pieces are doors, etc…

What I did was run an analysis and calculated the volume of each piece, then calculated the flatness factor or elongation factor and attach these custom properties to each object.

After that I run a serious of scripts and assign various metal materials to these objects based on these values; volume, flatness, elongation and proceed to tweak by hand.

It gave me a really good start for a huge dataset at it was only on the various key objects that I had to spend some time by hand, the rest was quite good straight away.

hope it helps

finally found the time to get through the whole process.
Ive organized every shape in the alembic file with a proper naming convention.
In Houdini loaded the alembic file as houdini geo.
From there I've separated the tire, car_body and light elements into geometry networks via object merge sops.
Then put in a shopnetwork in every geonetwork, don"t know if its a good idea, I found it kinda nice. Having geometry and material library (xsi-lingo) at the same spot.
Build up some materials and attached them to my prim groups with the material sop.

Couple things Ive noticed.
As soon as Ive switched the Alembic sop to load houdini geometry, every move elsewhere meant significant increase in cooking time. Also when the alembic output is locked.. which I don't want to do, resulting just in a 1 gb hip file.
I am used to XSI behave like a snail on ketamine as soon a fair amount of geometry is loaded in. But Houdini began to crawl on every level switch, material create etc.. Switching off the scene view, helped a a lot. (blame the opengl draw, its the same with xsi btw.)

At some point I could not relate to some prim group names (despite my genius naming convention ;p ). So I tried to select them in the viewport and could not figure out their names. The only way was to tab select a delete sop and read the resulting group name value.

I thought at first assigning materials that way would be kinda painful, but I have to admit that it is quite the opposite.
Guess one has to type more than drag n drop in Houdini.

On a side node. I suppose houdini (and htoa) is exporting all that geo to render when using the ‘load as houdini geomtry’ mode in the alembic sop. I would like to stay on the delayed load, but I am not sure how to handle material assignments and rigging then.

Then put in a shopnetwork in every geonetwork, don"t know if its a good idea, I found it kinda nice. Having geometry and material library (xsi-lingo) at the same spot.
Build up some materials and attached them to my prim groups with the material sop.

Dont do that , 1 shop network is all thats required and secondly dont load in all the geo > do stuff , then just leave it. Write it all back out to disk.

Rob

Hey Rob,

Care to explain to me why I should just use one shop network?
Do you mean to write the separated geo networks out and assign mats then?
Please elaborate a bit more on that.
Thanks
Sebastian

Hi,
Once you get your head round scene management in Houdini your going to find it a breeze. right now funny enough I am working on a pipeline to handle cars for a new venture I am working on. see attached for a basic structure you can use.


Rob

If I model in another app or get model that is done in another app, and most of the time as obj. I made script that goes through groups, ‘extracts’ them as geos (and do few more things). So instead of one geo node I have several, based on groups. I like it that way, just easier for me to organize. Not sure if this is correct workflow, but I hate when I see material SOP with billion of tabs … Also you can drag and drop materials in IPR as bonus

In both ways you end up having copies of the source geometry on disk.
On the fly caching is a breeze in Houdini, but I struggle a bit with the idea to have n-duplicates of the source asset.

Thats why I like the alembic format so much. Referencing just one file. Problem is that one has to unpack it to assign materials..
alembic per material group would come to mind.

if you want to assign material per packed primitive, you don't need to unpack
after all material sop just assigns “shop_materialpath” attribute to primitives,
you can also use packed edit and pack/unpack.

NICE!

Let me try this on a production asset.

Ive build a tree (btw how cool is that python sop!) to create packed prims by primitive groups.
I know the assemble sop is used for similar scenarios but in my case I have 200 prim groups like this: car_body_paint00, car_body_paint01, . . . , light_chrome0, light_chrome1, …

its cooking for some time, its python after all.
maybe someone find this useful.

thanks everybody for the insight.
I am ready for the next car job

btw how cool is that python sop!

yeah, it is, but it can get slow

sorry, couldn't help myself (an alternative)

that looks more houdinish.

Unfortunately I can't preserve my path attributes when I save them packed prims into an alembic file. bgeo works fine.
after loading the abc file I get what looks like a reference to the pack sop instead having a proper naming for each prim.