Allrighty then, here’s a new test render. It’s just a plain old AO scene that renders in 1/2 hour with AA set to 1 1. Quite slow compared to yafray or blender, which take only 1 minute each.
Tips/info:
Turn off gamma correction to get the same color results as blender.
Allow textures to work with ambocc without renaming many materials: export normally and replace “type diffuse” with “type amb-occ.”
Loading textures takes a while the first time; reloading the scene is then much faster.
I tried to speed things up by using path tracing and a large constant-shaded sphere around the entire scene, but it renders just a little slower http://home.comcast.net/~gamma-ray/sf/toon-house-gi.jpg and the results are the same. I guess the amb-occ shader is optimized to the fullest, but the AA is what slows it down.
What happens when you browse the source code? You find a new render engine inside sunflow! These two scenes (see bottom of toon-house-fake.sc) use the ‘FakeGIEngine’ and will render rather quickly, and the results are pretty good. Time was 1m53s for each with AA set to 1 1. Some experimentation with the ‘up’ vector even led to a nighttime scene. The only drawback is that the groundplane seems loose visual power. You gotta love this stuff.
Use this FakeGIEngine for daytime:
gi {
type fake
up 0 1 0
sky 0.0 0.5 1.0
ground 1 1 1
}
And this for nighttime:
gi {
type fake
up 1 1 0
sky 0.0 0.5 1.0
ground 0 0 0
}
is there a Yafray comparison to these renders. the blender one doesn’t look to great, but the other one does. i am curious if Yafray is pretty similar.
For ambient occlusion you don’t need to set min=max. This will slow you down. This suggestion is only valid for path tracing (because its really noisy and you don’t want the adaptive AA getting confused). AO is typically rather smooth so you can use adaptive on it.
Looking at your scene, 0 1 should be fine. Even 0 2 for final quality.
The important number is the number of rays used for the AO shader. Unfortunately, when declaring the shader type as “amb-occ” you can’t set the number of rays explicitly. Its 32 by default. The probe rays are also infinite when they could be clipped to a small range. I’ll adress this in the next release.
I plan on removing gamma correction altogether for future releases. It doesn’t really belong inside the renderer. Now that we can output lossless OpenEXR files, you can always take that image and gamma correct it if you really want that.
Yep thats a good way to do it (its how I first tested the AO shader). See the note above about this declaration not including extra AO options that could improve performance.
Yep, the amb-occ shader is optimized for exactly what you are trying to do, so anything else is gonna be slower.
I don’t recommend using this engine at all. Its a simple hack to have a directionally varying ambient term. It doesn’t shoot any rays which is why it isn’t giving you any contact shadows. It can fill in your scene if you just have a single object floating in space or if you already have shadows from your main lights, but on its own its pretty useless
Thanks for the scenes. I’ll try to optimize the render when I get home.
Alltaken: The yafray ao render is nearly identical to the others. In fact they all are very, very similar. Blender’s is just a little darker. Yafray’s is here: http://home.comcast.net/~gamma-ray/sf/toon-house-yaf-ao.jpg and it took about 4 minutes with Blender’s ao setting.
Chris: Wow! That’s what I call optimizing. The kdtree had a tremendous impact. It renders on my PC in just over a minute, which is the same as with Blender. The fakegi renders in 5 sec. Thanks a million. So we need a general description of which type of accelerator is good for which type of scene.
As far as the number of rays goes, I was going to learn java and extend the ‘AmbientOcclusionShader’ to allow for textures, but for amb-occ2. I still might try it myself just to learn from your code.
I like the FakeGIEngine. I know it’s not a real “engine,” but I was just experimenting. And a similar result could be had with one or two colored point lights.
Well, basically kd-tree will always perform well, however there are currently a few downsides: memory usage and build time.
But fpsunflower is working on that (as am i for yafray g).
I don’t know if it’s possible to squeeze the memory usage like in C++, it’ll probably always be above the uniform grid, but as the name implies, uniform grids only perform reasonable on uniform geometry distribution, which is actually rarely the case…
might be good for some particle clouds etc. but not really for surface geometry.
