Hi all,
I'm building a massive super material type shader that will allow the studio to quickly shade 95% of assets consistently with a high degree of quality/flexibility, and tunned to our particular pipeline (standard AOV outputs, methodology etc).
I have decided to build it modularly, some large Vop modules dealing with the main shading characteristics, and a couple of support modules.

The main modules are:
-Diffuse (direct and indirect lighting)
-Specular (layered specular lobes etc)
-Reflection (layered etc)
-Subsurface
-Emission
-Transparency (with optional refraction etc)
-Displacement

And each main module has a copy or copies of the following support modules:
-Layered textures, up to 5 layers, with separate uv layer selectors, uv transform controls and blending modes, multiplied by number of parameters you want to be texturable,
-Fresnel (with tinting etc)
-Noise (proc textures)

Because its built in a modular way, it should have productivity benefits for those times when we have to build customized vopnet shaders, since each module is still available as an individual tool in the vopnet context. Thus I have built nice an clean interfaces for them (using folders and separators, etc).
However, building these nodes was very painful in some ways.
For example, the Input-Output list in the type properties editor is a major PITA… will no option to re-order the list using drag n drop, thus moving one or more inputs (in a list of 60 or so inputs) is tortuous… click, click, click dozens of times, one at a time……… if you get one wrong and move it above where it should be you might as well open a window and jump… and if you start re-naming the inputs and their respective referenced parameters, chances are that the asset will break… and when it does, I will check that everything matches (don't fancy doing all that again) and still it seems to have irrecoverably lost connections, so I grab a backup.
In addition, its not clever enough to keep the connections through to the internal nodes should you want to rename them. I think this part of the editor needs some really serious attention from sesi… although its not until you make something really huge that you will notice.
In the end I started to plan everything very carefully before jumping in the deep end of the input-output list, and things progressed more quickly.
The Input-Output list needs to have Drag n Drop ability and a button to auto generate the Inputs based on Parameters you have already added.

So I finished making the individual modules and started thinking about making the combo super shader, and its interface… but there is where the problems really start for me.

Big Problem #1

You select a texture module for example, with 60 something inputs, and push “Create Input Parameters”… it puts down the 60 Parameter nodes that will become buttons, colors, sliders etc in the shader. Great, but… it puts the “Parameter Name” in its “Parameter Label”, so I end up with 60 parameters with short lower case Labels that will mean nothing to anyone but myself. Not normally an issue, but normally I don't have such a large number of parameters.
So I figure if I start renaming the layered textures module now and its dozens of copies (720 Parameter Label edits, not counting all the other stuff)… I might not finish before I die of sheer boredom.
It's not possible to do it just once and duplicate it, because copying and pasting the texture module along with its Parameter nodes will generate identical Parameter Names instead of incrementing them with numbers at the end, so they dont work.

In addition, once I worked up the courage to start renaming stuff, the “Create Input Parameters” dumps the nodes stacked on top of each other, fine to start with… you could start from the bottom and carefully work your way up, right? I say carefully because if you accidentally click the wrong one the stacking gets out of whack, and you start to lose the ability to even select nodes, unless you deliberately start creating a mess by quickly moving the nodes out of the way of each other, just to be able to select them.

I've not started renaming a thousand nodes yet, I want to figure out the next problem before I start. In the meantime I'm hoping SESI will change the auto “Create Input Parameter” code so that they automatically use the same Parameter Label as the parameter they were created from… please I beg you!

Big Problem #2

The Material Node… I wanted to use the material node so that I could stick the displacement shader along with the surface shader in the same place, and I'm tired of redoing lots of mundane shite already so this next part is a test with a couple dozen exposed parameters.
The problems start when you click Promote Material Parameters… it dumps them all into a single list. Ideally it should detect parameters that are connected to a single node (say the 60 parameters of my layered textures node) and neatly places them in a nice neat little folder labeled the same as the node they are connected to, it a least a start!

Then I start cleaning it up, duplicating the interfaces I had already built for the Vop nodes, making folders, separators etc… then I decided to create a bunch of other parameters and pushed Create Input Parameters whoosh… everything I just done as just disappeared. Heh!? so every time I add a parameter to the shader I have to rebuild the Material UI???

I figure I would have to build the UI in the Surface Shader node that is inside the Material, and then promote it (there's almost always some kind of logic behind how H does things, which I like)… So… click on “Edit Parameter Interface”, unexpectedly a totally different kind of interface editor will popup, it only lets you re-order and make folders… This gets recognized by the Material node when promoting parameters, but its not good enough, with this shader the list of parameters is a mile long and not being able to collapse folders like in the regular editor is a big PITA…

So, Ok I thought I'd try something else. I created a Vopnet inside the material node, inside that I put a Vop Surface shader and dumped in there the contents of my Super shader. This then becomes available as a Shop that I then connect to the Surface Shader input of the Material. With this Shop I can click “Edit Parameter Interface” (the regular version of this UI) and organize stuff with folders, like before but two better… I get separators, and collapsible folders, whoohoo… not a big deal but its just a much better UI to do make folders in the first place, which begs the question, what's the point of the other list based thing? why are there 2 UI's for doing essentially the same thing?
To add insult to injury when I push the dreaded Promote Material Parameters, it completely ignores the UI of my Shop and again Dumps all the parameters into one enormous list… arghhhhh

What am I supposed to do here? ditch the Material node and use plain Shops instead? and have the SOP Shader node moan at me that I'm supposedly using an antiquated form of shader? Change the Geometry type Interface to include separate displacement fields…

Am I doing something really really stupid?

Thanks for your help

Sergio

hey sergio, i feel your pain. vops need lots of love right now. for instance, theres no if,then,else (or gather, else) construct right now. node inputs only respect input numbers rather than names. plus the whole parameter mess you mentioned. and we havent' even mentioned the super clunky “new look” ui. (why bother making it look different when the old look was fine - we needed new functionality - rather than pointless eye candy). ugh.

so, i hope that sesi are listening here. mantra just rocks - but the ui to interface with mantra has fallen way behind. we need real world production usability. the new “production ready shaders” (haha) just emphasize how out of touch sesi really is with what users really need. it's otu of-the-box useability and intuitiveness that will sell houdini and keep new users interested - and i hope that v10 will concentrate on. it's come so far recently - so i remain optimistic! :-)

also, i'd like to sneak in my own RFE: to have a material switch!

First, problem #1. The Parameter Name is coped from the Input Name. The Parameter Label is copied from the Input Label. So in your custom VOPs have you set the Input Labels to the verbose labels you want? You set these by editing the Label column on the Input/Output page of the VOP Type Properties dialog. I just tested this using the Veins VOP, and it seems to work properly. If it doesn't work this way for you, could you send a sample VOP that demonstrates the bad Parameter VOP Labelling?

For problem #2 there is no magic bullet. I can explain (though not satisfactorily justify) the two separate UIs for arranging parameters: when a VOP Network defines your SHOP, it is the Parameter VOPs that determine the parameter set for the SHOP. The distributed nature of this information means there is no single editor (equivalent the the Edit Parameter Interface dialog) where you can control the parameters of your SHOP. The parameter ordering (and grouping into folders) is handled by having that second UI (which is just a front end for a parameter on the Output VOP). I will point out that you can multi-select and drag and drop parameters in that list, so it's not completely non-functional. I can't claim it's any match for the Edit Parameter Interface dialog (no labels and separators, can't directly edit the parms themselves, etc), but in the end getting used to this approach may be your best option. And in case it wasn't obvious, there is already an RFE to provide an “Edit Parameter Interface”-style UI for managing VOP Network parameters.

Your second approach, of using a VOPNET, instancing the SHOP defined by that VOPNET, then doing Edit Parameter Interface on the resulting SHOP is certainly a clever idea. The best explanation I can give for why the Material SHOP ignores that parm layout when you Promote the Material Parameters is that the layout information for that SHOP is stored as part of the spare parameter definition. Promote Material Parameters ignores spare parameters and promotes only the optype parameters, I believe, to avoid promoting the OGL parameters (which are spare parameters). Though I would say this is neither expected, nor the best way to accomplish this. So I've submitted an RFE to have Promote Material Parameters use the spare parameter information. But this isn't going to make it into a 9.1 daily build - it's too big a change. Which is why I said earlier that your best bet may be the VOP-specific parameter grouper.

Also, I'm not sure how “set” your materials are going to be, but you could do a reasonable job of grouping parameters into folders using the VOP parm grouped. Then you Promote the parameters to the Material. Once on the Material you can use the Edit Parameter Interface there to put the final touches (separators, etc) to the UI for the whole material. This means re-doing this organization for each Material which could be a huge pain if you have a large number of materials. But if you are creating one “super material”, it's not so bad. And if you create one-off custom materials based on the super material, you don't have to bother with polishing the interface because you've at least got something reasonable coming up from the VOP level. Not a perfect solution, but possibly serviceable depending on the exact shading workflow you want.

I won't bother commenting on your list of valid complaints about building complex VOP assets and VOP Networks, as I don't have anything useful to add. Peter and Jason will no doubt be by any minute to add their “me too”s along with Paul. I can only say we do the best we can here at SESI, and hope you all believe me

Mark

Hi Mark
Thanks for the in-depth explanation, it's helped me get a much clearer picture of how it works, and how I'm going to aproach it.

Re Problem #1
I didnt realise that the Parameter VOP was taking the name and label from the input, rather than the name of the parameter that the input references. But given that the idea of Parameter VOP usage is generaly to replicate the UI of the VOP node to a higher level shop or material, shouldnt it be using the Parameters Name and Label instead?
The trouble is that the VOP inputs truncate labels longer than 6 characters I think, of course if if you have long labels that limitation makes them pretty much unreadable, even if you zoom right in… I actually started that way with the first few modules, but it was taking a lot of time and a user fiddling with a vopnet is also likely to understand what all the abreviations mean.
Most of my Labels far exceed that limitation. For example, in my reflection VOP I have a toggle button with “Occluded Reflections (Faster… all but Envmap are black)” as the label.
I need to have descriptive Labels to make my life easier when I'm converting studio newbies to Houdini!

Also while on the topic of Inputs, I dont really understand why this interface needs to exist. IMO it should be transparent, meaning as you add more parameters the inputs just appear (unless it is set to invisible). After all, why would you want a parameter that you cant connect a Parameter VOP or whatever else to? btw, it would be really cool if the VOP input list supported separators. In my layered textures vop its hard to see where one layer's inputs begin and the next starts.

Anyway, I'm much happier now because I only have to rename the input labels rather than a ton of parameters.
But I guess I'll have to give it another pass next week when you fix all this, hehe

Re Problem #2
Yeah I guess I'll have to deal with the little list UI and forget about seperators. I found that if I only add a set of Parameter VOPs at a time it becomes much easier to deal with because they appear at the bottom of the list where I can quickly group them and move them.
Its either that or work with “deprecated” shops


Anyway, I know you guys work really hard on this colossal software and we all apreaciate that effort

cheers
Sergio

Indeed there is often a one-to-one correspondence between VOP inputs and Parameters on that VOP. But there is no requirement for that correspondence. This may be one of those cases where our attempts to cover 100% of possible use cases makes it more difficult to deal with the most common 95% of cases. For example you could certainly write a VOP with two “modes” of operation - say a math utility VOP that accepts an input angle in either degrees or radians. You don't want to do a runtime check of this choice, so you use #ifdefs in your VOP code. You might not want to create an input for this option because that would imply that you could use a Parameter VOP and expect this choice between rad and degrees to be made based on a point attribute value, which wouldn't work because it isn't a run-time check. A stupid example I'm sure, but I think the principle extends to more realistic cases. Similarly you can have an input that has no matching parameter (if it is a required input, for example, there is no need for a matching parameter).

Since Parameter VOPs must be connected to inputs, we gather the name and label for each Parameter from the input it gets connected to. If there is a matching parameter on the VOP, we do extract extra information from there (such as the range for float values, menu item choices, and so on). But the primary interface between the two VOPs is the input connection, so that is used as our primary source of information when creating the Parameter VOP.

There is no limit on the length of an Input Label or an Input Name, AFAIK. Of course the Input Name (shown on the VOP node tile) should be short enough that the user can read it. But the Input Label appears only on the tooltip when the user mouses over the input. So it can (and should) be as long and descriptive as you want.

Mark

Well, it looks like the Material concept (for shading) is out the window for me, unless you can convince me otherwise… In favor of a tried and tested, efficient, and reliable old friend… Vopnets and SHOPs.

I asked one of our guys to test the shader on a character with a bunch of polygon assigned materials. It's representative of most assets we will have to shade.
I suspected this would happen but it became apparent very quickly that Material HDAs containing a VOP VEX Surface SHOP (especially this very large one), are far less efficient than the method we've been using since we first switched to Houdini a few projects ago.

The problem with Materials with a VOP VEX Surface SHOP is that the Vopnet does not get instanced across copies, so what happens is that Hip files get huge, IFD gen get to 3 mins a frame for one character, takes almost a minute to copy and paste a material, and it takes a long time for renders to start because VCC appears to be compiling each and every identical copy of the VOP builder. I experimented with making trimmed down Super Materials (with just diffuse and spec for example ) which helped but still very inefficient.

I don't think Materials were a very good idea anyway, because we need to apply displacement shaders from outside the material HDA… i.e. we may want to use a Surface Super shader along with a custom displacement shader or vice versa.

As you can imagine things are getting really complicated just by using Material HDAs with vops in them…

The way we have done and very probably will continue to use is:
One or more object level HDAs (per category of asset, i.e. one for vehicles another for characters etc).
These HDAs contain a Shopnet which in turn contain lots SHOPs (like head, boots, eyes, body etc, times number of characters). This Shopnet also has inside it a VOP network HDA where one or very few VEX builders define all the SHOPs above.
This has worked perfectly for us so far.
What we will be doing from now on is pretty much what I described above except that there will be just one VEX builder in the whole scene (except for things that the super shader can't cater for). There will be no need for cut down versions because additional versions only hurts efficiency, rather than improve it as in the Material method.

What scares me is that Sesi seem to be deprecating this way of shading

From Dictionary.com
deprecated: Said of a program or feature that is considered obsolescent and in the process of being phased out, usually in favour of a specified replacement. Deprecated features can, unfortunately, linger on for many years. This term appears with distressing frequency in standards documents when the committees writing the documents realise that large amounts of extant (and presumably happily working) code depend on the feature(s) that have passed out of favour.

So the point is… Please can you not Deprecate it, “make it linger for many years”, and remove the warning bars/message from the SHOP SOP… pretty please with a cherry on top

cheers
Sergio

Edit:seems to me that Materials are really only intended for object level assignments since there parameters can be promoted without duplicating the material itself. If this is correct I understand a bit why it is the way it is, but then you might as well remove the Material SOP… something not right here.

Serg
Edit:seems to me that Materials are really only intended for object level assignments since there parameters can be promoted without duplicating the material itself. If this is correct I understand a bit why it is the way it is, but then you might as well remove the Material SOP… something not right here.

You know that the material sop also can do overrides, right?

I'm not the expert on Materials or shading workflow by any means. And I'm a firm believer in “do what works for you”, so I'm not really trying to convince you to change your mind here. But I will defend Materials a little bit.

The first thing I think I should do is clarify that Material can contain any kind of SHOP. You don't have to put SHOPs containing VOPs inside a Material. So the decision to use Materials or not has nothing at all to do with the decision to use VOPs inside your SHOPs vs. VOP Networks elsewhere in the hip file, or SHOPs defined in OTLs using raw .vfl/.vex code. Those are completely independent decisions.

The VOPs within SHOPs thing is not, I think, meant as a replacement for anything. It is provided simply as a different way to do the whole VOP thing without the indirection (which often confuses people) involved with VOP Networks that define a new SHOP Type. In cases where the VOP Network is relatively simple it provides a much easier to understand, and much more easily tweakable, customizable solution. But certainly when you've got huge VOP Networks you would want to avoid the overhead of having 15 copies of that Network. We are definitely not deprecating the workflow of having the VOP Network separated from the SHOP that you describe. But again, this portion of your setup is completely independent from the Materials decision.

From your description of your setup (which I think is very common) I don't know why you couldn't continue to do exactly what you are doing now in terms of VOP Networks/SHOPs, but just start putting your SHOPs inside Materials and using the Material SOP instead of the Shader SOP. But there could easily be issues here that I don't understand.

I honestly don't know enough about Materials and the Material workflow to comment on the shader assignment problem. I know Materials are definitely not meant to be an object-level-only approach to shader assignment (otherwise the Shader SOP wouldn't have that warning). But I don't know enough to elaborate on this aspect of it. Hopefully someone else can jump in here and fill in that part of the picture.

Mark

Sorry if my posts above sounded over dramatic, that wasn't my intention

Thanks to you I just realized that all my confusion stemmed from the idea of having VOPs inside the material, so there is really nothing at all to stop us from working the way we usually do but using the Material SOP instead of Shader SOP.
Its not complex at all, I just got totally confused by considering factors that weren't even factor anymore. DUH!! ops:

The only remaining issue there is that Promoting materials parameters can't replicate shop UI's that have be cleaned up/edited with separators etc.

BTW, it would be super cool if there was an option at object level similar to “Create Local Material Parameters”, the difference being that it would look inside for Material SOPs, and put the shader parms into folders named the same as the poly groups the materials are assigned to?

It's a shame that that functionality at the moment is limited to objects. The overrides in the Material SOP don't really count because a user shouldn't be expected to go inside an use that type of UI to tweak shader values. I know that overrides are intended for automating things like texture assignment etc.

Thanks
Sergio

Serg
BTW, it would be super cool if there was an option at object level similar to “Create Local Material Parameters”, the difference being that it would look inside for Material SOPs, and put the shader parms into folders named the same as the poly groups the materials are assigned to?

It's a shame that that functionality at the moment is limited to objects. The overrides in the Material SOP don't really count because a user shouldn't be expected to go inside an use that type of UI to tweak shader values. I know that overrides are intended for automating things like texture assignment etc.

Isn't it possible with a little scripting now? This has nothing to do with that if this feature should or shouldn't be possible by default, but definitely worth to try

Very interesting topic btw.!

cheers,
sy.

BTW, it would be super cool if there was an option at object level similar to “Create Local Material Parameters”, the difference being that it would look inside for Material SOPs, and put the shader parms into folders named the same as the poly groups the materials are assigned to?

Once you've assigned a material to an object, go to the Material parameter page on the object, and have a look at the menu under the “down arrow” button to the far right of the parm dialog. I believe this mechanism requires that you have already promoted the parameters from the individual shaders to the Material SHOP. There are also lots of other neat tricks under that menu (such as removing unchanged local material parameters to clean up any object level overrides that match the Material SHOP values).

Mark

But that is only usefull for assigning and editing materials at Object level, afaik.
My sugestion is for something that looks inside for Material SOPs, and Promotes the parameters of all shaders to object level.
So as a user you dont have to hunt around for shops, just select the OBJ and alll the SOP assigned materials are right there.

At the moment if you keep selecting “Create All Local Material Parameters” whilst entering different materials in the path you can populate that OBJ with loads of materials parms, but there is no link to the materials assigned in SOPs.

hope I'm not being stupid… again…

cheers
Sergio

To defend the Material SOP and it's different interface from Object assigned materials.

First in H8 there was no way to manipulate shader interfaces using the Shader SOP. You had to use an Attribute SOP and modify a long shader string manually. Certainly not very accessible or quick. As well many users weren't aware that you could remove parameter entries from that mega long string attribute so you had material assignments with lots of parameters. This meant that you were creating new shaders for each shader assignment even though they were defined by the same shader asset.

In H9 we have the Material SOP and a UI method to add parameters from materials one by one. This means that you have a greater level of control in both cases over H8.
When working with materials in H9 you tend to have a single material installed in the session then you override those values with the material assignments that you want to change, or you have multiple materials.

If you use multiple materials from the same gallery entry, then yes the new loose VOP SHOPs will cause the issues you raise. At that point, turn your VOP network in to a SHOP HDA material and use that instead.

The loose VOP networks inside materials work well if you use the single installed shader and then override the parameters at the object or geometry level. Obviously any changes you make will apply.

Shader/material assignments at the geometry level are not as efficient as those same assignments at the object level. Long cook times. Impact with SOHO. Just inspect the rib/ifd to see the difference. If it makes sense to assign materials at the object level, then do that. If you are building a complicated prop (like a plane, truck, etc) in a single object, then you will limit yourself:
- potentially large ifd/rib sizes
- difficult to control level of detail in a discrete way.
- all-or-nothing geometry load if you use disk geometry archives

It's the last one that really limits you on large scene files. Say you have a truck that some very excited modeller went ahead and built the entire interior cabin, engine, drive train. You know the stuff that will never be seen and in typical fashion, doesn't get cleaned up. If each component was an object and you were using disk archives, they will never be loaded at render time. Better to split up in to separate objects inside a subnet object in some cases.

I can see how archiving individual objects will help in the rendering but wouldn't the hip file memory usage become an issue? If all the objects are sepereate OBJ nodes then you potentially might have thousands of them.

jeff
Shader/material assignments at the geometry level are not as efficient as those same assignments at the object level. Long cook times. Impact with SOHO. Just inspect the rib/ifd to see the difference. If it makes sense to assign materials at the object level, then do that. If you are building a complicated prop (like a plane, truck, etc) in a single object, then you will limit yourself:
- potentially large ifd/rib sizes
- difficult to control level of detail in a discrete way.
- all-or-nothing geometry load if you use disk geometry archives

It's the last one that really limits you on large scene files. Say you have a truck that some very excited modeller went ahead and built the entire interior cabin, engine, drive train. You know the stuff that will never be seen and in typical fashion, doesn't get cleaned up. If each component was an object and you were using disk archives, they will never be loaded at render time. Better to split up in to separate objects inside a subnet object in some cases.

I can see how archiving individual objects will help in the rendering but wouldn't the hip file memory usage become an issue? If all the objects are sepereate OBJ nodes then you potentially might have thousands of them.

Not necessarily. you only need to create one archive for each type of material – group and merge all of bits and pieces of ‘one type’ into one archive. one for metals, one for glass, one for rubber tires, etc…

G

A node is a node in Houdini. Whether you have 1000's of objects with a few SOPs or one object with 1000's of SOPs, the overhead is pretty much the same both memory wise, load time and cooking time. At some point the geometry has to be built to display and render. It doesn't matter if that geometry is in one monster object or spread out over thousands of objects. The end result is pretty much the same.

Houdini9 has improved support for objects and object subnets: both traversing them in the viewport by double clicking on what you see, the outliner, shelf tools to collapse and extract, materials and parm overrides, etc.

keyframe

I can see how archiving individual objects will help in the rendering but wouldn't the hip file memory usage become an issue? If all the objects are sepereate OBJ nodes then you potentially might have thousands of them.

Not necessarily. you only need to create one archive for each type of material – group and merge all of bits and pieces of ‘one type’ into one archive. one for metals, one for glass, one for rubber tires, etc…

G

this sorta negates the purpose of making separate objects archives in some instances. ie, you wouldn't want to group all the windows of a city in the object - as every window in the city will be loaded even if your rendering just a CU of one building. you really want to archive/separate objects in a spacial sense - rather than a material one. at least in order to benefit from delayedReadArchive (or render from disk).

btw jeff/mark/andrew, we really need the auto archive back (with bells and whistles) asap! ;-)

