Indirect Lighting with BI(possible feature)

[broken]

I think something should be said about gamma/linear workflow/etc.

It's not as simple as just saying applying a gamma of 2.2 to any render will make it more correct. All that does is lighten the midtones. At least the way I work currently with a non-linear workflow, I set the lights up to get the desired output on screen when I'm doing test renders. So if the midtones are too dark, I'll add in lights and tweak it so it's brighter and looks good to me on my gamma 2.2 screen. Going and adding another 2.2 correction to that will just screw things up.

The real value and point of a linear workflow comes with rendering colour textures. But as the name suggests, it's a workflow, that has to be kept in mind throughout the entire process.

What the issue is, is that when you make a texture, either painting it in Photoshop to look good on your screen, or with a camera, that image is made to look good *under gamma corrected conditions, usually gamma 2.2*. So as you paint that texture, you're looking at it on a monitor that's already gamma 2.2, which is not linear. This is all well and good, displays are already gamma corrected to better fit the range of human vision.

The problem starts though, when you use those colour maps as textures in a renderer. When you're doing lighting calculations in a renderer, those take place in a linear colour space. i.e - add 2x as much light, and it gets 2x brighter. The problem is that your colour textures aren't like that if they're at gamma 2.2. What's double in numerical pixel values in gamma 2.2 is not necessarily twice brighter perceptually. So this breaks the idea of taking brightness information from a colour texture and using it in lighting/shading calculations, especially if you're doing multiple light bounces off textured surfaces.

So what a linear workflow means, is that you take those colour textures, and convert them back to linear space before rendering, then you gamma correct/tonemap the final result back to gamma space (for viewing on a monitor). This means the lighting calculations work accurately, however it does change things - because the textures get darkened in the midtones the image can look darker, so you need to change the lighting setup, etc. etc. Hence, workflow - it's something you need to have on all throughout the process, not just applying gamma at the end.

I did some code a little while ago that did it all automatically, applying inverse gamma correction for colour textures before rendering, then corrected back to gamma 2.2 afterwards, and after adjusting lights to have the same intensity, it had some nice results. It seemed to bring out a lot more detail in the textures, which kinda got blurred out before (below, left is normal, right is with linear workflow). It's not finished though, it needs to also adjust the lights in the preview render, and inverse gamma correct colour swatches too so the flat colours you pick in the UI are also linear.



Hope that clears some things up!

[cekuhnen]

Hi Broken

maybe it is a language / translation problem but what do you mean with linear workflow.

I do not understand the point mentioned once you are done with your texture created with a gamma 2.2 space.

Claas

[cekuhnen]

ypoisaant

I actually only shoot in RAW and do the correction on the display

[broken]

Originally Posted by cekuhnen Hi Broken maybe it is a language / translation problem but what do you mean with linear workflow. I do not understand the point mentioned once you are done with your texture created with a gamma 2.2 space.

You can search for 'linear workflow' in google to find some good info on the subject - this is a nice one here: http://www.gijsdezwart.nl/tutorials.php

Basically, your texture's created in gamma 2.2 but for correct results it needs to be converted to gamma 1.0 (linear) before rendering, in order for the light calculations to work best. Then afterwards you need to reverse that, applying a gamma 2.2 to the rendered image to take it back from linear colour space to gamma corrected colour space (which looks good on a monitor).

[renderdemon]

