Ubershaders are bad for you, mmkay?

[horizon1231]

Hi,

I tried the v.65 and I am still gettting a solid white render and an error saying cannot find a signiture with the correct arguments and return type for the "set" arguments. Also errors about export values. I am on 10.0.249.5

Just wondering if anyone else is experiencing the same issues?

thanks!

david

I got errors like itriix too, bad parameter reference.H 10.0.317

[Alexander Weide]

This Shader Works with the Daily Build 10.0.320 perfectly

[lisux]

Really nice eetu.

I also have done an uber surface and displacement shader, not so complete as your but quite similar.

One problem I found is that your is an "alive" network in the scene, is not a "compiled" shader, so everytime the sahder is used it is going to be compiled, and all the network is going to be in all the scenes using the shader, not just a reference to the compiled shader.

On the other hand you can always dive into the network and add new stuff as procedurals for exmple.

At the end my feeling is that is better to code the main guilding blocks and get a compiled version and an alive version, depending of the needs.

Anyway amazing stuff you shader.

[Netvudu]

I confirm it doesn

[Netvudu]

It does work properly on more recent daily builds. I hope it doesn

[eetu]

It does work properly on more recent daily builds. I hope it doesn

Edited July 15, 2009 by eetu

[eetu]

Ok, going forward.

A new "request-for-comments-preview" sorta version up. Color and Map tabs redone; rest is either old, missing or nonfunctional

My philosophy behind this next version:

Generators, Ramps and Combiners.

- Generators are independent color maps, procedurals, and other stuff like accessibility, incidence angle, slope etc.

- Generators are used either as raw Inputs or as inputs for Ramps.

- Raw inputs and ramps are then fed into Combiners that can be multiplicative, additive, screen, soft light etc - and perhaps alpha.

I've been making the innards more modular, and now my main question is how many inputs/ramps/combiners should I use for each channel (here meaning color/spec/etc)

At the moment the demo Color tab has one raw input, one ramp and one combiner.

To get a meaningful alpha going, three Inputs/Ramps would be best - but three sets for each channel makes quite a damn large shader.

Perhaps 3 for color and 2 for the rest? How many separate Map and Procedural Generators would be needed?

I'll try to get the basic structure correct before I start cloning stuff, changing things after that is more cumbersome.

Another new feature is the "Implicit Cubic" UV mode in Map tab. It's the Lightwave-style cubic/triplanar rendertime UV mapping, where each sample's normal

determines from which axis that sample is planar-mapped. It's a bit of a dirty method, but quite useful in the real world

eetu.

[Serg]

Ok, going forward.

A new "request-for-comments-preview" sorta version up. Color and Map tabs redone; rest is either old, missing or nonfunctional

My philosophy behind this next version:

Generators, Ramps and Combiners.

- Generators are independent color maps, procedurals, and other stuff like accessibility, incidence angle, slope etc.

- Generators are used either as raw Inputs or as inputs for Ramps.

- Raw inputs and ramps are then fed into Combiners that can be multiplicative, additive, screen, soft light etc - and perhaps alpha.

I've been making the innards more modular, and now my main question is how many inputs/ramps/combiners should I use for each channel (here meaning color/spec/etc)

At the moment the demo Color tab has one raw input, one ramp and one combiner.

To get a meaningful alpha going, three Inputs/Ramps would be best - but three sets for each channel makes quite a damn large shader.

Perhaps 3 for color and 2 for the rest? How many separate Map and Procedural Generators would be needed?

I'll try to get the basic structure correct before I start cloning stuff, changing things after that is more cumbersome.

Another new feature is the "Implicit Cubic" UV mode in Map tab. It's the Lightwave-style cubic/triplanar rendertime UV mapping, where each sample's normal

determines from which axis that sample is planar-mapped. It's a bit of a dirty method, but quite useful in the real world

eetu.

Yeah it's really important to plan really carefully before you start building the texturing part in particular. Add extra features now because you will regret it later... then build it really neat and tidy.