this sorta negates the purpose of making separate objects archives in some instances. ie, you wouldn't want to group all the windows of a city in the object - as every window in the city will be loaded even if your rendering just a CU of one building. you really want to archive/separate objects in a spacial sense - rather than a material one. at least in order to benefit from delayedReadArchive (or render from disk).

Agreed. In a City context it's probably a bad idea. In the case of a ‘complicated prop’ (as was being discussed earlier), it will probably help.

It's hardly ever (if at all) cut and dry when it comes to large datasets. On the one hand you could be looking at enormous ifdgen times, on the other, you could be looking at huge amounts of network/disk traffic that you might not be equipped for. Pick your poison.

G

We consider the benefits of splitting into objects vs the extra human and network resources to manage lots of seperate bits of data.

Most of the hero assets we normally deal with are in the range of 40K to 100K polys, with anything from one, to about a dozen or more materials. Since they are lightweight we dont routinely split it into a large number of objects/Dra's.

Because we would have:

- A large number of bgeo sequence files, long take lists, lighting rigs with a ton more exlusions/inclusions than is necessary etc…

- Differing asset structure across software's. The Object level structure is largely determined by what we get from the animation transfer from maya, we like to keep things consistent between both softwares.

-its harder for the network to deal with lots of small files than fewer larger ones.

