Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Here is a little puzzle i made up: In the image is a cross-section of a mirror sphere in a room with red floor, blue wall, and green ceiling. A light ray comes from above and hits the sphere near its "rim" (from the lightsource's view it is the rim) at the point of impact. The lightray can reflect
a) towards the green ceiling (because it is supposed to go back to where it came from whenever possible)
b) towards the blue wall (because it is should hit a tiny part of the wall)
c) towards the red floor (because it wants to leave the surface at the same angle it arrived there)
What would be the most likely direction, and why?
They might have fixed it in 4.7 (i do not have 4.6 anymore, so i cannot check). If you can boil it down to 3 or 4 nodes i can try it out.
Okay, I've confirmed for myself that millighost's *two extra bricks do the trick. I simply added them to the Shader Network in post #21 of this current thread (plugged into the brick middle left labelled "Reflection Map", which is actually an Environment Color Map brick), and set the "Mapped Or Raytraced slider to 0.5 (so we get 50/50 mapped/raytraced reflections), and grey diffuse on both sphere and plane) Here's the render (DS 4.1.1.17 Pro 64 bit). It now looks right, in that I can see the reflected grid in the plane now. But I need to do more tests to confirm the the actual part of the environment map that we see in the reflection is actually the correct part.
I'm just going to do another check based on Kadix' confirmation of my observations - i.e.setting up an environment mapped reflection from a standard (i.e. NON-ShaderMixer) material via the Surfaces tab, opening ShaderMixer and loading from the scene (I have a feeling that's how originally worked out the bricks required for my network)...
*Kadix - I didn't look into whether the NTransform brick is really required. (Edit: see post 36 below)
...and here's what happens if you get ShaderMixer to import the mapped reflection from the scene for you. It appears that if you do 'File > Import From Scene' from ShaderMixer (*DS 4.6) with a material that has an environment mapped reflection, then Shader Mixer forgets to put in a rather important brick or two.
*Kadix - did you do your test with DS4.7 ?
Edit: Bug report 184174 amended with the following new comment:
"Update. The bug has now been tracked down to ShaderMixer's 'File > Import From Scene' option. (not sure whether it's still a problem in DS4.7)
If you load a plane primitive and set up environment-mapped reflections on the default (NON-ShaderMixer) material, i.e. on the Surfaces tab set Reflection Strength = 100% and plug an image into 'Reflection Color, and then open Shader Mixer, do 'File > Import From Scene', and apply that straight back the environment mapped reflections no longer work (N.B. This is only really apparent on a flat plane).
The fault is that ShaderMixer simply plugs an Environment Color Map into Reflection Color, and doesn't add the essential 'Reflect'brick.
For more information see post #28 ( http://www.daz3d.com/forums/discussion/7582/P15/#744801 ) and post #34 ( http://www.daz3d.com/forums/discussion/7582/P30/#745123 ) of the "Was there ever a non-beta Shader Mixer for DS3A?" thread ( http://www.daz3d.com/forums/discussion/7582/ )"
They might have fixed it in 4.7 (i do not have 4.6 anymore, so i cannot check). If you can boil it down to 3 or 4 nodes i can try it out.
It's just a Trace brick plugged into Reflection Color (which is the network you get if you set up raytraced reflections on a standard material and do 'File > Import From Scene' from ShaderMixer.
Test/screenshots below using DS4.6.1.17 Pro 64bit as usual
Is The NTransform Brick Really Needed For Environment Mapped Reflections?
Back to Kadix query about whether the NTransform brick is required for environment mapped reflections.
For the first image in this post I set up raytraced reflections on each plane/sphere pair using the standard NON-ShaderMixer material. That's our 'control', and I'm taking this as being 'correct' reflections.
For the second image I used 'File > Import From Scene' in ShaderMixer. With the central sphere/plane pair I added just a 'Reflect' to this (as Kadix suggest). With the right sphere/plane pair I added a 'Reflect' and 'NTransform' as millighost initially stated.
The third image shows screenshots of the added bricks.
To me both central and right sphere look okay in the second image (although a test with a more strongly coloured map is probably required to confirm orientations are correct), but (surprisingly) both central and right planes still look wrong (i.e. they don't match the first image). The central one obviously so, but the right one more subtly - note the colours of the '+' signs, which indicates that they're not showing the same part of the environment map as a reflection.
Once again I'd appreciate if somebody else can confirm/refute this - I may have made a mistake in setting up even these very simple networks, and I didn't save the scene!
Here is a little puzzle i made up: In the image is a cross-section of a mirror sphere in a room with red floor, blue wall, and green ceiling. A light ray comes from above and hits the sphere near its "rim" (from the lightsource's view it is the rim) at the point of impact. The lightray can reflect
a) towards the green ceiling (because it is supposed to go back to where it came from whenever possible)
b) towards the blue wall (because it is should hit a tiny part of the wall)
c) towards the red floor (because it wants to leave the surface at the same angle it arrived there)
What would be the most likely direction, and why?
The laws of reflection : http://en.wikipedia.org/wiki/Reflection_(physics)
On your sphere : you take the normal to surface at the hit point. You draw it.
You take your incident ray and measure the angle of this ray with the normal. The reflected ray will have the same angle with the normal, but the other side of the normal.
Now try to ray trace this and you will see that rays from the floor should go "through" the sphere in order to reach the camera. Which is not the case, that is why strictly from above you should not see floor reflection. This is why I'm 99% convinced that there is no reason to plug a world change on the environment map. My feeling is that is already included in.
It's just a Trace brick plugged into Reflection Color (which is the network you get if you set up raytraced reflections on a standard material and do 'File > Import From Scene' from ShaderMixer.
Test/screenshots below using DS4.6.1.17 Pro 64bit as usual
Ah, now i can see what you have done! I do not think it is an error but rather a simplification; in nature a material's color is made of two components, diffuse and specular reflection. The color of a material is mostly only the diffuse reflection color (produced by subsurface scattering). The specular reflection is very weak and always the same color as the light (ie specular color is white). The only materials where the specular color determines the overall color because they have practically no subsurface scattering are metals. So for metals it makes sense to use the diffuse color also for reflections. Think about a copper plate: it can be rather diffuse (because the surface is rough) or shiny (because it is polished), but the color will be the same, i.e. diffuse and specular color are not independent. And that is exactly what is behind setting the "Lighting model" of the "DS Default Material" to "Metallic"; the diffuse color is multiplied into the reflection color (like Richard Haseltine guessed some posts ago). It is the same with DS4.7, by the way.
Just confirmed millighost's explanation (previous post, #38) of my black diffuse "problem"...
It's NOT a problem - it's correct. That's how the Metallic lighting model should work
(In all my ShaderMixer tests the lighting model is set to 'metallic', whereas in all my 'NON-ShaderMixer' tests the lighting model is plastic.)
First and second images are a comparison of the effect of the two lighting models on ray-traced reflections in a standard (NON-ShaderMixer) material.
Third image is a ShaderMixer shader with ray-traced reflections, black diffuse, and PLASTIC lighting model - a final verification that using the plastic lighting model in the ShaderMixer matches earlier tests with the standard material. (note, its actually using 50/50 mapped/raytraced, without the fix that millighost's already pointed out for mapped reflections)
Using DS4.6 as usual
(Note: 'Lighting Model' doesn't appear on the Surfaces tab of the standard DS UI, and you have to open Shader Mixer to see/change it - it's at the bottom of the DS Default Material brick)
Well, there is only an environment map plugged into the reflection color. There is no reflection happening at all (just giving the environment map the title "Reflection Map" like DS4.6 appearently does is not enough). This is basically a static texture on the surface. It should include a reflections somewhere something like this:
Just a quick question for anyone that can answer - if you include environment maps using this set up , does the object it's applied to show any reflections at all. E.g if on a sphere with reflections at 100% should I see both the map image and objects in the scene reflected? Or should you only see the map on the sphere. I don't ususally use environment maps, so I'm not sure exactly what I should be seeing...
I've spent weeks working on my metal shaders (Advanced Metal Shaders and Advanced Metal Creator), and a lot of time in the brick network. I've spent years working as a photonics specialist, simulating real materials in photometric softwares and also acquiring and treating BRDFs for inputing them in theses softwares. I just want to share what I learn here as a DAZ shader developer, taking into account my optician background :
- The environment map does exactly what we ask it to do : fake an environment around the objects corresponding to the plugged environment image. And what we render is the reflected fake environment. The current to world change is already plugged in it.
- To have the exact image of the real surrounding environment, you just have to use a 100% ray tracing.
- In DAZ there is also another type of reflection, which is using the UV map, and can be useful too.
Yet, in our 3D scenes, the scenes are "too poor" in term of real environment so that 100% tracing, except in some specific circumstances (for instance interior scene), is insufficient. Why? Do you put something behind your camera? Above the scene, on the side of it? No, and this is what is rendered when is ray traced. The big empty!!!
The best solution is to have a mix : trace and environment : trace for the real reflections of the object of the scene, environment to "fake" that the rest of the scene is full of something.
Concerning diffuse : the diffuse is actually the diffuse reflection and correspond to surfaces having a very rough surface condition, meaning that on the millimetric / sub-millimetric level they have very different angles of reflection. In general if you want to have imaging reflections you have to kill the diffuse. Because imaging reflections correspond to polished surface conditions. Diffuse is the contrary.
This is the short version. I made a much more detailed topic about metal here : http://www.daz3d.com/forums/discussion/41437/
Here is a little puzzle i made up: In the image is a cross-section of a mirror sphere in a room with red floor, blue wall, and green ceiling. A light ray comes from above and hits the sphere near its "rim" (from the lightsource's view it is the rim) at the point of impact. The lightray can reflect
a) towards the green ceiling (because it is supposed to go back to where it came from whenever possible)
b) towards the blue wall (because it is should hit a tiny part of the wall)
c) towards the red floor (because it wants to leave the surface at the same angle it arrived there)
What would be the most likely direction, and why?
A real life chrome ball (or a bit of maths*) would be the easiest way to prove this. Since I don't have a chrome ball handy, I decided to use a virtual chrome ball instead. I did a simple test in both Poser 6 and DAZ Studio 4.6. The setup's very simple and easy for anybody to reproduce:
- a largish cube centred at the origin (large enough to hold a virtual camera, chrome ball, and light source. I used a cube 1 Poser Unit along each side, so about 8' x 8' x 8'. The main condition is that the cube must be visible from within.
- a sphere, about a tenth the size of the cube, also centred at the origin.(*1) The exact size isn't too important - just something to approximate the size of a real-world chrome ball.
- a camera vertically above the centre of the sphere looking vertically downward at the sphere. The camera is inside the cube, just below the top face.
- a point light(*2) slightly below the sphere (we need some light inside the cube, and I put it out of direct camera view so it doesn't overpower the reflected image on the sphere.)
Each cube face is a different colour: north=blue; east=cyan; south=yellow; west=red; up=green; down was originally magenta. But I changed this to a tiled texture to make the results of the tests crystal clear.
I'd guess that both Poser and DAZ Studio have got the basic laws of reflection more-or-less right, so unless anybody can spot a major cock-up in my test I think the results are pretty conclusive about whether you should see the floor in the reflection?
(but there's still that discrepancy between the colour of the plus signs in post 36 - something's not quite right with the NTransform brick...)
(*1 -the Poser hi-res ball primitive has its base at the origin. That's good enough for this simple test.
(*2 - I had to use a linear point light with intensity=200% and falloff start/end= 600 in DAZ Studio to get all internal faces of the cube lit up)
*Yes, I've also done the maths, but I think this test is far more fun! ;o)
That three-brick (Reflect -> NTransform -> Environment Color Map) network plugged into the DS Default Material's Reflection Color doesn't do any ray-traced reflections at all (unless I've completely misunderstood!) - it's simply used to determine which point on the environment map image to take the colour from. To get ray-traced reflections you need a 'Trace' brick - in the SDMS beta that's the one I re-labelled* as 'Reflection Trace', and then you need to combine the mapped and raytraced somehow.
(Sidenote: without the Reflect and NTransform bricks my shader was (unintentionally) using the third type of reflection that Kadix mentioned here (emboldening (!?) is mine)...
Using just one of the three types of reflections that Kadix mentions works fine in many situations. But being able to mix mapped and traced seems better... and now I'm thinking that adding UV mapped reflections into the mix would be fun too ! :D
*Re-labelling seemed a great idea at the time... :oS
I think it is interesting for the user to be able to choose depending on the rendering circumstances.
I've already implemented rays + environment mix in my "advanced metal shader" and "advanced metal creator" products.
I also have the total add : "ray+UV reflection +Environment map" with independent control for each and total control of the sum in all my "Amazing Skins" product (some of the eyes materials). For the Amazing skins, I never mentioned it anywhere else since I thought people would find it by themselves. And I think it is better to have the UV version too with the rest of the reflection.
Without the Input connected, the environment-brick uses the surface normal as input (i.e. a sphere-mapping). No UVs or reflection involved. So i would not call that a "type of reflection" :-)
Without the Input connected, the environment-brick uses the surface normal as input (i.e. a sphere-mapping). No UVs or reflection involved. So i would not call that a "type of reflection" :-)
(Referring to my comment/millighost's response in red above) Agreed - that seems the most logical answer, and brings to mind the UE2 problem ... but none of the mappings I've tried seems to work. Edit - resolved that, correct mapping in post #50
I'm doing a number of tests to get to the bottom of this. Lets start with a new 'control' - a plane primitive and sphere primitive inside the test cube setup from a couple of posts back (edit: post #42)
I've set Reflection Strength of both the sphere and plane to 100%- they're using the standard (NON-shadermixer) materials, so this means 100% raytraced.
The camera is 'behind' the world origin, i.e. along the negative Z axis, facing the origin. The back wall of the cube is yellow, and the 'floor' is back to magenta. (edit: for these next tests I added text to all faces, the right way round when you look at the face from within the cube)
Everything in the attached render seems correct to me, so I think we have a good starting point.
Next step - Ijust plugged a reflection map into the Reflection Color of the sphere and plane. Once again done from the standard DS material (NON-shadermixer).
I also made all faces of the cube white to avoid any confusion - this test is MAPPED REFLECTIONS ONLY
The reflection map I used and the resulting render are attached.
Once again results look correct, as expected (note: you don't see the plane reflected in the sphere or vice versa of course, since there is NO ray-traced reflection.)
Now I open shadermixer, import the sphere material from the scene and apply it straight back. Same for the plane. We already know thiere is a bug in this.
The resulting render is clearly wrong.
Now I just add millighosts two extra nodes to the shader network for the plane and sphere. I am still using the same reflection map as before.
Once again the result is clearly wrong. But it seemsto be a matter of orientation of the reflection map, just as millighost suggested
So I simply rotated the reflection map clockwise by 90 degrees (manual edit in GIMP). Here's the adjusted reflection map and the resulting render.
That seems correct to me.
(Edit: Is there a simple way to put that 90 degree adjustment into the network? Rather than having to manually edit every reflection map... )
(Edit2: Just re-read millighost's post - I think it might have to be the 'Matrix NTransform' brick)
...and a close-up of the sphere
Without the Input connected, the environment-brick uses the surface normal as input (i.e. a sphere-mapping). No UVs or reflection involved. So i would not call that a "type of reflection" :-)
Darn it, that was a last-ditch attempt at justifying my original mistake! ;o) LOL
Edit - but I'm not going to give up yet... one last,last-ditch attempt :D ... Surely applying the following image (or similar) via just an Environment Color Map brick to Reflection Color could pass as a quick'n'dirty faked gold reflection?
Little tip, only ever "import from scene" when you know the shader was built from the ground up in the SM, doing so with the default surface shader just gives you a facsimile of the shader, but with a number of issues and is therefore a load of crap.
This reflection issue is one of the issues and it's been there since the start, they did give us a "rough" workaround in the old bug thread on mantis, but even that didn't give the exact same results you see with the default surface shader.
Tried adding a Matrix NTransform brick and using the original reflection map
I've totally lost track of where the X,Y and Z point for the purposes of this brick, so I'm playing trial-and-error... and I don't really know what I'm doing...
Why's everything suddenly the right way round (i.e. the wrong way round). I'm getting confused...
:oS
(Edit: for the close-up I mistakenly moved the camera closer, rather than increasing the focal length, so it's only the non-back-to-front-ness of the reflection that's wrong here. Flipping an axis is simply a case of setting X/Y/Z Scale to -100% if I remember correctly...)
I managed to do a fair copy (or duplicate / triplicate) of the default surface shader in shadermixer two years ago - although I knew a couple of things (normals, refraction, and reflection) weren't quite right.
But it's only within the past couple of days that I've realized just how way-off-the-mark reflections were! LOL
However, I think I'm getting there...
:oS
(P.S. re your little tip - I wish somebody had told me that two years ago! LOL )
Took a break, came back and tried again - I think I've got it this time. I left the Matrix NTransform > Settings > From at its default value 'Current', instead of changing it to 'World' as in the previous post.
I don't understand why using 'World' seemed to flip the map - can anybody explain?
(Edit: can we now do away with the NTransform brick by incorporating what it does into the Matrix NTransform?)
Not really. Since the reflection map is in world-space and the matrix-n-transform always gives results in current-space, the result must be somehow converted to world-space (with the ntransform brick), although in theory it is possible, but it would most likely be even more complicated.
Note that setting the matrix-n-transform brick's space to "current" and then applying it to values in world-space is no problem, because the matrix-n-transform brick does not really "know" which space its inputs are in. And a rotation in current-space is the same as a rotation in world-space (or in any other space).
The bit about left and right handed axes rings a rather loud bell ! I've done a quick picture to summarize that little bit of what you said - I think I've got it right?
Edit 1: In the working network of post #56 setting the 'From' space of the NTransform and MatrixNTransform bricks to either Current or Camera (in any of the four possiblepermutations) gives me the same correct result, so that seems to confirm that Current and Camera space are the same.
Edit 2: Regarding the mirror-image/flipping thing I'm still straining that through my brain... :)
That looks right to me: it assumes that the initial camera and figure face each other, and that +X for either moves it to viewport-right, +Y moves it up, and +Z moves camera toward figure, or vise versa.