Was there ever a non-beta Shader Mixer for DS3A? [Reflection problems resolved]

2»

Comments

  • millighostmillighost Posts: 260
    edited December 1969

    Kadix said:
    ....
    Normally, when I render from EXACTLY the TOP VIEW, I should see the roof and very partially the walls on the side, but in no way the floor (which can only be reflected on the bottom part of the sphere). ...

    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?
    reflect.png
    500 x 450 - 33K
  • millighostmillighost Posts: 260
    edited December 1969

    ...
    However, I think the other problem, the black diffuse, is a genuine problem. Unless of course I've made a stupid mistake there too...

    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.
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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)

    mapreflok.jpg
    254 x 545 - 70K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    ...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/ )"

    standardMat.jpg
    1072 x 594 - 135K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited December 1969

    ...
    However, I think the other problem, the black diffuse, is a genuine problem. Unless of course I've made a stupid mistake there too...

    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

    results.jpg
    750 x 546 - 80K
    raytraced.jpg
    750 x 553 - 93K
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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!

    network.png
    620 x 595 - 53K
    stdMatx1+smMatx2.jpg
    840 x 647 - 78K
    stdMatx3.jpg
    874 x 513 - 65K
    Post edited by 3dcheapskate on
  • V3DigitimesV3Digitimes Posts: 2,318
    edited January 2015

    Kadix said:
    ....
    Normally, when I render from EXACTLY the TOP VIEW, I should see the roof and very partially the walls on the side, but in no way the floor (which can only be reflected on the bottom part of the sphere). ...

    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.

    Post edited by V3Digitimes on
  • millighostmillighost Posts: 260
    edited December 1969

    ...
    However, I think the other problem, the black diffuse, is a genuine problem. Unless of course I've made a stupid mistake there too...

    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
    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.

  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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)

    SMplastic.jpg
    599 x 498 - 34K
    metallic.jpg
    722 x 498 - 39K
    plastic.jpg
    722 x 498 - 43K
    Post edited by 3dcheapskate on
  • Eva1Eva1 Posts: 1,116
    edited December 1969

    ...

    I'm not so surprised. I was looking into ShaderMixer reflections in some detail two years ago and never nailed it down - I just had a feeling that something wasn't quite right, and left it at that. And it's taken a fair bit of digging over the past few days to get to the bottom of it ! (You have to be a bit crazy to dig this deep... LOL )


    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...

  • V3DigitimesV3Digitimes Posts: 2,318
    edited December 1969

    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/

  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    Kadix said:
    ....
    Normally, when I render from EXACTLY the TOP VIEW, I should see the roof and very partially the walls on the side, but in no way the floor (which can only be reflected on the bottom part of the sphere). ...

    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)

    DS46test.jpg
    900 x 450 - 107K
    P6test.jpg
    866 x 405 - 59K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    Eva1 said:


    ...
    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...

    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)...

    ...
    - 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.
    ...
    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.

    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

    Post edited by 3dcheapskate on
  • V3DigitimesV3Digitimes Posts: 2,318
    edited January 2015

    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.

    Post edited by V3Digitimes on
  • millighostmillighost Posts: 260
    edited December 1969

    ....
    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...)

    Most likely there is something wrong with the map. Longitude/Latitude maps (which are commonly used for the environment brick) come in at least two variations: Panoramic images (made by pointing a camera wildly in different directions and then stitching the images together) and reflection maps (often made by taking a photo of a polished silver ball and then transforming the result). In the end reflection maps are mirrored and environment maps are not. Of course, both can be converted to each other. But this is not enough: there is also the question which direction is "Up" in the environment map. 3delight traditionally uses maps with the x-axis (horizontal direction on the image) being "Up" in world-space where the rest of the world uses the y-axis. Also 3delight has a left handed coordinate system, where DAZStudio uses a right handed one (probably to be poser-compatible), so the transformation is partly built in the environment brick. UberEnv2, for example uses the traditional mapping which gives users and vendors alike all kinds of headaches of wondering why their maps do not look right. Most often this problem is "solved" by using an environment map where it is not that important if it is oriented wrong, i.e. avoid maps with text in it, and such. So if you want to have predictable reflections using maps you have to either build your own (either directly creating them directly or converting existing ones), or build the transformation into the shader, for example by building NMatrixTransform brick into the shader (which can rotate and mirror the vectors). In any case, a colored environment cube (like your test cube) is extremely helpful :-)
    There is a custom brick for shadermixer which mixes mapped and traced reflections, i did a while ago; in principle it still works, but has some problems in the latest DS versions (slow startup and bad behaviour if parameters are too low), perhaps you might find it useful:
    https://sites.google.com/site/millighostmix/home/maptrace-brick

    (Sidenote: without the Reflect and NTransform bricks my shader was (unintentionally) using the third type of reflection that Kadix mentioned here


    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" :-)
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    ....
    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...)

    Most likely there is something wrong with the map. Longitude/Latitude maps (which are commonly used for the environment brick) come in at least two variations: Panoramic images (made by pointing a camera wildly in different directions and then stitching the images together) and reflection maps (often made by taking a photo of a polished silver ball and then transforming the result). In the end reflection maps are mirrored and environment maps are not. Of course, both can be converted to each other. But this is not enough: there is also the question which direction is "Up" in the environment map. 3delight traditionally uses maps with the x-axis (horizontal direction on the image) being "Up" in world-space where the rest of the world uses the y-axis. Also 3delight has a left handed coordinate system, where DAZStudio uses a right handed one (probably to be poser-compatible), so the transformation is partly built in the environment brick. UberEnv2, for example uses the traditional mapping which gives users and vendors alike all kinds of headaches of wondering why their maps do not look right. Most often this problem is "solved" by using an environment map where it is not that important if it is oriented wrong, i.e. avoid maps with text in it, and such. So if you want to have predictable reflections using maps you have to either build your own (either directly creating them directly or converting existing ones), or build the transformation into the shader, for example by building NMatrixTransform brick into the shader (which can rotate and mirror the vectors). In any case, a colored environment cube (like your test cube) is extremely helpful :-)
    There is a custom brick for shadermixer which mixes mapped and traced reflections, i did a while ago; in principle it still works, but has some problems in the latest DS versions (slow startup and bad behaviour if parameters are too low), perhaps you might find it useful:
    https://sites.google.com/site/millighostmix/home/maptrace-brick

    (Sidenote: without the Reflect and NTransform bricks my shader was (unintentionally) using the third type of reflection that Kadix mentioned here


    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.

    stdReflCloseup.jpg
    946 x 946 - 292K
    BallSphereRefcubeStdRefl(traced).jpg
    946 x 946 - 324K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited December 1969

    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.)

    3_-_DSmapping-INV_refl.jpg
    946 x 946 - 240K
    DSmapping-LL1024-INV.jpg
    1024 x 512 - 61K
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited December 1969

    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.

    4_-_Import_into_SM_and_Apply_back.jpg
    946 x 946 - 221K
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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

    millig.png
    855 x 463 - 50K
    5_-_Adding_millighosts_2_extra_bricks.jpg
    946 x 946 - 248K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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)

    offset90.jpg
    946 x 946 - 240K
    DSmapping-LL1024-INV-Offset90.jpg
    1024 x 512 - 112K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited December 1969

    ...and a close-up of the sphere

    closeup.jpg
    946 x 946 - 316K
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015


    ....
    (Sidenote: without the Reflect and NTransform bricks my shader was (unintentionally) using the third type of reflection that Kadix mentioned here

    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?

    swirlyswirly.jpg
    512 x 512 - 57K
    Post edited by 3dcheapskate on
  • BejaymacBejaymac Posts: 1,282
    edited December 1969

    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.

  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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...)

    close.jpg
    946 x 946 - 302K
    render.jpg
    946 x 946 - 240K
    nw.png
    860 x 666 - 142K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    Bejaymac said:
    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.

    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 )

    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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?)

    Finally(Closeup).jpg
    946 x 946 - 338K
    Finally.jpg
    946 x 946 - 240K
    Finally.png
    862 x 621 - 142K
    Post edited by 3dcheapskate on
  • millighostmillighost Posts: 260
    edited December 1969

    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?

    The "current" space in 3delight is the same as the "camera" space. The "camera" space is left-handed, i.e. when having the right side of the camera pointed in the x-direction and the upside in the y-direction, the camera looks into the direction of positive z, this is the "current" space. The DAZ-Studio camera (without any transformations applied) is exactly the opposite (when increasing the z-value of the camera it moves backwards), this is the "world" space. So current and world are mirrors of each other, transforming from one to the other mirrors everything.
    Note that the matrix-n-transform brick has no to-space input. This is because the to-space is given by the matrix (in form of the rotations, translations etc.). The matrix-n-transform brick transforms points in from-space to the space that results when points in the current space are transformed by the matrix. This effectively results in the inverse of the matrix being applied to the points in from-space. The result is always in current-space. Since this is probably difficult to read, think of the matrix-n-transform as always transforming to current-space. And this does flip the orientation if from-space is world.


    (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).
  • 3dcheapskate3dcheapskate Posts: 2,067
    edited January 2015

    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... :)

    WorldVersusCamera.png
    934 x 759 - 120K
    Post edited by 3dcheapskate on
  • Eustace ScrubbEustace Scrubb Posts: 2,432
    edited December 1969

    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.

Sign In or Register to comment.