Shader Mixer (DS3+4): How to make a very basic diffuse IBL? [ShaderBUILDER solution found?]

3dcheapskate

{Edit: Possible Shader BUILDER solution in post 18 }

I want to make a very basic IBL light similar to Poser's diffuse IBL. (See first image - Poser 6, plain white cube lit by a single Diffuse IBL).

It should be simple since I'm not concerned with shadows, AO or anything like that at present. But I've Googled the DAZ forums, searched through the Shader Mixer Recipes threads , checked the documentation, etc, and I can't even find the basics! (I'm sure the answer's in the recipe threads somewhere though...)

So without anything to guide me I've been playing around and getting nowhere. I'm obviously doing something very wrong, probably right at the start... (See second image - a 'Light' shader with a 'Base Light' root brick [seems logical] and an 'Environment Color Map' [need some way to apply the IBL light probe angular map to the light])

Obviously this doesn't work (See third image - nice flat khaki colour for the cube)

Question 1: Can somebody put me on the right path please? I obviously need to create a 'Light' shader, so...
1a) I obviously need a root lighting brick. The 'Area Light' can't be added to a 'Light' shader, so the 'Base Light' seems the next most logical. Or not?
1b) I obviously need a brick that I can plug my IBL light probe image into. An 'Environment Color Map' seemed logical (although it clearly doesn't take an IBL light probe)
1c) I almost certainly need to add some other stuff in between. But what?

Question 2: When you've finished your 'Light' shader and you click 'Create', why does it create a Null, not a Light? What do I have to do to make a 'Light' Shader into an actual light in the scene?

(P.S. I know I could just use the UberEnvironment2 - but that's not going to help me actually understand how to create my own light shaders)

millighost

3dcheapskate said:

I want to make a very basic IBL light similar to Poser's diffuse IBL. (See first image - Poser 6, plain white cube lit by a single Diffuse IBL).

It should be simple since I'm not concerned with shadows, AO or anything like that at present. But I've Googled the DAZ forums, searched through the Shader Mixer Recipes threads , checked the documentation, etc, and I can't even find the basics! (I'm sure the answer's in the recipe threads somewhere though...)

So without anything to guide me I've been playing around and getting nowhere. I'm obviously doing something very wrong, probably right at the start... (See second image - a 'Light' shader with a 'Base Light' root brick [seems logical] and an 'Environment Color Map' [need some way to apply the IBL light probe angular map to the light])

Obviously this doesn't work (See third image - nice flat khaki colour for the cube)

The IBL light in Poser has two kind of modes, which behave very differently; without IDL and with IDL. Without IDL it simply projects the environment map onto the surface. No shadows, occlusion or complicated stuff. This is not difficult to do with shader mixer, but some points differ between Poser and DAZStudio anyway, see below.

Question 1: Can somebody put me on the right path please? I obviously need to create a 'Light' shader, so...
1a) I obviously need a root lighting brick. The 'Area Light' can't be added to a 'Light' shader, so the 'Base Light' seems the next most logical. Or not?

Base light is the right one. Basically all the light root bricks are the same, the main reason for the different kinds is for optimizing render times, for example by not calculating the shader of a spotlight, if the surface is not within the cone and so.

1b) I obviously need a brick that I can plug my IBL light probe image into. An 'Environment Color Map' seemed logical (although it clearly doesn't take an IBL light probe)

Right. The Environment Map bricks use longitude/latitude maps, not angular ones or lightprobes (BTW the thing in your screenshot looks more like an angular map, not like a lightprobe). You will need to convert them if necessary. In the illustration i used your screenshot, cut out the angular map, and converted it with luminance-hdr.

1c) I almost certainly need to add some other stuff in between. But what?

