Requesting ideas for luminosity, pure colour output

[Matt]

Happy New Year, everyone!

I've been thinking about something and would like to hear your ideas.

One of the things people use the Default Shader for is to create a fully self-luminous (emissive) surface. You can use this for physically glowing surfaces like lava. But it has non-physical uses too. For example you can use it to add stars to the background sphere, or output raw colour data generated by another shader for special uses like outputting a custom depth pass or matte pass for compositing. You might want to render a top-down image to be saved as a texture, without messing about with Render Elements, and want to be sure that the image contains the exact colours you created. Exporting vector displacement maps is an example of using this method.

In Terragen 4.4 and earlier, all you needed to do was increase the luminosity and set the diffuse colour to 0. And then connect your colour-generating shader to the "luminosity function" input.

In Terragen 4.5 the Default Shader underwent some changes. It is backward compatible so that Terragen 4.5 can render old materials and they will look the same as they did in previous versions, but if you create a new Default Shader in 4.5 you'll find that it looks a bit different. Some of the default settings were changed to make it easier to create PBR materials. Even if you turn the "base colour" down to 0, the material still reflects a small amount of light. This is the "Fresnel reflectivity". It's stronger at glancing angles, but depends on the settings "roughness" and "index of refraction." Even dull, non-glossy (high roughness) materials reflect some light this way.

The new defaults are good for rendering physical materials, and are good for the Default Shader's main purpose as the "go to" shader for adding materials to imported 3D models. Even glowing materials like lava have Fresnel reflectivity; this is realistic. But if you want to output a pure colour for a data pass or the starry sky example from earlier, the Fresnel reflectivity is another thing you have to remember to turn off.

Instead of using the Default Shader, you could use a Surface Layer. But in future the Surface Layer will probably get some Fresnel options and PBR-like default settings as well.

I think it would help if we had another shader that's dedicated to outputting pure colours: just luminosity (emission), without any reflectivity whatsoever. Most other renderers have a shader like this. But what should it be called in Terragen?

We have the Constant Shader but it currently doesn't have a colour function input. Should we just add that input? That would be a simple solution, but then "constant" is a bit of a misnomer. Should there be a new shader for this purpose? If so, what should we name it? Is there an important distinction we should make between physical and non-physical materials, or between colour and data?

What do you think?

[Dune]

My first answer would be that, as long as we can turn off any reflectivity, no new shader is needed. Of course I have to remind myself to do so if I add a new default shader and don't want any reflectivity, but the more shaders, the more complexity, I'd say.
But I might miss something others may use more frequently than I do.

[aknight0]

Colour Data shader maybe?

[WAS]

Albedo shader / emission shader / diffuse shader / Diffuse -- Emission Shader. Could also maybe just distinguish between "default" shader, and the new shader. Default shader doesn't actually make much sense in TG. Default as apposed to what? Lol Anyways, Blender has their new Principled BSDF as the default material shader now, I believe it's a abbreviation of what type of rendering it's literally meant for (which is Cycles I believe). Maybe could just call the Default Shader like PT Shader, or something similar, and than RT Shader (Standard Renderer). But I know we gotta maintain legacy usage. Just in general the "Default shader" thing is strange.

Great idea.

Another simple shader that I'd love to have is a simple Mask shader. Main Input, and a Mask, working in non-clamped data or clamped (similar to coverage in surface layer at 0-1.

Currently, you have to always set up a surface layer for this, such as inputting into colour first, and then child so it disabled colour (without going into it), but then I usually mostly am masking non-clamped data, so I have to go into the shader anyway just to disabled coverage. It's a lot of work just to mask something, and It's strange we don't have a dedicated method for like functions and stuff.

You could use Multiply or subtract, etc, but the results interestingly seem different in halftone areas, additionally, if you need clamped input you're adding a colour adjust or clamp 0 1 scalar/colour. That clamping when it comes to colour doesn't take into account 0-1 ranges but clamps the mixed colour at 1, so it doesn't produce the weird burning dark colours, but also doesn't look like it would with a surface layer masking. Also when you're masking whole setups, multiply/subtract/etc can really mess with all the unclamped  mixed data.

The distribution shader is an alternative, but you require a solid map to utilize the child input, otherwise it's colour or 1 will show through which you are not able to disable.

[digitalguru]

There's a shader in Maya that does this, but it's rather confusingly called "Surface Shader"
Arnold has a utility shader with a "flat" mode.

Renderman has a "Constant" shader.

When I was doing my vector displacement experiments I thought the Constant shader would do the trick and was a bit disappointed there was no input

Having a dedicated shader with an input is a great idea, and I'd be the first to try it out.

But for my money, a new shader under the Surface Shader category called "Flat" would get my vote.

