Alan's Lab - current topic: UberEnvironment 2 Lighting Rig

edited October 2012 in Art Studio

Hi. Alan here, of www.alanscape.com. This is my gallery thread in the Art Studio section (obviously), but I figure it can also serve as a repository for the techie "playing around" that seems to occupy so much of my DAZ Studio time. Hey, it's all part of the fun of the hobby, right?

The first sequence of posts was on jury-rigging a Spot Render within DAZ Studio.

Next came tests of Sub-Surface Scattering.

Currently, I'm experimenting with an UberEnvironment 2 Lighting Rig.

Post edited by merc-daz3d_c669b168a9 on

Comments

  • edited October 2012

    How To Improvise a "Spot Render" in DAZ Studio . . . [Transferred from another thread.]

    Shaaelia said:
    ... I wish I wish I wish that there was a way to save a spot render out at a particular resolution. ...

    I can't remember which thread it was in, but someone somewhere posted a clever trick for doing this in DAZ Studio. Basically, it's a variant on the old artist's framing/composition aid that uses two L-shaped pieces of cardboard as an adjustable viewfinder. (Maybe someone with a better memory and/or search fu can find the post.)

    As an example, suppose I wanted to change just the hairstyle on this render...

    BruunaLoopFelicity.png
    1600 x 2000 - 3M
    Post edited by merc-daz3d_c669b168a9 on
  • edited August 2012

    Here's a screencap showing the camera I'm reusing, with the "two Ls" gadget blocking out the parts I don't want to re-render. I used two different pastel-ish colors here, for illustration purposes, but any color would work.

    The surfaces of the L objects are using the standard "DAZ Studio Default" shader, with Diffuse strength at 0%, Specular strength at 0%, and Ambient strength at 100%. (It's the kind of surface setup you'd use on a sky dome.) This leaves very little for the render engine to calculate, so the blocked-out areas render very quickly. I also set the L objects not to cast shadows (again, like a sky dome) to pick up a little more speed.

    For positioning convenience, I parented the two L objects to the camera. I zeroed out their rotations--- except for rotating the second L in the Z plane by 180 degrees. Then I translated them around until I had blocked off everything but the spot I wanted to re-render. They ended up quite close to the camera, as you can see.

    framingcap.jpg
    700 x 500 - 34K
    Post edited by merc-daz3d_c669b168a9 on
  • edited August 2012

    Here's the resulting "spot render."

    Since the changed area was near the top, I didn't even have to let the render run to completion. (Although I still wasn't fast enough to stop it right after the important part was done!) This is using the default "Bucket Order" of "Horizontal" (which is set in the Advanced options of the Render tab.) If I needed to re-render an area near the lower left of the image, I'd use "Vertical," which works its way across in vertical columns. The "Spiral" bucket order works outward from the center.

    For a spot render in the lower right corner--- oh well, I guess I'd be waiting for the full render. But not as long as I would be if I didn't block out the rest of the scene...

    spotrender.jpg
    700 x 350 - 8K
    Post edited by merc-daz3d_c669b168a9 on
  • edited December 1969

    [Reserved for composite.]

  • edited August 2012

    The L object that I used is tiny, so here's a code embed:

    v -15.00000000 -15.00000000  0.00000000
    v -5.00000000 -15.00000000  0.00000000
    v  15.00000000 -15.00000000  0.00000000
    v -15.00000000 -5.00000000  0.00000000
    v -5.00000000 -5.00000000  0.00000000
    v  15.00000000 -5.00000000  0.00000000
    v -15.00000000  15.00000000  0.00000000
    v -5.00000000  15.00000000  0.00000000
    
    vt  0.33333333  0.33333333
    vt  0.00000000  0.33333333
    vt  0.00000000  0.00000000
    vt  1.00000000  0.00000000
    vt  1.00000000  0.33333333
    vt  0.33333333  0.00000000
    vt  0.33333333  1.00000000
    vt  0.00000000  1.00000000
    
    vn  0.00000000  0.00000000  1.00000000
    vn  0.00000000  0.00000000  1.00000000
    vn  0.00000000  0.00000000  1.00000000
    vn  0.00000000  0.00000000  1.00000000
    vn  0.00000000  0.00000000  1.00000000
    vn  0.00000000  0.00000000  1.00000000
    vn  0.00000000  0.00000000  1.00000000
    vn  0.00000000  0.00000000  1.00000000
    
    g the_L
    usemtl default
    f 2/6/2 5/1/5 4/2/4 1/3/1
    f 3/4/3 6/5/6 5/1/5 2/6/2
    f 5/1/5 8/7/8 7/8/7 4/2/4

    Cut-&-paste the above into a plain text editor, save it as an .obj file, and import that into DS at Hexagon scale.
    Post edited by merc-daz3d_c669b168a9 on
  • edited October 2012

    Sub-Surface Scattering

    After a few months of occasional attempts at using Sub-Surface Scattering, I finally got around to setting up a simplified experimental rig, to try to isolate what some of the different settings actually do.

    First off, credit goes to RawArt for providing some good starting settings. It sure helps to have some kind of effect visible before you start spinning dials at random... 8^j* I also snagged a copy of Dimension Theory's Interjection product during last month's PA sale, which saved me the truckload of hours it would have taken to construct my own SSS maps for the 4th gen figures--- and provided another set of UberSurface settings to experiment with.

    Attached are a sample render of "Four Levitating Bowls and a Bald Vicki," plus the goofy SSS test map I used for the surfaces on the bowls. (If you want to use the latter for your own experiments, click through to get the original version without the extra level of JPEGgery introduced by the forum previewer code.) All four bowls use the same starting UberSurface settings, with different sections shut off.

    The bottom bowl has no Ambient and no SSS active. The Diffuse is at 100%--- more on that in a bit.

    The left bowl (viewer's left) has Ambient on but still no SSS, with Diffuse at 95%.

    The right bowl has SSS on, no Ambient, and Diffuse at 95%.

    Finally, the top bowl (viewer's left) has Ambient on, SSS on, and Diffuse at 95%.

    Next up, dissecting the settings...

    SSS.jpg
    512 x 512 - 21K
    SSS-a1.png
    960 x 960 - 859K
    Post edited by merc-daz3d_c669b168a9 on
  • edited October 2012

    On the "test bowls," I left most of the UberSurface settings at their defaults--- in the attached composited screencap, a bunch of the subheadings have been collapsed. Those values are as the base UberSurface load initialized them. Proceeding from the top,,,

    The Diffuse color is a jpeg, medium beige, with a little multi-color Gaussian noise added, and multiplied by a peachy [255,238,221] off-white. It's a nice utility skintone for when I want to isolate the effects of settings--- the painted-in details in a good skin texture make those harder to pick out. Why 95% strength? Because in early experiments, highlights were getting "blown out" (i.e., kinda over-exposed looking) when I added in Ambient and SSS. Depending on the skintone/lighting/glossiness you're using, that dialing back may not be necessary.

    There's just a smidgen of texture in the Bump channel: a little Gaussian noise again.

    Went a little bit shiny with the Specular, for a slight ceramic effect on the bowls. On skin, the UberSurface defaults are pretty plausible, but this is something you'd adjust according to the needs of the image.

    This is a fairly bright & saturated Ambient color, but it's dialed way down to 4.2%. It's also applied only in the areas designated by my SSS map. Again, you have a lot of creative leeway here, depending on the skintone and desired effect.

    Velvet is used here to emulate looking through a semi-transparent ceramic glaze layer near the edges of the object, where the surfaces are almost turned away from the viewer. So you'd be looking through it at a shallower and shallower angle as you approach the edge, and therefore a thicker and thicker amount of the glaze. It's a similar idea with the fine hairs on human skin. Lots of leeway for experimentation here.

    And finally, the main event: Subsurface Scattering.

    For its color, I used that medium beige jpeg again, this time multiplied by a traditional pink--- that "subcutaneous blood" tinge that skin SSS is meant to emulate. Went pretty high with the Strength here, racking it up to 75%. And it's applied where my SSS map specifies, naturally.

    Searching around, I found refractive index numbers for skin (and water, responsible for a large part of skin's optical properties) quoted ranging from 1.3 to 1.5, depending on bunch of factors--- notably, the wavelength of light involved. I chose a kinda middle of the road value; for skin, the 1.3 to 1.5 range of settings doesn't seem to cause wild changes in the final effect.

    The Scale setting, however, was a surprise. I've read various descriptions of it as determining how far the light penetrates the object--- which is true enough, I suppose. But I find it more useful to think of it as affecting how much blur is in the final SSS effect, as seen in the actual render. For a larger object, such as a giant creature or humanoid, you'd use a larger Scale value to soften the edges, to be "in scale" (nyuk nyuk) with that larger being. And you'd go smaller for smaller figures, naturally. The ratio is nicely linear, fortunately.

    (When I first started my SSS experiments, I had the Scale value way too high, which caused the SSS effect to blur into imperceptibility. Sheesh!)

    Group? I have no idea yet what this is actually used for. I set it to a plausible integer and then ignore it. 8^j*
    [Update!] There's a thread explaining this very slider. Short version: you put surfaces in a group to have them calculated together as a unit, AND to avoid them getting interference from a different group. For example, group all the skin zones as one group, and group all the mouth surfaces in a different group--- and maybe, just maybe, avoid what Rawn calls "Lava Mouth." More experimentation on this to follow.

    Shading Rate is a quality setting. Unlike the Uber lights, higher values mean lower quality, less computation load, and faster renders. On this relatively simple image, the delta between rendering at 128 and rendering at 16 was only about a 2% increase in render time. Pushing to 4 took 11.5% longer than the render at 128. Visually, the higher quality translates to a smaller blur and more intensity in the SSS effect. The default of 32 is probably a good tradeoff point; I couldn't see a significant difference between the the renders at 16 and 4.

    SSS-shrate.png
    1080 x 720 - 425K
    SSSettings.gif
    330 x 1800 - 32K
    Post edited by merc-daz3d_c669b168a9 on
  • edited October 2012

    The eagerly sought-after Ear Glow !

    Note that this is SSS alone, without any boost from Ambient. For my purposes, I rather prefer this approach.

    SSS-e1_016.png
    960 x 960 - 818K
    Post edited by merc-daz3d_c669b168a9 on
  • edited December 1969

    Here's a look at the test bowls from the shady side, while Vicki takes a break. Topmost is SSS+Ambient; leftward, SSS alone; rightward, Ambient alone; bottom, none of the above.

    Note how the SSS by itself responds to the availability of light. Where that bowl's curvature causes a contour shadow on the outside, the glowy fuzzy SSS pattern on the inside fades out. The same occurs within the shadow cast by the top bowl.

    Ambient effects, on the other hand (bowl), glow regardless of whether light is hitting the surface or not. Also, they don't look very "scattered."

    Overall, if I'm faking an effect of scattered light, I'd prefer that the method pay attention to how much light is available. When the lighting of a scene is bright and sunny with loads of ambient light from all directions, the Ambient substitute will do, provided the SSS map is already fuzzy. When the lighting is more chiaroscuro, it looks like I'll be tuning the SSS effect to be sure it's perceptible.

    Still have to figure out how to produce an exaggerated waxwork effect within DS, though... ;-P

    SSS-r1_016.png
    960 x 960 - 764K
  • vwranglervwrangler Posts: 4,887
    edited October 2012

    alanscape said:
    Group? I have no idea yet what this is actually used for. I set it to a plausible integer and then ignore it. 8^j*
    [Update!] There's a thread explaining this very slider. Short version: you put surfaces in a group to have them calculated together as a unit, AND to avoid them getting interference from a different group. For example, group all the skin zones as one group, and group all the mouth surfaces in a different group--- and maybe, just maybe, avoid what Rawn calls "Lava Mouth." More experimentation on this to follow.

    Sorry to interrupt, and I hope this is helpful.

    With Ubersurface2 and Daz Studio, at least, you can avoid or at least sharply decrease "lava mouth" by turning the Translucency strength on the mouth textures down -- teeth, gums, tongue, and whatever the other one I can't remember right now is (I don't have Studio on this workstation at the moment).

    "Lava Mouth" is largely caused by translucency making light glow through the skin, as far as I can tell. Turning Translucency down doesn't necessarily seem to work as well with Interjection; there's something very different about the way the two shaders seem to work -- I think in part because Interjection actually uses Ambient for part of its effect, and Ubersurface2 defaults to doing whatever the mat settings are telling it to do. Even when you allow Ubersurface2 to replace mat settings instead of ignoring them, it doesn't generally turn Ambient on, at least not in the settings I've tried on human textures.You don't need to touch the external textures for the head to get rid of the effect, and you don't necessarily need to assign the textures to a separate group. (No, it does not make logical sense that turning down translucency on textures that aren't structurally external -- and therefore the ones that translucency should be affecting the least -- works, but it does. Logically, if the external head structure isn't translucent, but the internal mouth structure is, you wouldn't see anything until the character opened their mouth. This is not the way Studio works. No idea why.)

    (Honestly, since you can -- and, actually, must -- work with textures separately within the same group, I don't quite understand what the Group setting is doing there. Even when you assign given textures to a specific group, you still need to deal with each texture separately. I've read the thread you linked, but I think I'm just missing something about how Group works.)

    Thank you for going through all this; it's been really informative about how the shaders work and why.

    Post edited by vwrangler on
  • edited October 2012

    An "interruption"? On the contrary--- I'm gratified (and a little relieved) to hear that someone else is reading this thread. :) Although it's a valid way to make notes for my own future reference, I suppose. Still, one has hopes, y'know...

    Regarding grouping versus having to deal with textures/zones separately: As I read that thread, I don't think the Subsurface Group stuff is for helping me, as an end user, to manipulate a bunch of material zones as a unit. I think it's just a directive for the shader code, telling it to calculate some areas together, and some separately. ReDave's point about "no boundary between different material zones that belong to the same group" is a key concept, I believe.

    To test this idea, I'd set up two adjacent material zones in an object with the same general SSS settings, and place a bright area of SSS map in one of the zones, right next to the boundary.

    - If I assign both material zones to the same Subsurface Group, the SSS fuzzy glow should "bleed" across the boundary.
    - If I assign each zone to its own unique Subsurface Group, the SSS fuzzy glow should stop at the border.

    I'll go try this and post the results.

    On the glowy mouth syndrome: I vaguely recall stumbling into this in early efforts, but I didn't pay much attention--- I think I just set the mouthparts' shaders back to "DAZ Studio Default" and carried on with whatever was occupying my interest at the time. If I can recreate this condition intentionally, I'll try your suggestion. Thanks!

    cheers
    Alan

    Post edited by merc-daz3d_c669b168a9 on
  • edited December 1969

    Yep, that's how it works. :-)

    The bauble farther away from camera has both material zones assigned to the same Subsurface Group, while each material in the nearer bauble is assigned to its own separate Subsurface Group.

    I also varied the Diffuse color slightly, to make the boundary more distinguishable, and tweaked the (Basic Primary) Specular settings to taste. Apart from those and the SSS settings, everything else is at UberSurface default values--- mostly "Off," notably including Translucency and Ambient.

    SSS-g2_016.png
    960 x 960 - 817K
  • vwranglervwrangler Posts: 4,887
    edited December 1969

    alanscape said:
    Yep, that's how it works. :-)

    The bauble farther away from camera has both material zones assigned to the same Subsurface Group, while each material in the nearer bauble is assigned to its own separate Subsurface Group.

    I also varied the Diffuse color slightly, to make the boundary more distinguishable, and tweaked the (Basic Primary) Specular settings to taste. Apart from those and the SSS settings, everything else is at UberSurface default values--- mostly "Off," notably including Translucency and Ambient.


    Ah, OK. so probably not something you'd use much on a human texture unless you were trying to do something like a tan line; you could assign SkinHip to its own group and get that old-school Coppertone commercial look while keeping somewhat the same settings as the surrounding textures. It's nice to see how that works in practice.

    On the glowy mouth syndrome: I vaguely recall stumbling into this in early efforts, but I didn't pay much attention--- I think I just set the mouthparts' shaders back to "DAZ Studio Default" and carried on with whatever was occupying my interest at the time. If I can recreate this condition intentionally, I'll try your suggestion. Thanks!

    If you start using Interjection at its default strengths, you'll see it. In that case, however, it's largely but not entirely due to ambient settings, so turning down translucency doesn't work. Ambient seems to be part of what needs tweaking to get that waxy look you mentioned, by the by.

    I don't tend to see lava mouth with EHSS/Ubersurface2, but that's also in part because when I use Ubersurface on human characters, I turn down translucency on mouth textures so that it's never above 10%, and usually in the 6-8% range. That may be overcompensating, but the first time I ran into the issue, it took forever to figure things out.

  • edited December 1969

    vwrangler said:
    Ah, OK. so probably not something you'd use much on a human texture unless you were trying to do something like a tan line; you could assign SkinHip to its own group and get that old-school Coppertone commercial look while keeping somewhat the same settings as the surrounding textures. It's nice to see how that works in practice.

    Or the "second skin" clothing technique, now somewhat fallen out of use--- see attached. 8^D* In this case, the DAZ Studio Default shader sufficed for Vicki's "bicycle shorts," but now I have the option of using one of the UberSurface family of shaders.

    By the way, those hours in Photoshop that I avoided by purchasing Interjection? Spent 'em making simple skinhip displacement maps for the 3rd and 4th generation figures... 8^j*

    vwrangler said:
    If you start using Interjection at its default strengths, you'll see it. In that case, however, it's largely but not entirely due to ambient settings, so turning down translucency doesn't work. Ambient seems to be part of what needs tweaking to get that waxy look you mentioned, by the by.

    Noted, thanks. I suspect the weird glow thing may also show up more clearly in different lighting than the overcast-ish setup I've used in this series. (One muted UberEnvironment2 light providing ambient & occlusion effects, plus one soft distant light.)

    I don't tend to see lava mouth with EHSS/Ubersurface2, but that's also in part because when I use Ubersurface on human characters, I turn down translucency on mouth textures so that it's never above 10%, and usually in the 6-8% range. That may be overcompensating, but the first time I ran into the issue, it took forever to figure things out.

    Thanks! That tip has already saved me a bunch of hours: translucency certainly wouldn't have been the first suspect I'd have looked at...

    SSS-q1_016.png
    960 x 960 - 905K
  • 3dLux3dLux Posts: 1,231
    edited December 1969

    Thank you so much for the comment, Alan :-)

    Will reply in greater depth in my own thread but wanted to let you know I started reading this and thank you so much for sharing this information :-)

  • edited November 2012

    Cool--- glad to be of help! Feel free to chime in here with questions, suggestions, and suchlike, as I fumble around in the dark--- er, make that, fumble around with a

    Starter UberEnvironment 2 Lighting Rig . . . [Yay, new page!]

    First, a pointer to my favorite thread on the topic, adamr001's "Learning UberEnvironment 2..." Very useful.
    [EDIT] Also see a Dreamlight3D sample tutorial/introduction for UE2.

    Second, a quick textual run-through of some UE2 settings that would be typical of my usage. Your mileage will vary, you'll prioritize different attributes, and I'll even be adjusting them slightly/wildly as I work through test renders here. So stay flexible!

    Basic:

    Intensity - 100%
    Intensity Scale - 100% . . . . . . . For starters. This is a multiplier for the preceding attribute.
    (You might use this for a "noir" effect, to let you leave the first one bright enough so you can see
    your scene in the preview, and then dial this down so the actual render has darker shadows.)
    Color - [255 247 221] . . . . . . . . . I think I want to go just a smidgen warm with this light.
    & OmKitchen_EnvM.jpg . . . From DS4 Pro's Library\Runtime\textures\omnifreaker\Environment folder.
    Environment Mode - Occlusion w/Soft Shadows . . . A good middle choice. Nice effect, but not too computationally expensive.

    Map Controls:

    Saturation - 100%
    Contrast - 100% . . . Starting with defaults here. Similar to functions in an image editor, but here
    they're affecting the color and bright/dark areas of your ambient light pattern.
    This'll make more sense with demo images later.

    Ray Tracing:

    Occlusion Strength - 75% . . . . . . . . How intense or dark you want the Ambient Occlusion shadow effect to be.
    In most scenes I de-intensify it somewhat; this is a good starter value.
    Indirect Lighting Strength - 100% . . . Default. How strong you want the Indirect Lighting effect (bounce light) to be.
    Not used with the two "Ambient Occlusion" modes of UE2.
    [Above 2 notes edited after clarification from Szark-- thx!]
    Occlusion Color - [37 34 43] . . . . . . Something (ANYTHING!) other than that fleshtone-deadening pure black,
    in the Ambient Occlusion shadow effect. Purple is kinda classical. ;^D*
    Occlusion Samples - 96 . . . . . . . . . Affects quality; higher generally means less "freckling" in the A.O. shadows.
    Not terribly computationally expensive, even on my old obsolete PC.
    It's reputed to be better to stick with integer powers of 2 here--- 64, 32, 16, etc.
    96 provides preview renders that I find easier to gauge than 64 does,
    while being faster enough than 128 to be worthwhile.
    [Thanks once more go to Szark for this note.]

    Advanced:

    Shadow Bias - 0.10 . . . . . . . . . . . . Default value. Offsets any cast shadows a bit. (!) Yeah, bizarre, but it's needed for virtual lights.
    Otherwise you get shadows sticking through what's casting them, or some such weirdness.
    Shading Rate - 8 . . . . . . . . . . . . . . Another quality setting; lower number, better quality, longer render time.
    Max Error - 0.10 . . . . . . . . . . . . . . And another quality setting; lower number, better quality, longer render time.
    Maximum Trace Distance - 500 . . . Default value. How close two surfaces have to be to cause A.O. shadows on each other.


    Phew! Off to set up a test scene...

    Post edited by merc-daz3d_c669b168a9 on
  • edited October 2012

    Okay, so here's a render with just an UberEnvironment light active. I reused an existing scene, moved a few props around, added a couple of others, and then went through with a virtual spraypaint can, turning most of the surfaces off-white. For some reason, that last part was ridiculously fun...

    Changes to the settings quoted above, mostly for exaggerated effects:

    Turned the Intensity Scale down to 62.5%, to avoid an overexposed effect.
    The environment map is OmKHPark_EnvM.jpg, from the same location.
    (The kitchen didn't have much color variation--- brown floor, mostly.)
    Cranked the map Saturation up to 125%, to exaggerate the color of the simulated Ambient light.
    Turned Occlusion Strength down to 75%, for dimmer shadows.
    Turned Indirect Lighting Strength up to 125%, to exaggerate the color of the Ambient light. [Echo in here?]

    The thing hovering behind her left shoulder is the EnvironmentSphere, which loads in parented to the UberEnvironment2 light. Normally it's huge--- the idea being to show you the simulated environment that's bouncing all this light inward. Personally, I find it more useful to shrink it down and look at it from the outside--- that way, if I turn the UE2 light so that, say, a red area of this preview sphere is facing the camera, then I know that surfaces in the scene that are facing the camera will receive reddish ambient light. If I look at it from the inside, I'm looking at the light colors for stuff facing AWAY from the camera. Not as useful, IMO.

    It also took a bit of finagling to get the EnvironmentSphere to show up in the render--- it's set up not to. :)

    So anyway, if you click through to the (slightly) larger and (much) clearer original render, you can see that upward-facing surfaces are receiving blue ambient light from the virtual sky, while downward-facing (and sideways) surfaces are picking up the green of the virtual lawn.

    Next test (probably tomorrow): add an ordinary DAZ Studio spotlight.

    Alan

    testUE2_A1.png
    720 x 960 - 882K
    Post edited by merc-daz3d_c669b168a9 on
  • JaderailJaderail Posts: 0
    edited December 1969

    Okay, now that I understood. Sphere image = Lighting. I got a Click moment. Thank You. Very Simple post (mine) but It covers the Idea I think.

  • edited December 1969

    You're entirely welcome! And yes, you do Brief Yet Clear very well. Whereas I keep giving myself awkward reminders on why I'm not a writer... %-P

  • edited November 2012

    Here's the scene with an overhead(-ish) spotlight switched on.

    The spotlight is using a cool [221 238 255] color, in keeping with the color scheme of the OmKHPark_EnvM.jpg environment map. Its intensity is a mere 37.5%, and the UE2 light's Intensity Scale multiplier is also lowered, to 50%. That's due to the fact that, on my first try, much of the white area was "blown out." Have I mentioned that there's a LOT of white area in this set? I still managed to blow out the highlights a bit on the second try--- however, that seemed to harmonize with the illicitly displayed EnvironmentSphere, so I left it like that.

    This is my go-to lighting rig--- an UberEnvironment2 set to do image-based Ambient Occlusion, plus one key light--- when starting to light a scene. From here, I can add elaborations, but this gets a big hunk of the heavy lifting done in a 3Delight render, for not much processing-time penalty. (And given the low probability of faster hardware in my immediate future, this is significant.) If you flip between this render and the previous one, you can see that the modeling (in the lighting sense of the word) of forms in the shadow areas is due to the UE2 light. Much nicer than an inky void under the tabletop. (Unless that's what the image calls for, of course.)

    Another UE2 tip that's perhaps overly obvious, but still worth mentioning: you can rotate the light, to change how the image-based simulated Ambient light falls on your scene. Here it's rotated -30 on the Y axis, to bring the sunny hotspot to the front. I'll be back with a quick demo render or two in a bit, to show what silliness this allows...

    testUE2_A2.png
    720 x 960 - 864K
    Post edited by merc-daz3d_c669b168a9 on
  • edited October 2012

    Let's see... There's a dark green leafy canopy overhead, and a nearby swimming pool is reflecting some blue light upward. Yeah, that must be it... ;-P

    (UE2 rotations: X 90, Y -72, Z 120.)

    testUE2_A3.png
    720 x 960 - 812K
    Post edited by merc-daz3d_c669b168a9 on
  • edited November 2012

    Okay, I'll stop soon. :P

    Venturing perilously close to psychedelic territory, here are a couple of renders using the lighting setup from my contribution to the Halloween Freebies Challenge. Still one UE2 and one spotlight. The second one (if I've got my attachments in a row) is even shot through the same camera.

    Besides being silly, this also demonstrates how the surface settings affect the mood achievable by the lighting. All that clinical white is a lot less gothic than a dark-ish, heath-colored ground plane...

    The environment map image is OmCornellBox_EnvM.jpg; UE2 rotations are X -45, Y -54, and Z 18; Contrast (under Map Controls) is down to 75%; Occlusion Strength is up to 87.5%, for more intense (darker) occlusion shadows.

    testUE2_B1.png
    720 x 960 - 834K
    testUE2_B1h.png
    720 x 960 - 788K
    Post edited by merc-daz3d_c669b168a9 on
  • edited May 2013

    One more comparison shot. At the insistence of the image attachment feature here, on the left is "Indirect Lighting w/Soft Shadows," and on the right is "Occlusion w/Soft Shadows." The intensities of both the UE2 light and the spotlight on the Occlusion render are 50%, as opposed to 41.7% on the Indirect Lighting render--- that extra brightness was needed to get the overall values roughly the same.

    Basically, with the Indirect Lighting setting, UE2 does all the math it does for the Occlusion setting, plus it calculates bounce light. While a detectable trace of the green and the orange of those two bowls have thereby been reflected into their respective shadows, by far the dominant difference between the two renders is the upward bounce from all that white. It's especially visible in the yellow portion of the abstract sculpture, in its contour shadow.

    Definitely improved plausibility, but not without its cost: the render times here went from under 5 minutes to nearly 2 hours. :exclaim:

    testUE2_C2.png
    720 x 960 - 856K
    testUE2_C1e.png
    720 x 960 - 789K
    Post edited by merc-daz3d_c669b168a9 on
  • SzarkSzark Posts: 10,634
    edited November 2012

    Just to clairify a few things.

    Having the Indirect Lighting Strength at 125% without using Indirect Lighting functuon in UE2 is a waste of time. You can set to to 1000% but without IDL selected it isn't going to do anything.

    Saturation effects the light colour of the HDRI map produces. So if the light colour is too strong then lowering it will lessen the colour.
    Occlusion Strength is better at 75%
    Occlusion Samples: best to keep at either 64 or 128. I read somewhere that we should stick to the math that 3Delight uses. 8,16,32,64,128 you see the pattern. I am not sure if this has changed with the new 3Delight Render engine we have now in DS4.5.1.6

    Post edited by Szark on
  • edited November 2012

    Szark said:
    Just to clairify a few things.

    Having the Indirect Lighting Strength at 125% without using Indirect Lighting functuon in UE2 is a waste of time. You can set to to 1000% but without IDL selected it isn't going to do anything.

    Saturation effects the light colour of the HDRI map produces. So if the light colour is too strong then lowering it will lessen the colour.
    Occlusion Strength is better at 75%
    Occlusion Samples: best to keep at either 64 or 128. I read somewhere that we should stick to the math that 3Delight uses. 8,16,32,64,128 you see the pattern. I am not sure if this has changed with the new 3Delight Render engine we have now in DS4.5.1.6

    Nice clarification & expansion-- thanks!

    Yeah, now that you point it out, the lexical connection between IDL & IDL Strength seems kinda obvious. I'll run a couple of quick tests to verify, but I expect you're correct. [EDIT: Yes, it checks out-- correction on its way...]

    Yep, that observation agrees with my experience with Saturation. More often I'm turning it up for exaggerated effect. :D

    Occlusion Strength at 75% matches up with my followup post, immediately after the text dump. Checked a few of my old scenes, and although it's not always that exact value, I do tend to attenuate it some. Good point.

    The integer powers of 2 thing is interesting. I seem to recall seeing some visible decrease in speckling as I crank it up through the intermediate values (which would be fractional powers of 2), but there's also mathematical efficiency to consider. I wonder if the render times take a hit with those-- i.e., it's possible that there's logic in the code to use more efficient bit-shift math when the Samples value is an integer power of 2.

    If you get a chance, could you delete the quote from your post? I expect I'll have a few notes to add to the original. :roll:

    Post edited by merc-daz3d_c669b168a9 on
  • SzarkSzark Posts: 10,634
    edited December 1969

    Quote Deleted

    The integer (nice word couldn't think of it myself) I am not 100% sure of this so I need to ask the more geekish CV's. :)

    I am so glad you took this in the spirit it was given.

    I have noticed a few things about Ubersurface too that needs a bit more clarification but more on that later.It is getting close to bed time for me.

  • JaderailJaderail Posts: 0
    edited November 2012

    Powers of two work better because the PC is based on the Binary system. All Powers of two are BASE powers that the Processors can read without doing any math. That was my understanding when I took Microprocessor design at R.E.T.S. twenty odd years ago. Now that the Systems can read 128 bits and more in one go I'm not sure that still applies. I was in it at 8 bit systems.

    Just my two cents.

    Post edited by Jaderail on
  • SzarkSzark Posts: 10,634
    edited December 1969

    Interesting Jad. I wonder if that is still the case. I have asked in our corner of the forum about this. We need to give it a few days for other CV's to see it.

  • edited December 1969

    I just did a rough, unscientific set of time trials--- being in the middle of accreting a new scene out of pieces of old ones, I had a reasonably simple (but not too simple) surreal jumble of props & one figure, with a fair number of surfaces occluding each other. So I did a series of quick renders, stepping the Occlusion Sample slider from 16 to 128, in increments of 16.

    Note that this left a bunch of variables uncontrolled, especially available memory as render windows piled up. On the other hand, they're small renders, and this situation is similar to my ordinary working conditions, so I'm not too concerned by this for a quick test.

    Times (approx): 46s ; 1m 1s ; 1m 19s ; 1m 31s ; 1m 47s ; 2m 2s ; 2m 17s ; 2m 34s
    Deltas (approx): 15s 18s 12s 16s 15s 15s 17s

    Despite that slight dip to a 12 seconds delta when going from 48 to 64, this is close enough to a linear progression that I feel comfortable in assuming that there's not a big hit (if any) using values that are not integer powers of 2. Heck, Omnifreaker could have programmed his shader/light code so this slider went in integers from 1 to 7, and then used those values as exponents. Since, however, the intermediate values were made available, I'm guessing that they're there to be used, if desired.

    A proper test would require trying many more scenes, preferably from multiple authors, and many more intermediate values. Which would be way beyond the scope of a series of posts based on, "Hey, here are some starter values that give me a reasonable result, so if you're stuck on UE2, or not even trying it, here's a place you can start, and then tweak settings to your own taste."

    So, I think I'll reinstate my 96, while keeping the new note beneath it. It's faster than 128, but still "de-freckled" enough, compared to 64, to allow me to judge how dark-to-medium-light surfaces (like skintones) are going to respond in a final render.

    Good discussion, folks! I do appreciate the help in livening the thread up, and coming up with interesting things to try. Thanks!

    g'night
    Alan

  • SzarkSzark Posts: 10,634
    edited December 1969

    Looks like for now I will not be able to confirm the interger settings for the Occussion Smaples. I will have to go further a field to find the correct information. I did try but hit a stone wall for now.

Sign In or Register to comment.