UberEnvironment2 - Can Anybody Explain The Result Of This Simple Test? [UE2 problems/fixes]

Takeo.Kensei

Horo said:

Takeo.Kensei said:

@Millighost : sent you a PM. Did you get it?

No! Thank you for asking. I've checked my PM inbox, there's nothing.

Horo the PM was addressed at Millighost. It is about the Bug with the Identity matrix transform he mentioned. I did some tests and from my point of view the Identity transformation doesn't do anything. The reason behind it is that I don't think the UE light is doing the coordinate transform I would have awaited in order to get it correct versus the DS coordinate system. And in fact, it is written in the doc that "Rotating/Translating the light will not change the rendered image. Rotate the scene to get the desired placement of the Environment lighting. " (see at the bottom http://www.omnifreaker.com/index.php?title=UberEnvironment2)

So there is no way to change the UE light from just using the sliders of the light. Which means the Identity transform doesn't do anything too. We have to attach the light to an object (a null object will do ) and rotate the object to rotate the UE.

Horo

@Takeo.Kensei - thank you. Now you got me baffled. Looking at the link provided I see in the Users Guide, What's new in UberEnvironment2 as the first item: Rotating the light will now affect light direction.

And that is what I see. Though in my tests, I set 6 cameras to look at each side N, E, W, S zenith and nadir. If only the UE2 is selected, not the group, the light can be rotated X, Y and Z.

Takeo.Kensei

Horo said:

@Takeo.Kensei - thank you. Now you got me baffled. Looking at the link provided I see in the Users Guide, What's new in UberEnvironment2 as the first item: Rotating the light will now affect light direction.

And that is what I see. Though in my tests, I set 6 cameras to look at each side N, E, W, S zenith and nadir. If only the UE2 is selected, not the group, the light can be rotated X, Y and Z.

Lol I'm baffled too. Must be too stu..d these days or simply tired
Done the test again and now I can rotate the UE light. Sorry don't know what I did wrong when I tested

But I still confirm that deleting all "Identity" entry in the RIB file doesn't change any of my rendering

I just wanted somebody else to confirm that point

millighost

Takeo.Kensei said:

Horo said:

Takeo.Kensei said:

@Millighost : sent you a PM. Did you get it?
No! Thank you for asking. I've checked my PM inbox, there's nothing.

Horo the PM was addressed at Millighost. It is about the Bug with the Identity matrix transform he mentioned. I did some tests and from my point of view the Identity transformation doesn't do anything. The reason behind it is that I don't think the UE light is doing the coordinate transform I would have awaited in order to get it correct versus the DS coordinate system. And in fact, it is written in the doc that "Rotating/Translating the light will not change the rendered image. Rotate the scene to get the desired placement of the Environment lighting. " (see at the bottom http://www.omnifreaker.com/index.php?title=UberEnvironment2)

Of course, you are right about the Identity. In my simple-mindedness i overeagerly assumed that the Identity was in place of the Scaling that the light should have, but this is not the case. After a bit experimenting i would say that DAZ Studio completely ignores the scale setting for any light. I can scale the lights all the way i want, it will not change anything in the output, even for spotlights (where it could be somewhat useful). Parenting the light to an object does not help, though, DAZ Studio seems to remove all parent-child relations of the object when sending them to the renderer.

So there is no way to change the UE light from just using the sliders of the light. Which means the Identity transform doesn't do anything too. We have to attach the light to an object (a null object will do ) and rotate the object to rotate the UE.

Rotation and translation on the other hand, are applied to the lights (and to the UberEnv2, too). Translation is irrelevant for the UberEnv2, but Rotation works as expected. I.e. rotating the UberEnv light 180 degrees around any axis will make the front side appear on the back and vice versa.

EDIT: Ah yes, redundant information; should have read the last two posts first...

millighost

Horo said:

@millighost - thank you for dropping in here, your insights are very much appreciated.

The image you took is an LDRI JPG, not an HDRI. I can always make available any of my test HDRIs for free download if there's an interest. However, I've also noticed that there is essentially no difference whether an HDRI or an LDRI is used for the colour test. Never mind washed-out colours, as long as they are correct, I don't care at this stage. I have no idea where in 3Delight I could switch on or off gamma. The HDRIs I use are always linear, they are true 96-bit TIFFs (or RGBE radiance HDRs).

And, of course, I use truly spherically projected images, not just some 2:1 aspect ratio things. The TIFF tags 33302 and 33303 are neither standard nor registered private tags and can only have a relevance in a particular program. As for valid TIFF tags, see
www.digitalpreservation.gov/formats/content/tiff_tags.shtml. There is no program I know of that creates these tags. I don't know what a TDL file is. As you say, it's 3Delight variant of TIFF. How can one extract it?

Not sure about the "officiality" of the 3330x tags. I found them in the libtiff headers, where it says "tags 33300-33309 are private tags registered to Pixar", so i assume it is more or less semi-official. At least it is a kind of de-facto standard for textures, because renderman and aqsis use them also.
Apart from that a tdl file is just a normal TIFF file that is named with a tdl suffix (all the 3delight files have a suffix with a "dl"). They are created with the tdlmake utility when when DAZStudio does its "Optimizing images". That not only converts the texture to TIFF, but also generates MIPMAPs and some tags that 3delight can make use of. You can get to them by exporting the RIB file (in the render settings: Render To File) and then looking into the output (with a bit of guesswork, because they are named rather uninspiredly like "d1.tdl", "d2.tdl" and so on.

UE2 takes a 96-bit TIFF either compressed or not for the light. It wants it in the spherical projection and maps it around an invisible sphere. How exactly it is mapped on the sphere, I don't know, and this is part of all these tedious experiments to find out. If the spherical HDRI panorama is not correctly mapped on the sphere, we get funny colours and I think we all absolutely agree here.

if the center of the environment map is longitude and latitude = 0, the mapping is:
x = cos (longitude) * cos (latitude)
y = sin (longitude) * cos (latitude)
z = sin (latitude)
that makes the latitude move from the front to the back, and the center of the environment map the direction of the x-axis. The right half of the map is the up-direction, the left the down-direction. See below for an example. This is for uberenv2 and most standard functions used in shaders. But unfortunately different shaders do it differently, other render engines do it differently, and i am not so sure that every light preset you can find in the shop here is created by someone who exactly knew what he or she was doing. More common than this mapping however is something with the latitude running from downwards to upwards.

Whether point or area light sources are created from the loaded HDRI or not is not relevant but must be known by the render engine in order to be able to interpret what it finds out from its feeler rays it sends out.

Creating distinctive light sources from the HDRI loaded has the advantage that there is a way to control quality and speed by the number of lights created - or the light source resolution; this pixel is bright, the one next to it dark. Each bright pixel has the same brightness. The nearer those pixels are together, the brighter the light source is considered.

The disadvantage is that there are no parts that fade out or mix with adjacent colours. We can see this in Bryce because this results in shadow banding, even with 4096 light sources. If 3Delight scans the HDRI backdrop, it must be able to interpret the brightness of each pixel in the HDRI. This is very time consuming but should give the best result. If only a coarse scan is made and the rest around it guessed, speed increases and accuracy drops. But accuracy only drops if the HDRI is high resolution as mandatory for RNL (rendering with natural light), resolution doesn't drop noticeably if a specular convolved HDRI is used, the less the smaller Phong exponent used and least at exponent 1, which results in a diffuse convolved HDRI.

As far as i can tell, the main difference between UberEnv2 and an area light is how the samples are processed. With an area light, the map is sampled 4096 times (the virtual "light sources" one could say) and for each of the 4096 samples the interaction with the object surface is calculated; after that the resulting 4096 values are usually averaged. With UberEnv2 the 4096 samples are averaged first, and then applied to the object's surface. Because it does not make much sense to average e.g. light directions (which would be needed for specular lighting), it always gives diffuse lighting. The non-diffuse aspects cannot be done with UberEnv2.

What I want is to render with natural light in DS like I can in Bryce and Octane (and in Carrara, though I performed only preliminary tests, being the Carrara dummy I am). I could make RNL work in DS for 2 HDRIs up to now. Using the same method doesn't work with the colour cube. What roughly works with the colour cube doesn't work with an outdoor and indoor HDRI.

That's why I say UE2 (or UE2 with 3Delight) doesn't work consistently. It may also well be that I want something out of UE2 for which it was never made. All tests I have now performed left me baffled, each one worked in Bryce.

To say something nice, using an uniformly white HDRI (dynamic range 1:1) gives correct results using a sphere to be lit by it or a cube. Moving down intensity results in an even uniform grey, brightness can be nicely controlled. No complaints here.

Here is an example i created with UberEnv2; i used a skymap from cgskies.com (sky no. 0225).
1. I added it as a skymap to a simple scene containing only a white square to create a reflection map in lat/long format using luxrender. This is particularly easy to do with luxrender, because it supports creation of environment maps out of the box, no conversion with mirror balls, six cube-cameras etc needed. The resulting map is shown in the upper half of the illustration. Note that the sky is on the right side of the map.

2. In the 3delight scene i loaded that map into the uberenv2 (no rotations or so necessary), added the white square and a sphere. For the sphere i used the shinymetal shader that comes with 3delight, and i applied the envmap as a reflection map to it. The nice thing about this format is, that i need only this one map. The resulting render is in the lower left.

3. For comparison i rendered this same scene with luxrender using a metal ball for the sphere (i often use luxrender as a reference because i find it to be very exact in what it is doing and rather easy to use, not much unlike you use bryce i think). All in all i think the lighting, in particular the strength of the shadow of the sphere on the plane are very close.

Of course the 3delight image lacks the caustics on the square where the sphere touches it. The reflection on the sphere is also slightly different, because the reflection map is rendered from the center of the sphere, not from the surface, and there is no reflection of the sphere's shadow, because there was no sphere when i created the reflection/environment map, but this is not the UberEnv's fault.

By the way, I'm using AsTiffTagViewer if I'm not just looking at the hex dump of the IFD.

3dcheapskate

millighost - your attached images seem to match the conclusion I came to in posts 50/51. Your first image, with the sky on the right, is the same as my 4.jpg and 5.tif in the second attached image of post 51. As far as my own tests are concerned this seemed to resolve ALL the problems I could see.

Edit 2: Since post 50/51 I've been unable to reproduce for myself any of the pole offset problems or shadow misalignment problems. But from what Horo and Takeo say these issues appear to be inconsistent, and dependant on the particular HDRI image. Since all my images originate from LDRI JPG sources it's perhaps not surprising that I don't see these effects?

Edit: Regarding the way UE2 samples the HDRI - I really don't understand the discussion on this, it's way over my head. But something seems a bit odd to me - omnifreaker's UE2 wiki page states about a third of the way down:

Environment Mode

One of the most critical settings for UberEnvironment2 is the Environment Mode

Direction Shadows can only be achieved by using an EnvironmentMap. If the Light Color is not mapped, the direction of the light source is uniform and so the shadows will be as well. Directional Shadows are achieved by examining the HDR and sampling the map where the map has the highest values.

Is this "...sampling the map where the map has the highest values..." at the root of Horo's problem with shadows? Reading about the '4096 samples' in millighost's post I'd assumed they would be in a 64 x 64 grid ?

3dcheapskate

I've just realized that using red, green, blue, cyan, magenta and yellow for the colour-spots test image may add to the confusion when used to illuminate a sphere - the red, magenta, and yellow spots all have peak red, and with the convolution this will make it appear that the peak red illumination comes from some point between the three. Etc...

If I open Horo's colour-spot image in HDRShop and simply run diffuse convolution (Phong exponent = 1) on it I get the attached image (I've expanded the dynamic range in GIMP to make it clearer), a similar sort of effect and I think you can see what I mean (and it's easier than posting half-a-dozen DAZ Studio renders).

To avoid this effect only the three primary colours should be used, and the same primary colour should not appear on two adjacent faces.
(my original six-colour test image was used to determine light direction, so six different colours were necessary, but we're well past that stage now)

Horo

Takeo.Kensei said:

Must be too stu..d these days or simply tired

Sounds more like me, misinterpreting the PM thing ...

A) If only the light of UE2 is selected, the light can be rotated.
B) If only the env sphere is selected, the env sphere can be rotated.
C) If the UE2 group is selected, light end env sphere can be rotated in synch.
This is great and very useful, particularly the common rotation helps to fit backdrop and light into the scene.

@millighost - thanks for pointing out how to set the render options to get the RIB file. The TIFF/TDL/tags questions are answered for me. Those are proprietary tags and the appropriate software can interpret them. Those that cannot interpret them should just ignore them, at least that's the TIFF specs.

The formulas, the same are used for the geocentric elliptic coordinate system used in astronomy to find heavenly bodies. Being in a 3D CG world centre is the same thing. Makes sense. Thanks for the reminder. I used to write programs in the CP/M times but forgot all about it (tempus fugit).

Onmifreaker uses render throttle, not 3Delight. In my DS3 version I only got 3Delight as I have in 4.6 so I have no possibility to check if there would be a difference using different render engines. I wonder how much UE2 and how much 3Delight contribute to the result. I would expect from a render engine to also fire shadow rays.

Your examples with 3Delight and Luxrender with the skydome are instructive. I get the shadow correct and the light mostly correct if I mirror the spherical HDRI panorama then rotate Y and Z by 90°. To get a strong shadow, the main light source (sun) needs to be quite bright. These preparations are done before loading the 96-bit TIFF as light in UE2. I've tested this concept with 9 outdoor and 1 indoor scene and I get satisfactory results. Using test files, like the colour dots, this method fails completely.

This may be due to the way the map is sampled. I'm going to use photographs, not test files, and as long as photographed HDRI panoramas approximate roughly the desired result, I'm fine. Obviously, my expectations in UE2 (together with 3Delight) were set too high and those who developed things may have had other uses in mind than rendering with natural light.

@3dcheapskate - yes, mixed colours confuse interpretation of the results. I've thought that too. But a cube has 6 faces and there are only 3 primary colours. Though I said much farther up that small light sources ought to be used just because of the colour mixing; small light sources may just not work in this IBL implementation. There's a reason why there's always talk about specuar convolving the HDRI.

Szark

DAZ_Spooky said:

Szark said:

Well Spooky this was reported back in the DS3 days...yes it has been broken all that time...I hope the new bug report doesn't get ignored like the old one did.

We never had this kind of detail and DS 3 was from before I was responsible for Software Bugs. Fair comment. I hope this does lead to a fix soon. Sorry to the late reply.

Takeo.Kensei

So are we finished with this? And should we stop there and just report the bug with the envsphere alignment?

Horo

Takeo.Kensei said:

So are we finished with this? And should we stop there and just report the bug with the envsphere alignment?

If you think somebody would care at all, why not. The environment sphere is offset, whether 35° or 20°, I cannot say for sure because I delete it and use spheres I made in Wings3D and exported with Y and Z swapped. I can load a spherical LDRI panorama and it displays correctly without offsets. As far as the light part is concerned, this is a bit more tricky. I found a somewhat acceptable solution (or rather hack) that appears to work consistently. If Studio is to have a proper IBL that can be used for RNL, they ought to start from scratch. In all fairness, UE2 as it is now, can be used for creating ambient light and it does a nice job at it. Just use a specular convolved HDRI with a relatively low dynamic range and add a distant light to create the main light source and the appropriate shadows.

3dcheapskate

(Just back from a short break well away from the internet)

Well, DAZ_Spooky's already given us some hope that it'll be properly looked into this time around once the bug report's filed, and it looks like the discussion about what exactly is going wrong has come to an end.

So who's done/doing the bug report then?
And can they add a new post here with a link to the new bug report so we can all take a look?

Cheers all,
Pete

Horo

3dcheapskate said:

So who's done/doing the bug report then?

I can't file bugs anymore since Mantis is dead, I'm afraid. Honestly, re-thinking the whole concept of IBL in DS would probably be the better solution if there is an interest to make IBL RNL compatible. I think it would be worthwhile, but I may be alone with this idea.

Szark

Bugs are reported via Zendesk but where and how I have no idea.

As for making a new IBL I suggested his a while back, didn't I Takeo. ;) But I don't have what it takes to do it.

mCasual

just a thought

when a cube is in its default orientation, rotations = 0
the face normals are aligned along vectors like [0,0,1] and [1,0,0]
this (the zeros) may sometimes create computation issues
so it's worth a try to do render tests using a cube with, for example, x y z rotations of 0.001 0.003 0.005

Horo

Szark said:

As for making a new IBL I suggested his a while back, didn't I Takeo. ;) But I don't have what it takes to do it.

You're a good man, Pete, so I'm not alone.

Zendesk is no option because it lacks the history. Mantis went back years and with the search function, you could find and assemble all that concerned that particular issue.

@Casual - good idea, I had tried that as well.

Szark

I know Zendesk is IMHO a bad choice for bug reporting.

Takeo.Kensei

Did someone already send a request? If not I'll make one. Just understood what people meant by Zendesk is bad. I agree that is not adapted for bug reporting.

Horo

I haven't and I won't, but I'd appreciate if someone gives it a shot. I'd recommend to point to this thread so that people can get familiarized with the issues. There's more wrong than right.

3dcheapskate

Go ahead Takeo, and include a link to this thread as Horo suggests. And don't forget to post a link to the bug report here too - then I can copy the bug report link to the OP.

Casual said:

just a thought

when a cube is in its default orientation, rotations = 0
the face normals are aligned along vectors like [0,0,1] and [1,0,0]
this (the zeros) may sometimes create computation issues
so it's worth a try to do render tests using a cube with, for example, x y z rotations of 0.001 0.003 0.005

Yes - that's a non-UE2 bug that confuses the matter! There's already a known problem regarding perfectly vertical (up/down facing) normals - not sure if there's already a bug report on that one...

3dcheapskate

So has a new bug report been filed?

Takeo.Kensei

Nope sorry but I'll make one today. I'll include one question I didn't post here

3dcheapskate

Thanks Takeo.
Folks have mentioned that bug-reporting is via ZenDesk (I assume it's via the standard 'Submit A Help Request' - I can't see a separate 'Report Bug' link anywhere) - so does that mean only the person who raises the report gets to see the replies (very odd if that's the case)?

So I guess there must be a separate 'Report Bug' link somewhere? And I think (iirc) that Rob (rbtwhiz) mentioned a bug list accessible via the DAZ website, but I can't find the link...

Takeo.Kensei

I submited it. I think only I can access it. That is why I said that it's not very adapted for bug report

My ticket is here if you wanna try https://helpdaz.zendesk.com/requests/152637

Here is what I wrote

Hi

As the title says, the axis between the uberenvironment and the UE sphere are off. See the thread http://www.daz3d.com/forums/discussion/28358/
As a side remark by doing test it also seems that Light shaders in 3delight have their "up" axis toward Z instead of Y. I don't know if that is normal and would like to know if you have an explanation. I can provide my tests if you need them

Thanks

Horo

Thank you for submitting this issue. Of course, only the one who submitted it can view and modify it (You do not have access to request #152637. It may have been solved or deleted.) which makes sense in a closed private bug reporting system. I'll never understand why Mantis was abandoned.

3dcheapskate

Thanks Takeo - I've added a note at the start of the OP. Also sent a PM to DAZ_Spooky just in case he hasn't spotted it yet! ;o)

Re: Bug reporting in general, I just found this thread from August about the change to Zendesk for bug reporting - http://www.daz3d.com/forums/discussion/26978/ , and a link from there to this post by Rob http://www.daz3d.com/forums/discussion/26880/P90/#408874 summarizing DAZ Studio bug reporting under the new system.

DAZ_Spooky

Takeo.Kensei said:

I submited it. I think only I can access it. That is why I said that it's not very adapted for bug report

My ticket is here if you wanna try https://helpdaz.zendesk.com/requests/152637

Here is what I wrote

Hi

As the title says, the axis between the uberenvironment and the UE sphere are off. See the thread http://www.daz3d.com/forums/discussion/28358/
As a side remark by doing test it also seems that Light shaders in 3delight have their "up" axis toward Z instead of Y. I don't know if that is normal and would like to know if you have an explanation. I can provide my tests if you need them

Thanks

Thanks.
The limitation of not having public Bug Reports is one we are working with Zendesk on. That feature is coming "Zendesk soon."

By the way, just to let you guys know Ketthrove's fix has been approved by our Dev that wrote Shader mixer (Looking for a link to that fix for this thread) as the best way to handle this until we get this fixed.

Szark

Well that is positive Spooky, nice one.

3dcheapskate

...intrigued by "Ketthrove's fix" - Googled ketthrove uberenvironment but couldn't find anything that might be DAZ_Spooky's link...

3dcheapskate

Still waiting for a link to ketthrove's fix...