LW 9.3.1 FG/GI falloff power?

[Red_Oddity]

Okay, this has been driving me nuts all day now (eating away more than a day of my 3 day budget).

Not sure if any users can answer this (hopefully one of the developers can shed some light on this)

We work in a linear workflow (color and textures all in linear RGB color space, light using inverse square distance as falloff), but i have the vague impression LWs FG/GI uses no falloff model when dealing with multiple bounces.
Now, FPrime seems to do inverse square distance on it's GI calculations (seeing the huge differences in shadow areas)

Am i just imagining this? Or should i just switch to Maya on the last day (again).


Also, does LW mipmap textures in linear color space or just in sRGB, because it might also pose a problem of double sRGB to linear conversions, negating the benefits of linear mipmap operations.

[gerardstrada]

Okay, this has been driving me nuts all day now (eating away more than a day of my 3 day budget).

Not sure if any users can answer this (hopefully one of the developers can shed some light on this)

We work in a linear workflow (color and textures all in linear RGB color space, light using inverse square distance as falloff), but i have the vague impression LWs FG/GI uses no falloff model when dealing with multiple bounces.
Now, FPrime seems to do inverse square distance on it's GI calculations (seeing the huge differences in shadow areas)

Am i just imagining this? Or should i just switch to Maya on the last day (again).

Yep, that's an interesting question, and that difference has nothing to do with direct lighting, as you've said.

But question is: which is the right way?

If we see the manual, it says: Inverse Distance ^2 uses a higher, more natural level of reduction.

But, let's consider this: that natural level of reduction is obviously shown without no linear workflow taken into account. In that context, Inverse Distance ^2 provides more natural falloff than linear because what ID^2 is really doing is compensating a wrong preview result. So question now is: working in linear light, is Distance ^2 really needed? hmmm...


Also, does LW mipmap textures in linear color space or just in sRGB, because it might also pose a problem of double sRGB to linear conversions, negating the benefits of linear mipmap operations.

Please, don't say sRGB, a better term in this case is log space or encoded gamma space or non-linear gamma (LW doesn't work in sRGB or something like that). It doesn't manage colors. It works internally in XYZ color model. So all colors from a given image are interpreted as "absolute" colors.

About mipmap, I've noticed LW apply the mipmap operation according to the gamma encoding of the image. So if our image is linear, mipmap is linear too.



Gerardo

[Captain Obvious]

Lightwave's radiosity uses inverse² falloff over distance, just like every other GI engine out there. It's pretty much impossible to do proper GI that DOESN'T do inverse².


But, let's consider this: that natural level of reduction is obviously shown without no linear workflow taken into account. In that context, Inverse Distance ^2 provides more natural falloff than linear because what ID^2 is really doing is compensating a wrong preview result. So question now is: working in linear light, is Distance ^2 really needed? hmmm...
Yes, it is! Inverse² falloff is the physically accurate falloff. It's really quite simple: Light sources work by emitting photons. An "omnilight" emitts photons in every direction. If you get twice as far away from the emitter, the density, photons per square meter, is decreased by a factor of four.

It has NOTHING to do with the color space or the gamma correction or anything of the sort.



As for LW and images, Lightwave just deals with raw RGBs. It completely ignores color space and whatnot.

[gerardstrada]

Lightwave's radiosity uses inverse² falloff over distance, just like every other GI engine out there. It's pretty much impossible to do proper GI that DOESN'T do inverse².

However Red_Oddity inquiry still remains. FPrime and LW calculates bounces in different ways. At least, results are different here, too (mainly in reflective surfaces).


If you get twice as far away from the emitter, the density, photons per square meter, is decreased by a factor of four.

It has NOTHING to do with the color space or the gamma correction or anything of the sort.

