I am stupid dumb. Where can I find the IBL sweeting used with AO in blender 2.48? I just had it a minute ago in 2.47 :rolleyes:
Ah it would be new to me that 2.4.8 has IBL.
There was a not yet finished patch - but I think it was not done
and committed yet.
I also would love to get that into Blender and a single one or two bounce for
color bleeding.
Mellowfellon: You must have used a custom build, because IBL have never been in an official build.
The last thing I heard about the IBL-patch was that it still needed work to integrate it nicely in blender, and at the speed Matt’s currently is developing volumetrics, I guess there isen’t much time left for the IBL…
yep - looking forward to the volumetric.
but I hope that at one point Matt will find some time to go back and finish the IBL.
Blender would benefit from this a lot.
Will IBL be needed now that UncleZiev comitted meshlights to his branch? Since I assume textured meshlights will work like textured arealights you could possibly use this to do an IBL-like lighting dome with procedural textures even.
From what I heard and saw, it was much faster and didn’t (as far as I know) suffer from the banding problems that LC does.
I just saw that UncleZeiv said that there’s a current limitation to meshlights in Light Cuts in that they cannot currently be textured. Maybe he can get it working eventually…
What’s IBL?
Yellow IBL stands for “Image Based Lighting”
You use an HDRI image to illuminate your scene - so you do not need lamps.
Claas
You can always slap an HDR OpenEXR file as the environment (AngMap in the World), enabled AO and use Sky Textures for the illumination color.
As far as lightcuts, unless it gets faster and nicer than a standard GI solution (final gather, etc.) and loses the flicker on animation it’s not going to cut it as a production solution.
I’ll ask a phenomenally stupid question: would it be possible, then, to render out an environment in Vue to a BMP, somehow convert that to a compatible format, and use THAT with AO/Sky Textures?
Sorry if that’s dim, I’m a bit new at this side of things… :o
Sure. It wouldn’t be High Dynamic Range, but you can do that.
Found a couple of links talking about Broken’s work on his patch.:
http://blenderartists.org/forum/showthread.php?t=119418
From what I gather, it falls somewhere between sky-colored AO and lightcuts. I, for one, would love to see Matt finish this lil’ ol’ project with a fleshed out implementation… it could be really handy. However, I don’t want to take away any of his efforts on volumetrics, atm.
Cool, thanks for the answer! I’ll go experiment with it, I can think of all kinds of fun things to render! :yes:
In the lightcuts branch you can set up a HDR image in the World panel as sky texture, ang-map, and it works already as “environment lighting”. As for textured emit materials, it’s just a matter of finding the time to code that, there’s no inherent limitation.
What Matt does in the patch you guys are mentioning, as far as I know, is an interesting technique that extracts the low frequency variation from the environment map and uses that for shading in a very efficient way. In a sense it’s like having a blurred version of the environment map: the less blurry it is, the less efficient it gets. It’s a technique that can be used even in realtime, with some limitations.
@harkyman: you’re perfectly right, lightcuts is not production ready. Yet 
This “efficiency” is why I think it would be great to flesh this out and get it into the main. If it could somehow be leveraged and utilized for enhanced real-time lighting in the BGE, then wow, even better! Think of the archi-viz walkthru’s that could be possible…
Uncle
would it be possible to continue his work so it can be used with AAO?
I have been told that Brecht did some tests experimenting this kind of stuff, but wasn’t satisfied with the results. We’ll see.
I’m not sure what you guys are referring to exactly there, but the prefiltered IBL code I was working on works quite well with AAO, using ‘bent normals’. Here’s an example, took less than 10s to render:
The main reason I haven’t taken this much further so far are other more pressing priorities, and the unanswered question of how to integrate this properly. We really need a consistent framework for the future that is flexible enough to allow you to choose between multiple GI methods, AO, multiple ways of using environment lighting, etc. At least in my experience Vray and also luxrender have nice structures for seamlessly choosing between different GI sources like path tracing, photon mapping, instant radiosity, etc, etc. and that’s what we will need for Blender too.
Ideally you should be able to turn on environment lighting and choose between multiple ways of calculating it, like this method, or light cuts, or some other importance sampled approach, whatever. Getting this consistent and usable is the tricky part, and I haven’t spent that much time thinking about it yet.
A bit of a bump, but it was that or start a new thread I guess.
Effectively don’t know any code, but successfully compiled my first windows build of Blender tonight. Yay!
Being the ambitious fellow, I then tried patching the IBL (ibl06.txt) using TortoiseSVN. I got most of the way through - I think - using TortoiseMerge, but rayshade.c (first on the list of patched files) gave the following error:
The patch seems outdated! the file line
else{ /WO_AOSKYTEX/
and the patchline
float dxyview[3];
do not match!
I thought I’d make myself useful and try patching IBL to the current SVN rather than bug other people to do it. If it currently can’t be done, could someone let me know - save me the time of sifting through code I dont understand… 
Also, I tried compiling anyway despite the error, it compiled suspiciously quicker than my other build (which was my first build, maybe it doesn’t redo everything) and appears to be no different. Any thoughts?
Thanks for your time.