1) The Environment Map uses a normal to look up a texture value. The default for the normal is the N-Variable. But when used in a light shader, the N-variable is the normal of the light (yes, in 3delight, lights have normals, too), not the one of the surface. The normal of the surface is Ns. To plug it into the Environment Map brick, check "Show advanced parameters".
2) Coordinates (and normals) in the shader default to Camera space in 3delight, probably not what you want for an IBL light, because it would orient the light always towards the camera. Convert it to Shader or World space before plugging the normal into the Environment Map. In the illustration below, i used Shader space, which allows to rotate the environment light by rotating the light object.
3) Normally when using an IBL without occlusion, you would blur the image with a very big radius, to simulate the light from different directions, especially when simulating diffuse lighting. I did not do this in the illustration below, because i think it is easier to see what is going on without it. Poser does this internally, 3delight does not., so the results are not exactly the same.
4) To get exactly the same IBL as with Poser, you will need to think about the orientation of the light., especially when transferring rotation settings from Poser to DAZStudio, because there will be a difference about which side of the environment map is "up" and which is "right" and so on. Hint: in 3delight the normal's x and y are the longitude, and z is the latitude. In the illustration below, i did not care.

Question 2: When you've finished your 'Light' shader and you click 'Create', why does it create a Null, not a Light? What do I have to do to make a 'Light' Shader into an actual light in the scene?

I do not think it matters; lights are not "real" objects anyway. You can simply give it a different name when creating it.
(P.S. I know I could just use the UberEnvironment2 - but that's not going to help me actually understand how to create my own light shaders)

3dcheapskate

Thanks millighost - that's cleared up a lot of things for me. I added the Variable and NTransform bricks as you suggested and my DIY IBL is now casting light - a big step forward!

Time to do a bit more experimentation now.

millighost said:

...The IBL light in Poser has two kind of modes, which behave very differently; without IDL and with IDL. Without IDL it simply projects the environment map onto the surface. No shadows, occlusion or complicated stuff. This is not difficult to do with shader mixer, but some points differ between Poser and DAZStudio anyway, see below...

Hmmm... didn't realise that IBL and IDL were different things!

...Right. The Environment Map bricks use longitude/latitude maps, not angular ones or lightprobes (BTW the thing in your screenshot looks more like an angular map, not like a lightprobe). You will need to convert them if necessary. In the illustration i used your screenshot, cut out the angular map, and converted it with luminance-hdr....

I thought light probes were angular maps (and stated it here)? And I know that mirrorballs aren't angular maps. So are light probes the same as mirror balls then?

Bejaymac

That isn't an IBL, from what I can tell it looks like it's projecting the environment map into the reflection channel, on every object in the scene that's using the default surface shader, use HSS or USS or any other shader and it renders black.

Szark

Bej that is what interior HDRI's can look like. ;) But good HDRI won't be jpeg, yes you can use LDRI such as jpeg but for me what they put out isn't worth using them.

Bejaymac

Let's put it this way Pete, I was using an exterior long/lat that 3dcheapskate posted in the freestuff, I spent a couple of hours last night playing with it in UE2 and got some very good results from it, yet when I plug it into that network I get the attached result, not much use for an IBL but it has some use as a chrome.

Szark

Sorry bej you loast me. I was just refering to what you said about the OP's image no being an IBL. Image based Lighting can use any thing, with in reason but vary due to the quality fo the IBL map.

millighost

3dcheapskate said:

Thanks millighost - that's cleared up a lot of things for me. I added the Variable and NTransform bricks as you suggested and my DIY IBL is now casting light - a big step forward!

Time to do a bit more experimentation now.

millighost said:

...The IBL light in Poser has two kind of modes, which behave very differently; without IDL and with IDL. Without IDL it simply projects the environment map onto the surface. No shadows, occlusion or complicated stuff. This is not difficult to do with shader mixer, but some points differ between Poser and DAZStudio anyway, see below...

Hmmm... didn't realise that IBL and IDL were different things!

IBL is a very general term used for all kinds of lighting based on images, every software does it differently. IDL (indirect diffuse lighting) on the other hand is a very specific marketing term virtually used exclusively by Poser/SmithMicro. In the rest of the world Poser's IDL is rather known as radiosity (at least it looks as they are the same), which is one specific algorithm to simulate global lighting effects. But you can use radiosity with or without IBL.

...Right. The Environment Map bricks use longitude/latitude maps, not angular ones or lightprobes (BTW the thing in your screenshot looks more like an angular map, not like a lightprobe). You will need to convert them if necessary. In the illustration i used your screenshot, cut out the angular map, and converted it with luminance-hdr....

I thought light probes were angular maps (and stated it here)? And I know that mirrorballs aren't angular maps. So are light probes the same as mirror balls then?

I think "mirror ball" and "light probe" mean the same thing more often than not, because they are often used to refer to the object that is being photographed (like in "drill a hole into your light probe, so you can mount it on a tripod"). But it would probably be best not to call it "light probe" to avoid confusion. "Angular maps" in CG practically always refer to a specific mapping, but outside of CG, a "longitude/latitude map" is also called an "angular map". So basically you have three different names you can spread more or less arbitrarily on three different objects without being completely wrong. Many people on the internet make heavy use of that feature :-)