[WAS]

But for my money, a new shader under the Surface Shader category called "Flat" would get my vote.

That may be confusing when it comes to displaced terrains.

Another name I want to spit out which is kinda unique is "Radiant Shader" which could be dealing with the radiance of albedo, or emission of something.

[Dune]

For my work at least a 'mask shader' isn't necessary. I would probably not use it, as it's easy enough to use a surface shader (with its extra possibilities to use breakup and all other parameters).
If you really need the 'new default shader', why not call it 'pure color shader' (you already mentioned it, Matt).

[WAS]

For my work at least a 'mask shader' isn't necessary. I would probably not use it, as it's easy enough to use a surface shader (with its extra possibilities to use breakup and all other parameters).
If you really need the 'new default shader', why not call it 'pure color shader' (you already mentioned it, Matt).

Breakup only works for clamped coverage input, and breaks scalar data. You also can't "breakup" child input, so you're just using the mask input redundantly on white colour to achieve breakup which also breaks simple PF input. You can use functions for the same effect while preserving data, in one node. These sort of easy to the point shaders are pretty important in getting to the point of a scene quickly. Having to set up a surface layer just to mask scalar data which is so common for me is annoying.

I can see how it's now so annoying for you because of the simple nature of your scenes with reds.

Also "pure colour" sounds silly, and also not accurate as emission isn't "colour". It's radiation. However, radiation can encompass colour surfaces as those rays we see is radiation.

PS if Terragen opened newly created shaders in a new window, I'd probably have less of an issue. It's frustrating you have to open up each shader, or go to the shader tab to access settings on something you will 99.99% of the time need to immediately set up. Other DCC open the settings window or open the settings tab when you generate shaders/stuff cause they know it's not an out-of-the-box thing to just add and move on.

[Hannes]

Happy new year, Matt!!!
Actually I have to say, that I never thought, that I need a special shader for luminosity. It didn't feel uncomfortable for me to check, if there's reflectivity, since I do that automatically. But that's only my opinion.

[WAS]

Happy new year, Matt!!!
Actually I have to say, that I never thought, that I need a special shader for luminosity. It didn't feel uncomfortable for me to check, if there's reflectivity, since I do that automatically. But that's only my opinion.

It is usually part of more elaborate shaders these days, like the aforementioned principled shader in Blender. It has emission, SSS, etc, all in one. No longer do you need to merge shaders and stuff with subsurface, emission, etc in their own shaders. While they still exist, and it's nice to have, you can just drop in the Principled BSDF. In a way the Default Shader was ahead of it's time with all the functionality it has.

However, I can see a reason to differentiate when it comes to legacy stuff, and backward compatibility moving forward. Also makes documentation less confusing when dealing with legacy issues and features older users may not have access to and not catch that one line about what version it's available in -- leading to forum posts.

[WAS]

That name though default shader has always got me though. Default to what? Default to any object created besides the planet/lake? I guess that makes sense, but at the same time there is no other shader that does the things it does without an elaborate node tree.

[cyphyr]

And a happy new year to you too.

Maybe just call it "Special shader"

Could the new shader also have an optional Render Layers output?

From the sound of what your describing it would have most use as a post process tool and anything that comes out in the beauty pass is already covered by other shaders.

Also I wonder weather it could also take input from cloud nodes somehow.

[Dune]

Breakup only works for clamped coverage input, and breaks scalar data. You also can't "breakup" child input, so you're just using the mask input redundantly on white colour to achieve breakup which also breaks simple PF input. You can use functions for the same effect while preserving data, in one node. These sort of easy to the point shaders are pretty important in getting to the point of a scene quickly. Having to set up a surface layer just to mask scalar data which is so common for me is annoying.

I can see how it's now so annoying for you because of the simple nature of your scenes with reds.

I won't be hijacking Matt's request, and leave it at this, but do like to say that I don't understand at all what you're talking about. Sure it works with unclamped input and can breakup child input. Or it may be a riddle I don't grasp. And I don't think you really know my scenes (the simple nature of them with reds)

[Matt]

My first answer would be that, as long as we can turn off any reflectivity, no new shader is needed. Of course I have to remind myself to do so if I add a new default shader and don't want any reflectivity, but the more shaders, the more complexity, I'd say.
But I might miss something others may use more frequently than I do.

Maybe we should focus on making it easier to intialize the Default Shader for different purposes as soon as it is created. "PBR" being one purpose, and "luminous only" (or some other description) being another. Perhaps we could add these to a sub-menu on the node creation context menu and/or extra items on the Node Palette. They would all create a Default Shader but with different initial settings.

[Matt]

I think the discussion about masking doesn't really belong in this thread.