Basically, we will happily split the asset for any reason such as, because its a large asset or we need individual dicing control or whatever. But we dont split just because of shader assignment.

But anyway, my point was that SOP assignments should have the same bells and whistles as OBJ to generate linked UI's at object level, so that we can quickly tweak shader parms without having to go hunting around for Shops living somewhere else.
Or me having to link over 900 parms per super shader into an hda… this extra work is really the only reason to have seperate routinely unlocked Shopnet HDAs associated with an asset by naming convention only.

I agree that the material SOP ui is a much easier way to override parms per poly than H8, but clearly thats not intended for the same purpose as “Create Local Material Parameters”, I'm merely arguing for some similar functionality for SOP assigned shaders.

On a different matter with the material SOP, our artists have come up against an issue with it, which is throwing me back towards the deprecated shader SOP and that is that it's not possible to assign Surface and Displacement shaders separately. For example, we have a soldier character with a vest full of pockets etc, it's all made of the same cloth stuff, so we only require one or two surface shaders for the whole vest, but we need a bunch more seperate displacement shaders assigned more granularly to polys for individual control.

No problem for the shader SOP, but with the material SOP the displacement shaders get overwritten by the surface shader, or vice versa depending on the list order. We dont want to duplicate surface or displacement shaders just to make it fit with the material SOP. We arent needing any extras that the material SOP provides over the shader SOP, so we will be sticking with it the shader SOP for the time being.
So, in this case the material SOP is giving with one hand and taking away with the other.

And finally the artists tell me they dont like the tabbed multiparm style UI of the material SOP… its faster/easier to look for assigments in a top down list as in the shader SOP, since they are all displayed at the same time (its easier to check for mistakes like groups being assigned to two shaders). I realise its a multiparm ui because of the extra atribute override bits, but that funtionality will be rarely needed.

BTW, shader assignment, basic shading, texture assignment etc is one of those jobs we want to give to Juniors with little or no Houdini experience.

Anyway I'm glad this is being discussed!

Serg
On a different matter with the material SOP, our artists have come up against an issue with it, which is throwing me back towards the deprecated shader SOP and that is that it's not possible to assign Surface and Displacement shaders separately. For example, we have a soldier character with a vest full of pockets etc, it's all made of the same cloth stuff, so we only require one or two surface shaders for the whole vest, but we need a bunch more seperate displacement shaders assigned more granularly to polys for individual control.

At first I thought, “No problem, just use a Switch SHOP and make an override to pick which Displacement/Surface SHOP you want.” But sadly this doesn't work either.