millighost

Bejaymac said:

That isn't an IBL, from what I can tell it looks like it's projecting the environment map into the reflection channel, on every object in the scene that's using the default surface shader
You can call it IBL or not (i would call it IBL, because it uses an image). However if you want something "very similar to Poser's diffuse IBL" (OP) this is basically what you are asking for. A difference is, that it would be an ambient light, not a diffuse light. Coming from 3delight's side, any light that does not have position or direction is ambient. With Poser, there is only one surface shader, which means the lights can rely on a specific behavior of the surface. With 3delight the surface shader can be changed, making it more difficult to make an arbitrary surface shader work with another light shader, because those two need to communicate with each other. The most basic convention is the distinction between ambient and directional lights, supported by most of the surface shaders. The IBL does not have a direction, so it is ambient, which makes it turn up in the surface ambient channel (if you want to call it that, there is no such thing as the "ambient channel" like there are red green and blue channels). It has nothing to do with reflections, however.

, use HSS or USS or any other shader and it renders black.

That is probably right (at least it renders black with the USS2). This is due to the fact that USS2 does not work with ambient at all, or at least i have found out how to make it work; the USS2's parameters named "ambient something" have nothing to do with ambient light, they simply seem to add a constant value to the color (which BTW makes it very similar to Poser's ambient setting which also is not influenced by lights, perhaps that is the idea behind it).

3dcheapskate

3dcheapskate said:

Thanks millighost - that's cleared up a lot of things for me. I added the Variable and NTransform bricks as you suggested and my DIY IBL is now casting light - a big step forward!

Time to do a bit more experimentation now.

Okay, so I spent a bit of time experimenting. I was getting some effects that took a little while to figure out - see attached images.
-The UberEnvironment2 image render is correct, i.e. it's more-or-less identical to my Poser 6 render).
- At first glance the DIY IBL render (using millighosts shader network) looks completely wrong. But I managed to work out the explanation(s) for several of the issues render myself (and millighost's latest post seems to confirm them):

- The DIY IBL is effectively adjusting the ambient colour of every object in the scene, but is not touching the ambient strength. This makes perfect sense to me, and seems a completely logical way to apply a basic global light. But it's clearly not the way Poser does it.
- The lower sphere/cube/torus are solid black because they have ambient strength set to zero. (The upper ones have ambient strength=100%)
- The black text on white for the backdrop becomes coloured because the backdrop has diffuse/specular strength=0%, while ambient strength=100%, and ambient colour=white. (I specifically set it like this in Poser to stop the Diffuse IBL from having any effect on the backdrop!)
- The orientation of the colours is wrong, but MilliGhost already said this would happen in point 4 of the first reply.
- The appearance of the IBL-image on the objects looks more like a reflection than lighting (as Bejaymac pointed out), but this is because there is no automatic blurring applied to the light, as MilliGhost already said in point 3 of the first reply.

But there's two things I can't explain:
1) I'm not sure why the text on the background (which is mapped onto the inside of a large sphere using a lat/long mapping) appears to be blue - unless it's being illuminated from outside the sphere?
2) The front and left of the upper sphere, torus, and cube are the same colours (cyan and yellow respectively) - so why is the top of the cube imagenta, while the top of the sphere and torus are green?

