Indigo Renderer Forum

This is a Beta release.
If you spot any bugs or problems, please make a post about them in this thread.
Thanks!

Indigo for Windows 32-bit:
IndigoRenderer_2.0.11_Setup.exe

Indigo for Windows 64-bit:
IndigoRenderer_x64_2.0.11_Setup.exe

Linux 32-bit:
indigo_v2.0.11.tar.gz

Linux 64-bit:
indigo_x64_v2.0.11.tar.gz

Changelog:
2.0.11
* Fixed packing of IGMs
* Populating Image save dialogue with scene filename as default filename.
* Populating Pack IGS and Pack IGM save dialogues with default filenames.
* Fixed Aperture diffraction bluriness issue. (See the thread at http://www.indigorenderer.com/forum/vie ... f=7&t=6409 )

Now that aperture diffraction is fixed, everyone should use it on all their renders - because Indigo aperture diffraction is a reasonably accurate simulation of a real and inescapable phenomenon.

Yay! Now if only I could use it... :(

Hey Ono, here you got a "Crash & Burn" scene file!

Is it possible to enable/desable automatic update when I test light...

edit: Sorry I just found how to do it

here a quick test:

ZomB wrote:here a quick test:

Did you made the scene like that. Is it expected behaviour? =)

oh yes it is... just a field with 100 emitting spheres and a cam with small aperture size + obstacle map!
At the moment I only have problems to get this working with image based lightning... like envMaps (and envMap reflections!) :/

Ono, before I continue testing... does this work with image based light anyway??

A perfectly fine scene render useless by 2.0.10 :(

Also the same problem on 2.0.11

ZomB wrote:Hey Ono, here you got a "Crash & Burn" scene file!

Zom-B: You're an Indigo-crashing machine, aren't you

The bug was with the one-component obstacle map, have fixed for next release.

Pixie:
I investigated the bug you are referring to. It's a self-intersection issue.
I tested out a possible fix, to make the intersection a little more robust. Unfortunately, it slows down rendering speed by something like 3%-10%. So I'm not sure if it's a good idea to include, seeing as most scenes render fine.
I think you are seeing issues because your model is quite large - larger than it should be (if one unit = one metre) , and not near the origin of the scene.

I'm still investigating this issue, so any feedback or thoughts are welcome.

WytRaven wrote:Yay! Now if only I could use it...

Ah.. sadly, We'll have to wait till Monday to do a Mac build.

OnoSendai wrote:Ah.. sadly, We'll have to wait till Monday to do a Mac build.

I will try to survive till then. Would I be able to resume my current hi-res rings render from the current 2.0.10 igi (@ about 8.6K spp) with the new build and edit the igs to enable aperture diffraction or will that likely cause problems?

WytRaven wrote:

OnoSendai wrote:Ah.. sadly, We'll have to wait till Monday to do a Mac build.

I will try to survive till then. Would I be able to resume my current hi-res rings render from the current 2.0.10 igi (@ about 8.6K spp) with the new build and edit the igs to enable aperture diffraction or will that likely cause problems?

The IGI will definitely be compatible. Editing the camera aperture after the render is an interesting question. Any new samples will be bogus, i.e. effectively rendered using a different scene.
You can certainly enable aperture diffraction. Changing the aperture size etc.. may or may not work
I think if you resume the render, then hit stop immediately, then you can mess around with various aperture sizes and shapes.

ok well I'll leave the current render going and then maybe play around on a backup once the new build is available and see what happens ;)

Added Linux builds.