The texturing part of the Ubershader can't be a module, because there is no way afaik to create a Vop node that incorporates ramps which can be re-promoted to shop level (arghh....). For this reason I cant build a texturing node and simply duplicate it, so it's a PITA to go and update the textures with new capability after you've built the whole thing... because you have to manually replicate the upgrade on however many texturable channels you have.

Like yourself I came from LW so I know how useful cubic mapping can be. I lost count how many times I got away with throwing a cubic projection and your LW accessibility shader on something

Here's some screen shots of the structure.

The first shot is the top level, the second is the Output Module that takes care of sorting all the AOV's, creates Utility AOVs like Depth fresnel etc, and optionally routes any of them to the beauty for fast re-rendering of an individual pass.

The last shot is the Texture module. You can see how the Output of the Procedurals generator gets fed into the ramps.

cheers

S

[lisux]

Interesting stuff here.

I didn't know about the cubic projection before, sounds cool, is like an uwrapping at render time.

Hey serg this shader looks massive!

Cool stuff indeed

[mrice]

The texturing part of the Ubershader can't be a module, because there is no way afaik to create a Vop node that incorporates ramps which can be re-promoted to shop level (arghh....). For this reason I cant build a texturing node and simply duplicate it, so it's a PITA to go and update the textures with new capability after you've built the whole thing... because you have to manually replicate the upgrade on however many texturable channels you have

Is SESI aware of this bug? It looks like if a ramp gets promoted from within a subnet its unusable at the material level, and is a major limitation to building modular shaders.

[Serg]

Is SESI aware of this bug? It looks like if a ramp gets promoted from within a subnet its unusable at the material level, and is a major limitation to building modular shaders.

I think its more of a limitation... imo the problem is that the ramp node is both the tool and the parm, unlike anything else in Vop land... it should really be just a tool with an input for the ramp and an input for the parameter node, that way the ramp could live inside a subnet whilst being controlled by an external parm.

[theflu]

really cool eetu! makes shading&texturing in houdini much easier for me!

[mrice]

I think its more of a limitation... imo the problem is that the ramp node is both the tool and the parm, unlike anything else in Vop land... it should really be just a tool with an input for the ramp and an input for the parameter node, that way the ramp could live inside a subnet whilst being controlled by an external parm.

OK makes sense. In that case a hack could be to use an asset's event handlers to copy its ramps to vop level, with 'Use this node to set parameter attributes' checked. Here's an example.

ramp_subnet_test.hipnc

[eetu]

Holy shit Serg, that's crazy!

.. and I thought mine was getting complicated

I put a new one up with 2 map and 2 proc generators plus some raw inputs on other channels.

I'm still thinking about where to put the ramps and how many, I don't think I want to go all out after all, putting all controls everywhere.

(although maybe that's some definition of an ubershader).

edit: added 0.91 which has reflection, some more ramp inputs and minimal docs. Mappable reflection blurriness is nice

eetu.

Edited July 20, 2009 by eetu

[eetu]

Ok, version 098 up.

I HDAfied some of the building blocks inside and populated the specular and reflection tabs with ramps & combiners.

I also added mode blending modes from Nuke.

This should be in a somewhat usable state now, wishes and bugs welcome.

eetu.

[rd1010]

Thanks.. I am downloading it right now to check it out

[theflu]

hey eetu

would it be possible to implement the AXIS_SSS.otl into your shader?

would be a great enhancement i think

e:

another question, is it possible in houdini to have a preview of the procedurals?

Edited September 28, 2009 by theflu

[altbighead]

hi eetu.

Is there a reason there is no reflection pass AOV in your ubder shander.I am missing something obivious or is it on your todo list?

I am using PBR btw.

[Ponge]

Hi Eetu,

I've been using this amazing shader for my recent student project and I'm getting some really nice results out of it. However I've had some issues trying to render out extra image planes. Several of the export options don't seem to work for me, specifically fresnelExport, gritExport, procExport and specularExport. I've tried setting these up under Mantra and they just seem to output black in mplay. I was wondering if you had any suggestions or ideas, as having access to these passes would greatly help when I come to comp my project.

Many thanks,

Gary