3dcheapskate

Szark said:

Bej that is what interior HDRI's can look like. ;) But good HDRI won't be jpeg, yes you can use LDRI such as jpeg but for me what they put out isn't worth using them.

I'm not too bothered with the HDR side of things yet, not until I better understand creating my own light shaders. But I've already got a provisional (although untested) method of creating true HDR light probes from Terragen Scenes, based on various things I've read (I've added a note about it to the post I think Bejaymac was talking about here).

3dcheapskate

Curiously, using the UberEnvironmet2 incorrectly got me exactly the results I'm trying to achieve. I'd actually deleted the UberEnvironment2 'Sphere' node, leaving just the UberEnvironment2 light node. Hopefully the attached composite screenshot makes it clear how I got what I got - test images from my other thread here http://www.daz3d.com/forums/discussion/20395/#299337

So if I could work out how to do this in Shader Mixer....

Szark

Just so you know the UE2 sphere does nothing but give you a visual reference for rotation and it has no bearing on the light output at all.

3dcheapskate

Szark said:

Just so you know the UE2 sphere does nothing but give you a visual reference for rotation and it has no bearing on the light output at all.

Thanks Szark, that's what I'd originally thought, and on a further check it's obviously correct - if I simply load the UberEnvironment2, set the Environment Mode to 'Ambient (No Ray-Tracing)', delete the EnvironmentSphere child node, apply one of the 'Set HDR xyz.dsa' presets to the UE2, and render I get what appears to be the correct lighting. If I apply a different 'Set HDR xyz.dsa' preset and render then the lighting changes appropriately in the render.

What confused me (or, to be honest, one of the many things that confused me...) is that if I look on the 'Lights' tab for the UE2 nothing has changed. Specifically there's no image applied to the Light > Basic > Color channel (which seemed to me to be the obvious place to apply the light probe).

So I then applied my ColourSpots angular map to the Light > Basic > Color channel (the 'incorrect' way to use the UE2 I assumed, since none of the 'Set HDR xyz.dsa' presets touch this channel) and I was surprised that this gave me the results I'm after.

Millighost's simple light shader network has given me a starting point, but it's giving distinctly different results from the Poser Diffuse IBL without AO (which is what I'm trying to mimic). And more importantly I (sort-of) understand why the results are different.

So I'm still trying to create a DS light shader that has a similar effect to the Poser Diffuse IBL without AO. Still experimenting based on millighost's initial response, which gave me the pointers I asked for. But I may need more pointers soon...
;-)

millighost

3dcheapskate said:

...
But there's two things I can't explain:
1) I'm not sure why the text on the background (which is mapped onto the inside of a large sphere using a lat/long mapping) appears to be blue - unless it's being illuminated from outside the sphere?

Practically it is illuminated from outside. The environment map uses the normal, and because the normal points outwards that is the color it gets.

2) The front and left of the upper sphere, torus, and cube are the same colours (cyan and yellow respectively) - so why is the top of the cube imagenta, while the top of the sphere and torus are green?

This actually seems to be a bug. It happens for the flat faces, where the normal points exactly up or exactly down. For the longitude/latitude mapping, the longitude and latitude are not clearly defined at the north and south pole, which results somehow in the wrong mapping. I do not know if internally a flipped normal is generated or a texture coordinate outside outside the 0-1 range (which would result in wraparound in the texture). It can be fixed by adding a small offset to the normal when it is pointing in the positive or negative y-direction. Also, the environment map brick (as opposed to the environment color map brick) seems to work a bit better. It does not happen in with 3delight's built in environment() map at all, so i think the brick must be doing something slightly different.

Bejaymac

