I asked about why we have an emit value for a material, but no radiosity. The answer is the new AAO feature of Blender 2.5. This is very similar to what is available in Kai’s build. You can use the emit value of a material to cast AAO light onto a nearby surface. This gets us closer to mesh based lighting, but there are differences. You control the inclusion of this additional lighting information with the Indirect and Bounces values under approximate ambient occlusion of the world TAB.
A Bounces value of zero seems to turn it off. Also an Indirect value of zero seems to turn it of too. Another thing to remember about this is that the 2.49 EMIT value limit of 2.0 has been removed. So you can really crank up how much a material can contribute to the scene.
One of the things that really seems to be missing is the ability of this feature to reach out into the atmosphere. So you can’t seem do blooms or glows with it, but you can prepare the nearby surfaces to seem like they are in the presence of a bloom or glow.
The spacecraft in these images are using AAO for the nearly glowing parts.
this is even cooler, because it works with all materials, not only emission>zero. So basically it provides color bleeding phenomena (rough but fast). It can really make a render more vivid and “GI like”. I love it!
Currently it works only in “approximate AO” mode, but that’s OK for most scenarios.
ok, so it basically looks like on the picture. Purple box does not have emission (zero emission) still it color-bleeds on the gray cube. Seems it works after all.
What is bit strange is that cyan box is emitting light even under purple box. I guess it’s cause of approximation.
In my scene, I have a low energy (0.001), high Indirect (10.0), falloff set to 0.1, error set to 0.9, correction set to 0.9 and pixel cache turned on. The emit values on my materials range from 2.0 to 9.0. It is a nice fake, but I would hardly call it fast.I have found that get a right angle face to receive any color, you have to increase bounce up to at least 2. This bounce increase does come at a speed cost.
But it still is faster than how long it takes when getting a noiseless result using Farsthary’s photon mapping and FG build,
AAO GI will be much more useful once it is made independent from face size, I’ll be surprised if Brecht doesn’t do that because it may be required for Durian, particulary when they start the serious rendering work.
Well, it’s not so slow… or maybe I just didn’t try it in a “real life” project
But first pictures here renders in less then 30 seconds (with slight built-in postpro).
Seconds renders a lot longer, due to water material - it takes over 3 minutes (?).
Do I have to subdivided all my model before rendering whth the new AAO. This will freese my blender work. I am doing an architecture model with many glass, glossy reflection tiles and water.
I haven’t divide any geometry (more that it was in normal work-flow). On the screenshot you can see geometry and water material settings. It’s nothing fancy, btw water’s IOR is totally wrong (as for real water it’s about 1.2 if I remember correctly).
I read somewhere that you can avoid the faces subdivision with a… subdivision modifier. You may set it to simple subdivision if you need flat surfaces, and the AAO hack should work as well. Anybody to confirm this?
I have posted an animated test that reveals the the AAO/GI system flickers when used in an animation. This is a big bummer. I hope the Durian team can fix this, they are sure to run into this problem as well.
If you watch the video, you will see the shuttle craft flicker (mostly the blue light) because of the AAO lighting. http://www.vimeo.com/8043003
Fake techniques are never really going to replace more accurate ones. But yeah, flickering is a bummer as AO is mostly a fake intended to speed up animation anyway…
They HAVE to replace them for animation. You can’t run something like that through Lux. Yeah, it would look great, and would have photo-realistic lighting and would look just like the ‘real’ thing would… but you can’t hang around for 12 hours per frame for animation. Especially as most of us are limited to dual and quad core machines and don’t have our own render farms.
You really do need to ‘cheat’ for animation. People think it’s evil to cheat to render, but for animation, it’s a necessity.
Think of games, they cheat left right and center to get the results that they do in real time. Does anyone complain there? No. Same deal for animation.
Quad cores? Just a few months ago I still had a P4.
You don’t need ultimate realism, but some true raytracing and GI is good. Good ol’ Photon mapping GI is fast enough on today’s computers. Try out yafaray to see it – I’d be surprised if it’d take much more than 40 minutes per frame. Assuming not much refractions and reflections going on – just diffuse interreflections for GI is much faster.
I agree, I don’t need ultra-realism, just a way to approximate light emission. I did try Yafaray, but it crashes because it has a bug related to multiple mesh lighting. The ships I am using have several mesh lights per model and Yafaray for Windows can not handle that. I reported that problem to the Yafaray board and bug system as well.
@TeaMonster: Even with 12 hours per frame on Lux, there is still the dancing noise problem with Lux based animation. I would be trading one flicker for another. I can not find a single setting that removes the dancing noise problem with Lux and I have tried them all and communicated my efforts on the Lux board. Lux, simply, can not be used for professional output in an animation. It is fun to play with. I am using 25133 without any problems, maybe you could just try and download it again?
Overall, these external render systems are managed by 1-5 people who are typically only working on this stuff in the evenings or weekends. It is hard to wait around for months for an issue to even be addressed. Mainly, those developers just work on the issues that are plaguing their renders. I don’t blame them for that, I would probably do the same thing as well. That is why I try to contribute at the python level. I have added features to both Yafraray and Lux exporters, but the problems I run into are really at the core of each system.
A lot of times you can sort of smooth out the flicker at the expense of render time(of course…drats!)by using some good old motion blur, not vector based, but multiple frame overlay blur(standard).
This is just a thought I do mostly RT stuff and not too much rendering, but that is a trick I used to use(when I was getting into 3D) even for stills & to keep things clean.
@ nameskuseijin - 40 minutes a frame is still way too long, unless it’s a really small project. I’ve tried Yafaray out on some scenes and got some decent times. But I had to turn off just about all the GI features to get it to cough in a reasonable time. I’ve got a dual core, but only 1 Gb of RAM.
@ Atom - That is the problem I have with external renderers. It seems stuff works fine with Linux but in Windows it seems to die if you chuck anything chunky at it.
Thanks, I got it working. I hadn’t turned the right settings up.
I heard about the flickering problem. One of the devs was going to angle the next release towards getting a decent animation setting going, but I think he’s the one who left recently!
