VRayBlendMtl: Additive Checkbox per Material

[beat_reichenbach]

Hello VRayTeam,

We've been playing around with the new VRayBlendMtl behavior with displacement maps per material and noticed something. In the following scenario it would be nice to have additive checkboxes for each layer.

Base: Cobblestone road as the base material. Displacement is a map with the cobblestones. Mid Value 0.
1. Coat: Water. Displacement is a constant at -0.2, wherever the water is revealed, the surface is at a constant value of 0.2.
2. Coat: Dust. Displacement is a fine powder that should sit on top of the existing displacement. Mid Value 0.

In this case we would want the water to be not additive but the dust layer to be additive.

This scenario comes up in a lot of cases, for example skin, sweat, dirt: The dirt should be additive while the sweat should replace the displacement map.

[^Lele^]

Blend in a blend?

[beat_reichenbach]

Yes exactly, a nested blend would definitely be a workaround.

Another solution is to assemble all your displacement maps on the base material with a composite map and then set the blend material to additive. This is how it was done before 5.2. The change from 5 to 5.2 actually means that all existing blend materials look different, since the additive checkbox is not set by default. So the default for all existing blend materials is now that the displacement is taken into account which changes the look of all blend materials that are used in displacement mods. Just an FYI with quite the implication for continuity when upgrading versions.

Another thought would be to get away from blend materials and maybe make a new node, similar to the vraycomptex that only takes two inputs, but that has more parameters. That way it's easy to set additive spec or additive displacement per node. It could even support multiple blend modes and complicated setups just turn into nested setups.

[^Lele^]

The change from 5 to 5.2 actually means that all existing blend materials look different, since the additive checkbox is not set by default.

Ah! Great spotting!
Thanks for this!

Yes, the workflow is somewhat novel, and opens the flank to a few workflow conundrums.
Personally, i'm of two minds about this approach: most other engines use a single port for displacement in a collector shader (i.e.: one with surface, volume, and displacement ports), so all the blending is done before, and separately from the rest of the shading setup, in its dedicated network (after all, maps can be instanced around).
We can ofc do this as well in a number of ways (not least plugging the displacement maps' network in a displacement mod), but the blend with the dedicated displacement options suggests other approaches as well, which may be confusing, if elegant in some situation.

We can surely do with feedback on it all, would you mind expanding on your last point?

[beat_reichenbach]

You are right, doing it like other renders with a displacement input on the shading_engine (maya) would be another alternative.

We can surely do with feedback on it all, would you mind expanding on your last point?

I don't necessarily think this is the best way, I just wanted to bring it up since I thought about it. It would basically be like the VRayCompTex with an Operator attribute but also have operator attributes for spec and displacement. So for example, the spec operator being set to Add would basically be the same as the shellac feature. And if you'd want multiple layers you'd just add multiple blend nodes. Again, I doubt this would be the most elegant or user friendly option, but it is one.

[^Lele^]

The issue with this approach would be energy preservation: there isn't an easy way -that i know or was made aware of- to achieve that with disconnected components, much like it's a risky proposition to use the blend in additive mode (which would also be the current way to build one such setup as you showed).
So it'd definitely be elegant, and an approach i'd very much cherish*, but the result could compromise render speed greatly (by way of creating uncleanable noise and fireflies).

This is why we endeavoured to add to the base VrayMtl the two new spec layers (sheen and clearcoat), and to integrate the volumetric SSS in it.
That way, EP is conserved in a predictable way, and we get the speed, the physical plausibility, and -at least some of- the flexibility, if none of the above elegance (i should admit i was never a fan of ubershaders, much as i could see their undeniable positives.).

I'll be poking the devs anew, perhaps there is now some technique that would enable an unconstrained node-based approach, mitigating the potential issues.

*)I built one such scripted ubershader, based on an additive blend (and the Disney paper from 2012), which could be one-click decomposed into its constituents, in 2014/15, see attached.
To try and be EP, i had to introduce some serious hack to the additive maths, in the form of a weighted sum, but that would only work some of the time (not being per-pixel.).
It turns out it's possibly even harder (and/or impossible) to ensure unconstrained shaders are EP per pixel...

[beat_reichenbach]

This is why we endeavoured to add to the base VrayMtl the two new spec layers (sheen and clearcoat), and to integrate the volumetric SSS in it.
That way, EP is conserved in a predictable way, and we get the speed, the physical plausibility, and -at least some of- the flexibility, if none of the above elegance (i should admit i was never a fan of ubershaders, much as i could see their undeniable positives.).

Totally agree with you, I love the coat and sheen on the material. Thanks for sharing that!
Best solution for the user literally might just be using and chaining the blend materials together the way they are, and use the additive displacement checkbox per node. Do you happen to have done any tests to see if chaining multiple blend nodes together is slower than one blend node with multiple layers?