ypoissant,do you really want to know want I think?
At the end all we are saying the same thing,I mean,you want to point out the best workflow
in photorealistic rendering(isn't a Blender related stuff,it can be applied everywhere),no problem with that,I was interested more on what lightcut will be able to do in "raw brute force mode",let's say so.
This divide us,I thought that in a thread where people make test render for a new rendering feature ,that's what the focus of the discussion,not general techniques(btw they are allways good to speak about)
Bye

[kamaro]

Does the light should behave like this



Notice that this doesn't appear in Vray and I try it in real life and it doesn't
behave like this when the light is in front.

[matte]

It also becomes more important the more 'physically correct' you go (in as much as a 3d render can ever be truly physically correct!)

If you're aiming for a photoreal render then you'll be doing things like making lights have bicubic falloff, use reflections of light-objects to create proper specular highlights, and use textures and light intensities greater than 1. With all this active you get more predictable behavior when using a linear workflow. Moving a light twice as close becomes twice as bright, that sort of thing.

Zap Andersson, one of the key mentalray shader developers is very dogmatic about linear workflow, to the point that he's setting up a domain to explain it: http://www.linearworkflow.com

And here's a longish but interesting rant he posted: http://mymentalray.com/wiki/index.ph...ar_color_space

Basically if you're planning on linear workflow, then you have to adjust the whole pipeline. Textures gamma corrected going in, a flat gamma going out of the render, speculars properly calculated in 'add' rather than 'screen', shaders that have proper energy conservation, lights with correct falloff etc.. as Broken points out, its more than just applying a gamma curve.

[hunter551]

UncleZeiv i've found an error when using groups. Under certain circumstances blender will crash. I think i have narrowed the conditions under which it will happen down to:
-more than one instance of a group and,
-indirect lighting enabled

Here's a blend file which crashes for me with the latest svn:
http://uploader.polorix.net//files/177/groups_err.blend

[musk]

Originally Posted by kamaro Does the light should behave like this Notice that this doesn't appear in Vray and I try it in real life and it doesn't behave like this when the light is in front.

Is this a straight lightcut render or do you have AAO enabled for the blender render? Cause I see that behaviour when using AAO without a proper error correction in 2.47 of blender.

[kamaro]

No Ambient Occlusion ON nor antialias ON. Pure lightcut rendering.

[ypoissant]

Originally Posted by matte If you're aiming for a photoreal render then you'll be doing things like making lights have bicubic falloff

"Inverse square". Also called inverse quadratic or quadratic although mathematically, inverse quadratic can be a lot of other things apart from inverse square.

Moving a light twice as close becomes twice as bright, that sort of thing.

Byt the inverse square law, moving a light twice as close becomes 4 times as bright. 4 = 2 squared.

Zap Andersson, one of the key mentalray shader developers is very dogmatic about linear workflow, to the point that he's setting up a domain to explain it: http://www.linearworkflow.com

That looks promising. Thanks for the link.

@broken, - Thanks for getting in on this issue. You have a way for explanation. I like.

@renderdemon, - Yes I'm interested in hearing what you think if that does not include personal insults.

I understand your analysis of where we divide. Regarding this, I think one aspect that launched my gamma campain was exactly the fact that the posts in this threads were essentially testing the LightCuts algorithm and providing feedback on its use and results. As a developer, I found this was a disservice to UncleKliev who is the developer for this algorithm. Without precise benchmarking procedure and precise description of the procedure, it is impossible (and I mean it) for a developer to use user feedback as a guide to fix the algorithm.

Clearly, people can do whatever tweaks they want with Lightcuts but the basic premise of Lightcut algorithm is to produce the same (or nearly) result as any other GI algorithms. From the developer's point of view, that is the goal. And when I saw a suggestion to set the light attenuation to linear from the developer himself, then that is basically what blew my fuse. The solution is either for the developer to ignore any feedback from anybody who cannot tell in details the light workflow that was followed or to tell users how to do it correctly. I decided to try to do the second option. In the end, it can only serve the whole Blender community and serve the Blender reputation as well.

[Maurice Raybaud]

@Y.Poissant, linear attenuation was an answer to my report of colorbleeds being hard to tweak in my scene: not too dark nor bright but expanding too far when visible or just disappearing completely depending on the distance limit. I thought they had an attenuation problem and said they were too linear which thinking back to it would on the contrary have made them intuitively easier to tweak. Of course I was wrong and had underestimated his code since quadratic attenuation was already implemented. I was actually strugling with scales of an exterior cityscape.
I guess UncleZeiv just thought that I was asking for linear attenuation and probably meant to implement that as a non realistic and optional feature for artistic freedom.
Anyway you were right to jump in and clarify the point.

[cekuhnen]

thankx for the pointer for what you mean with linear gamma 1.

I was thinking too much in CMYK space lol it has a different term meaning there.
Linear is actually when it is corrected (printer). But I assume those a word usage
differences between US and Europe.

Claas

[matte]

Heh, should always check my terminology before posting...

Originally Posted by ypoissant "Inverse square". Also called inverse quadratic or quadratic although mathematically, inverse quadratic can be a lot of other things apart from inverse square. Byt the inverse square law, moving a light twice as close becomes 4 times as bright. 4 = 2 squared.

[UncleZeiv]

kamaro: can you provide a blend file?

hunter551: thanks, I'll look into it.

[cekuhnen]

any idea if linear workflow is actually possible with Gimp?

Googled it but it seems only PS is able for that.

[Ace Dragon]

Originally Posted by musk Is this a straight lightcut render or do you have AAO enabled for the blender render? Cause I see that behaviour when using AAO without a proper error correction in 2.47 of blender.

Kamaro: Can you try different settings with different values for direct lights, environmental lights, and indirect lights and bounces?

I hadn't seen such a problem when testing stuff with 4 or 5 bounces, it could also be the indirect lighting distance is too small as well.

[cekuhnen]

I assume Lightcuts use Blender Units?

I have some quite funky results.

[cekuhnen]

Just out of curiosity did I make a quick room test.

I actually do not get any light below the monkey.

All normals of the room face inside the room.

Are my settings wrong? I am pretty sure I only know
half the meaning of most buttons for lightcuts.

EDIT: link is corrected
http://picasaweb.google.com/www.ckbr...07063211269154

[Maurice Raybaud]

Your links give me a 404 error