Seeing your side by side comparison renders has reminded me that the environment bricks in the SM have never "worked right", they have always "rotated" the image differently to everything else in the scene, it was first noticed in DS 3.0, when people imported a surface into SM to connect the tiling brick to Bump and the like, on applying back to the surface they noticed their reflection maps were not showing the same as they were before importing.
Someone at DAZ wrote a recipe to fix this, can't remember if it was only available in the bug report or if was made available in the old forums too, I grouped it and saved it as a custom brick in DS3, I'll copy it over to DS4 and see if it still works.

EDIT

The attached pic show the differences

1 = texture applied to diffuse
2 = texture applied to reflection, diffuse strength set to 0%
3 = environment color map plugged into diffuse
4 = the DAZ fix applied to diffuse

As you can see from 1 & 3 there is a quite a difference, the map has been rotated a good 90 degrees, while 2 & 4 are identical, so apparently that's how environment maps are meant to look.

3dcheapskate

Thanks for the replies!

millighost:
- Re the top of the cube being magenta: I'd never have worked that one out! Yep, an x/z rotation of about 0.09° or more and it goes green as it should.
- Re the all-encompassing sphere being illuminated from outside: that surprises me. It's not a Sphere primitive, it's an imported OBJ with only internal faces, so the normals should all be inwards facing. I'm aware that if you import a one-sided plane OBJ (4 vertices, 1 face) into DAZ Studio it'll be visible from both sides (unlike Poser), but I wouldn't expect it to flip the normals?

Bejaymac:
- I guess it should be possible to correct the azimuth by adjusting the normal before plugging it into the Environment Color Map brick? (If it's a multiple of 90 degrees and I have the normals in world space, then simply splitting the normal with an XYZ Components brick, swapping/inverting X and/or Z as appropriate, and then recombining with a Point brick should do the trick, and could also handle any left/right flip of the image by inverting X or Z. Or not, but it's worth a play!)
- Regarding image 4 - are you* saying that's how an environment map applied to diffuse should look?

*or DAZ, or whoever it was at DAZ who wrote the fix

3dcheapskate

Anyway, back to my simplistic experimenting. After a quick download and read of RiSpec 3.2.1 (well I've only actually skimmed through pages 120-122...) and a brief foray into ShaderBuilder (which is beginning to make a vague sort of sense now...) I'm back playing with ShaderMixer.

And back to the very, very basics - trying to work out how to get a light shader that only affects the DAZ surface diffuse colour, and not the DAZ surface ambient colour.

My test subjects this time are 3 DS sphere primitives with a red-white-and-black checker image applied to ambient colour only. The only differences between the spheres are the diffuse/ambient strength.

I then created three ShaderMixer lights and did a render with each light. Each light is a single lighting root brick - all I changed was setting the light colour to green.
1. Just a 'Distant Light' root brick
2. Just a 'Base Light' root brick
3. Just an 'AreaLight' root brick applied to a long thin cylinder
Results in the attached image reminded me of these two comments: way back in the second post...

millighost said:

...Base light is the right one. Basically all the light root bricks are the same, the main reason for the different kinds is for optimizing render times, for example by not calculating the shader of a spotlight, if the surface is not within the cone and so...
...and in post #8...
... The most basic convention is the distinction between ambient and directional lights, supported by most of the surface shaders. The IBL does not have a direction, so it is ambient, which makes it turn up in the surface ambient channel (if you want to call it that, there is no such thing as the "ambient channel" like there are red green and blue channels)...

Looking at the results I assume that the Base Light must be non-directional. The Distant Light is clearly directional - so if I took that and if (instead of doing whatever jiggery-pokery it does with surface-normal and light-direction) I just plugged surface-normal into an Environment Color Map and used the light colour from that, then Bob's your Uncle!

But I'm beginning to think that what I want may not be easy (possible?) in Shader Mixer - maybe I need to dive into Shader Builder?

3dcheapskate

Well, I think I've got what I wanted using ShaderBuilder in DS3. Ridiculously simple really - almost embarrassingly so! It's just a point light whose position is defined by the point on the surface being illuminated - i.e. the point light is at the end of the surface normal.
Started with the DzPointLight network, disconnected the shadow stuff, adjusted a few connections, added an Environment macro and a couple of user inputs and it worked first time! Screenshot of the bits that are doing things attached. Also a DS3 render (similar setup to the 3 spheres in the previous post). Of course I need to do a bit more testing and make sure it's really working as a want...
If that goes okay I'll maybe try to do the same in ShaderMixer.

millighost

3dcheapskate said:

Well, I think ....
If that goes okay I'll maybe try to do the same in ShaderMixer.

I fear it will not work in shader mixer, because it is missing the Illuminate function. Perhaps you can make a custom brick in shader builder and import it into shader mixer. I have read somewhere that this is possible (but i did not try it myself).

3dcheapskate

millighost said:

3dcheapskate said:

Well, I think ....
If that goes okay I'll maybe try to do the same in ShaderMixer.

I fear it will not work in shader mixer, because it is missing the Illuminate function. Perhaps you can make a custom brick in shader builder and import it into shader mixer. I have read somewhere that this is possible (but i did not try it myself).

Yep, a custom brick might be the way to go for ShaderMixer (have to do some reading up). But I've done a bit more testing with the ShaderBuilder light from my previous post, and I'm fairly sure that it does what I want (attached test renders) - so I'm wondering is there any point trying to do it in Shader Mixer too?

I think the Shader Builder network needs a bit of tweaking so...

...A Couple Of Shader BUILDER Queries
1) The unnecessary parameters from the 'User Parameters' macro appear on the DS parameters tab, and I want to stop that. ButI can't delete the parameters I don't want (i.e. shadow stuff) from the 'User Parameters' macro since the 'Delete' option is greyed out (even after disconnecting them from everything). I can't replace the 'User Parameters' macro or delete the old one, or add a new one. And if I create a new SB light shader from scratch it gives me a predefined 'User Parameters' block with parameters I can't delete
2) With no Environmental map the light colour is black. I think I can fix this with a conditional 'if (no EnvMap) then (use just light color)
3) I have to give my light a 180 deg Y rotation and a -90 deg X rotation to get it oriented to match my background. Should be able to adjust the Ns before plugging it into the Environment macro.