Yes, that's what I think as well, but I wondering also from time to time: "If you get twice", we say, hmmm... that dependes on how we measure that, I guess... If the measure is perceptual, that is to say, with human eye perception, we are not taken into account linear light behavior and local adaptation. In such a case, it might have A LOT TO DO with non-linear space and tone mapping. But I'm not saying that it is necessary in that way. It's just a question to re-think from other point of view :)


As for LW and images, Lightwave just deals with raw RGBs. It completely ignores color space and whatnot.

Yep, as I said before, LW doesn't manage colors. It works internally in XYZ color model. So all colors from a given image are interpreted as "absolute" colors. We need to take that into account if we want to keep color consistency.



Gerardo

[Captain Obvious]

However Red_Oddity inquiry still remains. FPrime and LW calculates bounces in different ways. At least, results are different here, too (mainly in reflective surfaces).
Yes, there are differences, but it's not that Lightwave's not using inverse square falloff.


"If you get twice", we say, hmmm... that dependes on how we measure that, I guess... If the measure is perceptual, that is to say, with human eye perception, we are not taken into account linear light behavior and local adaptation. In such a case, it might have A LOT TO DO with non-linear space and tone mapping.
That's just confusing. If you're one meter away from a light, you get illuminated by X intensity. If you're 2 meters away, you get illuminated by X/4 intensity. Perception has NOTHING to do with it -- perception only changes how we percieve said falloff.

[gerardstrada]

Yes, there are differences, but it's not that Lightwave's not using inverse square falloff.

ok. Let's say that's correct. So this is due to...


That's just confusing. If you're one meter away from a light, you get illuminated by X intensity. If you're 2 meters away, you get illuminated by X/4 intensity. Perception has NOTHING to do with it -- perception only changes how we percieve said falloff.

Hope this doesn't confuse more, but it has A LOT to do since we are talking about how falloff spreads along a distance, even more if that measure is taking into account our visual perception.

Make this test - in reality, please - take a lamp and light a wall, then take other lamp (same intensity) and light the same spot. Even when that spot area is receiving the same amount of light twice, we don't perceive the double light intensity. Why? According to scientists it's due to local adaptation of human vision. We can simulate (and exaggerate) this phenomena with some tonemapping tool.

This is a raw render output:
http://imagic.ddgenvivo.tv/forums/ies/rawrendspec.png

This is a tonemapped version of the same render:
http://imagic.ddgenvivo.tv/forums/ies/tm.png

We can see how specular highlights has changed its falloff and intensity.

Other simple test. This is a raw render output:
http://imagic.ddgenvivo.tv/forums/ies/rawrend.png

This is the same, worked in LCS:
http://imagic.ddgenvivo.tv/forums/ies/lcsw.png

As we see, one of the advantages when we work in linear light (workflow), is a more natural diffuse shading. This implies to change the way light spreads along the surface. This affects the diffuse falloff, overall contrast of the image, fresnel reflections, color bleeds, perception of light intensities, glares, etc... and we are not taking into account local adaptation.

Now, how this affect the falloff feature? let's make other simple tests:

This is a raw render output. Distance from a extreme to another is 8m. linear falloff (8m).

This is a raw render output:
http://imagic.ddgenvivo.tv/forums/ies/raw8mfalloff.png

This is the same, worked in LCS:
http://imagic.ddgenvivo.tv/forums/ies/lcsw8mfalloff.png

Distance has changed. It looks more natural.

Let's try ID^2 now. This is a raw render output:
http://imagic.ddgenvivo.tv/forums/ies/raw8mfalloff2.png
It doesn't look realistic for me - it's too contrasted (and this is what we see in almost any sample about ID^2)

This is the same, worked in LCS:
http://imagic.ddgenvivo.tv/forums/ies/lcsw8mfalloff2.png

Again, distance is different, even intensity looks a bit different. It looks better but... which looks more natural? this one or the linear one?

If we say the linear one, we might think that the question proposed previously is not so senseless. But let's suppose we say this one. The range of that light intensity looks like a 1000% intensity (if we compare it with a distant light for example). So I made a test with 1000% intensity but using linear falloff by working in LCS (same 8m):

