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?
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.
Colour Data shader maybe?
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.
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.
Quote from: digitalguru on January 01, 2022, 07:24:17 PMBut 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.
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).
Quote from: Dune on January 02, 2022, 03:12:34 AMFor 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.
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.
Quote from: Hannes on January 02, 2022, 03:27:15 AMHappy 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.
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.
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.
Quote from: WAS on January 02, 2022, 03:21:00 AMBreakup 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) ???
Quote from: Dune on January 01, 2022, 10:37:43 AMMy 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.
I think the discussion about masking doesn't really belong in this thread.
Quote from: WAS on January 01, 2022, 08:53:09 PMAnother 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.
"Radiant Shader" seems like a reasonable option, one for the shortlist. But "albedo" is reflectivity, which is not what I'm asking about.
Different "configs" you can call from context or palette seems like the easiest way to implement this, and also simple to draw upon. It does make the documentation more confusing, however.
Also I don't think albedo is reflection at all, that's exclusive in refraction, albedo is the "radiation" of the sun, or light off surfaces. It allows us to see them. Other DCC use albedo exclusively for colouring, where reflections are reflections. In TG surfaces have radiation regardless of a reflection shader when there is light.
Think of a matt surface, it has radiation, buy its not reflecting/deflecting rays like in refraction.
Quote from: aknight0 on January 01, 2022, 11:41:39 AMColour Data shader maybe?
Maybe. But for me this name implies it should only be used for data output, not for texturing the background or something like that. I suppose if it were combined with
@cyphyr idea of a tie-in with Render Elements then it would be a good name. That feels like a bigger feature request though, and adds yet another shader that's overpowered for some of these use cases.
Quote from: Matt on January 03, 2022, 01:17:09 PMQuote from: aknight0 on January 01, 2022, 11:41:39 AMColour Data shader maybe?
Maybe. But for me this name implies it should only be used for data output, not for texturing the background or something like that. I suppose if it were combined with @cyphyr idea of a tie-in with Render Elements then it would be a good name. That feels like a bigger feature request though, and adds yet another shader that's overpowered for some of these use cases.
Colour in general is weird when it comes to light. Light is not coloured, it's a spectrum of light frequencies, which are interpreted different by different sources (camera sensors, human eyes vs a birds eye, etc). They can all perceive these as different "colours" because they aren't actually colours.
Quote from: WAS on January 03, 2022, 01:07:37 PMAlso I don't think albedo is reflection at all, that's exclusive in refraction, albedo is the "radiation" of the sun, or light off surfaces. It allows us to see them. Other DCC use albedo exclusively for colouring, where reflections are reflections. In TG surfaces have radiation regardless of a reflection shader when there is light.
Think of a matt surface, it has radiation, buy its not reflecting/deflecting rays like in refraction.
Reflection doesn't just mean specular reflection, it can also mean diffuse reflection. 'Albedo' is the proportion of diffuse reflection, but in some disciplines such as computer graphics the term is applied to non-diffuse reflection as well.
Albedo:
https://en.wikipedia.org/wiki/Albedo
Specular albedo:
https://www.cs.cmu.edu/afs/cs/academic/class/15462-f09/www/lec/lec8.pdf (PAGE 11)
https://docs.unity3d.com/Manual/StandardShaderMetallicVsSpecular.html
Albedo affects how the object appears to us, but only when it's hit by light from elsewhere. If you put an object in the dark, its albedo makes no difference, it will look black no matter what the albedo is. So albedo is not what I'm not asking about; I'm asking about emission.
I thought you were talking about both a constant coloured surface, and optionally emission if enabled. Emission seems irrelevant here, in regards to albedo as that's a source dispersing rays itself (and in most computers graphics don't even relate unless you're using albedo as a base colour for emission [from a solid surface]).
Quote from: WAS on January 03, 2022, 02:04:13 PMI thought you were talking about both a constant coloured surface, and optionally emission if enabled. Emission seems irrelevant here, in regards to albedo as that's a source dispersing rays itself (and in most computers graphics don't even relate unless you're using albedo as a base colour for emission [from a solid surface]).
Usually a "constant shader" means a shader that is purely emissive, and that's what I'm talking about.
When I think "emission" I think you're just saying a luminous surface, if so, why not just Luminous Shader to go in line with the naming used in other shaders already (luminosity)?
What I thought you meant was something like a surface layer, but only handles a coloured surface, or emission (luminosity).
But it sounds like you mean just a emission shader which doesn't interact with TG's lighting models (receive lighting/shadows), but adds to it?
Quote from: WAS on January 03, 2022, 02:34:16 PMWhen I think "emission" I think you're just saying a luminous surface, if so, why not just Luminous Shader to go in line with the naming used in other shaders already (luminosity)?
What I thought you meant was something like a surface layer, but only handles a coloured surface, or emission (luminosity).
But it sounds like you mean just a emission shader which doesn't interact with TG's lighting models (receive lighting/shadows), but adds to it?
Yes, that's exactly what I mean. "Luminous Shader" is one that I had in mind but wanted to hear it from one of you.
Would your intended "Luminous Shader" effect its environment?
Could it be used for illuminated windows, street lights etc?
Quote from: cyphyr on January 03, 2022, 02:51:47 PMWould your intended "Luminous Shader" effect its environment?
Could it be used for illuminated windows, street lights etc?
Yes. It would behave exactly the same as a Default Shader with only luminosity, or a Constant Shader with a function input.
EDIT: Unlike the Constant Shader, though, maybe it should have a mask input and be able to pass through (blend) its main input when the mask says it should. Some shaders still don't have this, but maybe they should.
This sounds like a good idea.
I also +vote just Luminous Shader to be different from "Emission" in like every other DCC (and also in line with naming already used). If not Luminous I still like Radiant Shader.
The main reason I would use such a shader would be to render an image for vector/scalar displacement - in which case "Luminous" would be slightly misleading if I was coming to Terragen fresh (even more so for "Radiant"). Perhaps the best option would just be to add an input to the Constant shader? And an emission only switch in the default shader for other purposes?
First I want to second Dune and Hannes' comments that (for me too, at least) such a shader isn't needed. I always tab through the Default shader before using and zero out the settings I don't need. But it sounds like the proposed shader wouldn't replace this, and that I could keep working as before.
I do think a dropdown "preset" menu in the Default shader would just introduce another level of complexity. A separate shader would be better.
My vote would be for Luminous shader.
Quote from: digitalguru on January 04, 2022, 04:48:59 AMThe main reason I would use such a shader would be to render an image for vector/scalar displacement - in which case "Luminous" would be slightly misleading if I was coming to Terragen fresh (even more so for "Radiant"). Perhaps the best option would just be to add an input to the Constant shader? And an emission only switch in the default shader for other purposes?
Thats not even its intended use, though, so thats more just a weird thing you'd be doing with it. Its the same as surface layer, and default, and most people use it for lighting.
As for people just used to going through a shader and zeroing things out... That doesn't seem like a valid excuse but admittance of its annoyance and you just not caring. Seems incredibly bias.
It's just one parameter that needs a zero, and I think it's pretty normal that one checks every shader and sets parameters like they're needed. You can't just add a shader and expect it to work as you need without adjustments. I also change the breakup shader, e.g. as I don't like the very warped lines created when greys are broken up. I could call that annoying, but I don't see it that way.
Quote from: Dune on January 05, 2022, 02:55:36 AMIt's just one parameter that needs a zero, and I think it's pretty normal that one checks every shader and sets parameters like they're needed. You can't just add a shader and expect it to work as you need without adjustments. I also change the breakup shader, e.g. as I don't like the very warped lines created when greys are broken up. I could call that annoying, but I don't see it that way.
Isn't that ironic though because that's literally the point of the aforementioned suggested shader? And aforementioned options for the default shader? So it is more straightforward and to the point. Need a lit surface? Drop in a Luminous Shader and do simply that. Not extrenous options TG needs to check to see if it's doing this or that at runtime before rendering that were never part of your intended goal. In coding this would be bad logic as it just adds to the runtime execution. However miniscule it seems for one function, can add up for several, or dozens.
Again this seems more personal, and more just not wanting to be bothered with change. Not that it's actually valid beneficial points. Should be more open and not set in ways.
If you want to test this yourself. Use a default shader with no fresnel naturally, and a surface layer, use a 0.5 colour. Now benchmark both these shaders for just colour against a constant shader. The constant shader is faster in all tests, because naturally it is
not going through a series of checks to see what it's doing beyond the intended goal. I have no terrain in my scene, and default camera and resolution of 800x450.
Surface Layer: 11s
Default Shader: 12s
Constant Shader: 9s
I also vote for "Luminous Shader". It sounds similar to what I think of as a "Self Illumination" shader from my years in 3DS Max, and other software.
Derek
Quote from: WAS on January 04, 2022, 12:23:20 PMThats not even its intended use, though, so thats more just a weird thing you'd be doing with it. Its the same as surface layer, and default, and most people use it for lighting.
Strange to see you describe it as a "weird thing" when you expressed your desire for more apps to support vector displacement:
https://planetside.co.uk/forums/index.php/topic,29760.msg291398.html#msg291398
Until there's a standard way to achieve this in Terragen (and we're not likely to see this until Terragen 5 at least) having an simple input to a constant shader seems a logical way to go (with no disruption at all to any other workflow), and for my money not uncaring at all or bias.
Quote from: digitalguru on January 09, 2022, 06:41:30 AMQuote from: WAS on January 04, 2022, 12:23:20 PMThats not even its intended use, though, so thats more just a weird thing you'd be doing with it. Its the same as surface layer, and default, and most people use it for lighting.
Strange to see you describe it as a "weird thing" when you expressed your desire for more apps to support vector displacement:
https://planetside.co.uk/forums/index.php/topic,29760.msg291398.html#msg291398
Until there's a standard way to achieve this in Terragen (and we're not likely to see this until Terragen 5 at least) having an simple input to a constant shader seems a logical way to go (with no disruption at all to any other workflow), and for my money not uncaring at all or bias.
You worded it as something we are all doing and it's main use or something. Hadn't even heard of that use by anyone here -- and relating to the end-user discussion being had.
I get what you mean, it just was not relating to what I was discussing here.