Edit: 4) A more general observation - I think the effect of the environmental IBL should be a lot more subtle. Basically greyish light with just a hint of colour? So maybe ((color x intensity) x environment color) isn't the right mix? Time for a bit more experimenting...

3dcheapskate

(Just in case you hadn't noticed, I've changed my display name from 3dcheapskate to unrealimperfect - just trying it out... it's already had me confused, so I added a note to my siggy too!)

Been doing a lttle side-by-side-comparison of this DIY DAZ Studio ShaderBuilder Diffuse IBL against the Poser version and it's looking reasonably good. Basic test scene is P6 Jessi, three primitives, a DIY terrain, a DIY all-encompassing background sphere (background image from here), a distant light for casting the shadows, and a diffuse IBL. For the DAZ Studio renders I imported the PZ3 I'd used in Poser and replaced the Diffuse IBL with my DIY DS SB version.

I'm fairly sure that most of the differences can be fixed by tweaking settings, e.g. to get the relative intensities of the two different lights nicely balanced. But there are two things I hadn't spotted/thought of before:

...carrying on the numbering from the last post for the ShaderBUILDER queries...
5) The DIY DS SB version is creating specular highlights (you can see them on the sphere and torus in the bottom-right render) - it shouldn't, so I need to work out how to prevent this.
6) The DIY DS SB version shows up as a point light in the preview (that'll be because I created it from a DzPointLight SB macro). It would be nice if I could find a way to change this, but it's a rather minor issue.

almahiedra

millighost said:

3dcheapskate said:

Well, I think ....
If that goes okay I'll maybe try to do the same in ShaderMixer.

I fear it will not work in shader mixer, because it is missing the Illuminate function. Perhaps you can make a custom brick in shader builder and import it into shader mixer. I have read somewhere that this is possible (but i did not try it myself).

nothing of my shaders in shader builder with illuminance block works in shader mixer. Probably I'm very wrong, but I believed Iluminate was in shader mixer before.