http://imagic.ddgenvivo.tv/forums/ies/lcsw8mlinfalloffintensity.png

hmmm... similar to ID^2. Question, is still valid I think. Let's reach our own conclusions :)



Gerardo

[Red_Oddity]

Kay, let's see, so, GI and FG (even interpolated) ARE using inverse square distance as falloff.
Mipmapping is done linear (seeing LW doesn't take a file's gamut into account)

Now, i asume the entire renderer and everything internally in LW is done in a linear fashion, as there is no option to set a color space or gamma for rendering.


Still, leaves the question as to, should we tweak renders with a gamma correction applied after rendering (as we do over here) and whether or not light fallof really should be inverse square distance when working in linear color space and it gets converted in the final comp to a non linear color space (usually sRGB), my eyes say yes, but i could be wrong.

...Man, we've been toying with this for more than 2 years now, and it still isn't quite clear (and it really starts getting fun when you create HDRIs, color space and white balance galore)

[Red_Oddity]

Ireally should run some more test when i have the time (but that won't be anytime soon as i'm swamped in work)

[jdomingo]

what is LCS?

[gerardstrada]

As we know LW doesn't manage colors, but it doesn't mean that it doesn't take into account gamma encoding of images. (let's remember gamut and gamma are two different things). So in this regard, if an image is gamma encoded, mipmap operations applied to it, will be in log space too (if we don't work with any linear workflow).

This means that if colors are gamma encoded, effects will be applied in log space too, and vice versa: Let's say we have an HDRI image (linear), if we apply a glare filter (let's say Corona), this filter would be applied in linear way to the image (because image is linear), if we gamma correct the result in post processing, we'll obtain a "physically accurate" or more realistic glow effect. But, if we gamma encode the image (let's say with FPGamma), and apply the same filter without gamma correct anything later, we are applying that effect in log space (even when LW works in linear light internally).

Btw, ID^2 looks good to me, too. And if you guys are working in linear light properly, OF COURSE! continue doing so :)



Gerardo

P.D. Just a comment, sRGB is commonly advisable only if we are working for web. In this regard you may want to take a look at Issue #18 of HDRI3D magazine (http://www.hdri3d.com/issues/h18.htm)(sorry for the advertising) :D

[gerardstrada]

what is LCS?

LCS= Linear Color Space



Gerardo

[Captain Obvious]

Tone mapping is a post effect applied to high dynamic range images -- it has NOTHING to do with the behaviour of lights or GI or anything else in the rendering process.



Kay, let's see, so, GI and FG (even interpolated) ARE using inverse square distance as falloff.
Mipmapping is done linear (seeing LW doesn't take a file's gamut into account)
Lightwave's mipmapping is done on the raw RGBA pixel values. All it does is generate a few lower-resolution versions of your images. It basically seems to be WYSIWYG: whatever the image editor shows is what the mipmapping uses.

[gerardstrada]

Yep, but as we've seen also, it seems it has A LOT to do with the way how we perceive light intensities, falloff and overall contrast of the image. When we tonemap an image, light behavior doesn't change, how light bounces is calculated doesn't change too, of course, but we can perceive it in different way (or very different) :)



Gerardo

[Captain Obvious]

Well yeah, that's the whole point of tone mapping ;)

Good example: If your scene is too dark, don't up the Ambient light, just up the Gamma correction instead!

[gerardstrada]

Yea, and it seems that's the whole point also if local adaptation and non linear response are taken into account when we measure light falloff.

Btw, If we want to keep the intended colors, I'd try something like this (http://forums.cgsociety.org/showthread.php?f=21&t=471102) before of beginning to play with gamma :) But better than that, I'd recommend to work properly in LCS (http://www.hdri3d.com/issues/h18.htm) (upsss! sorry for the advertising again :D)



Gerardo