Indigo Renderer 2.4.3 Released

[Pibuz]

Ok guys thanks.
So basically you're telling me to set, eg, the emitters' efficacy to 500 and then to dim it inside Indigo, through the layer value. This should lower the calc time for the emitters, and avoid the creation of fireflies?

[lycium]

What we are effectively doing is giving the lights a higher computation priority; support for doing this directly is planned, and has been discussed with the plugin developers.

Pibuz, yes it should help reduce the fireflies to some degree - exactly how much, I'm not sure; your tests would be greatly appreciated! I suggest also to raise the supersampling factor if you have free memory to do so.

[Pibuz]

...if you have free memory to do so...

Yeah: I WISH!

I'll try to push the efficacy up a lot, and to do a comparison test, btw. Seems to be quite critic, so I'm very curious! I'll post the result here.

[antoacq]

so i do not understand!
the new issue 2.4.4 for mac user is not still with GPU implement?
and when it will be?

[Headroom]

No it's not. The 2.4.3 releases aim was mostly GUI improvements. I have actually not gotten around to download and test it myself, however, based on what I read in other threads there are CPU speed improvements of up to 120 % ? (IIRC).

GPU acceleration is in it's beta phase and currently only supports MS Windows systems and more recent, higher level GPUs.

For example a current 27" iMac i7 with an ATI Radeon 4850 - at least in the current beta phase - won't offer GPU acceleration as the minimum is a 5xxx series ATI Radeon. So even if you would run a Windows system under Bootcamp you're out of the game!
We'll have to wait and see what ultimately will be supported when the fine folks at Glare get around to offer GPU acceleration for Mac users.

[zeitmeister]

The 120% is only in my actual scene, which is surely not representative.
In average, the new betas will have a speed increase up to something like 20-30%, I guess.

I have to say that in my case, I have a lot of single meshes (no instances). When I collapse them into one single mesh, the speed increase is around 23%.
So it seems like the upcoming versions are handling lots of single meshes far better than the old ones.


By the way:
It seems like the mac GUI is a little bit broken within the light layers tab. It appears to be scaled down to 50% of the rest of the GUI... if you can fix that, it is a great improvement. Especially the light temperature settings and the possibility to collapse everything... great! If only you could scale it to normal size. :-))

[fused]

The 120% is only in my actual scene, which is surely not representative.
In average, the new betas will have a speed increase up to something like 20-30%, I guess.

wait. so you're saying its 120% faster? not 120% of the speed of the old version? thats impressive

By the way:
It seems like the mac GUI is a little bit broken within the light layers tab. It appears to be scaled down to 50% of the rest of the GUI... if you can fix that, it is a great improvement. Especially the light temperature settings and the possibility to collapse everything... great! If only you could scale it to normal size. )

Yes, i noticed that issue to during testing, its on my todo list. Thanks for reporting!

[CTZn]

Ok guys thanks.
So basically you're telling me to set, eg, the emitters' efficacy to 500 and then to dim it inside Indigo, through the layer value. This should lower the calc time for the emitters, and avoid the creation of fireflies?

You don't have to wait to see if you've got a "good" efficacy value. Let render for 30s (of course the longer the test, the more accurate), then pause and swap layers; the noisiest one will need more power. Computation should be balanced between layers when all have the same amount of perceptual noise after the same amount of time, with the same layer settings.

That's on an average, as render times can make the first impression lie... but this should help meanwhile.

[zeitmeister]

wait. so you're saying its 120% faster? not 120% of the speed of the old version? thats impressive :)

Yes, but only in my special case. Why the hell. But it rocks!

Yes, i noticed that issue to during testing, its on my todo list. Thanks for reporting!

Denada! :-)

[fused]

Heya,

here's a mac build compiled with gcc 4.5.0 for, hopefully, some more performance.

edit: see below!

[zeitmeister]

What a pity; I can test it only on monday.
Erm, a question: these are 64bit-build only, aren't they?

[fused]

What a pity; I can test it only on monday.
Erm, a question: these are 64bit-build only, aren't they?

nope, these are so called "fat" binaries, they should work on any mac, 32 or 64, bit with at least a core 2 duo intel processor.

Also the next mac build (very soon) will have LLVM support for both 32 and 64 bit (32 is working already, 64 is building right now).

[fused]

edit: never mind, new build with fixed dependencies very soon

[Godzilla]

I don't know if this has been brought up (I don't feel like looking through this entire thread), but the 'lock aspect ratio' check box it broken, or at least not working like I would expect it to.

Ideally it should update in real time as you are typing in a new dimension if the box is checked (like Photoshop) - but I find that you need to type in a new dimension, then click the box and it will update the second dimension according to the previous H:W ratio.

Any plans to adjust this behavior? I find it to be unlike any software I've used..

[lycium]

It has been brought up (it also only works in landscape), and yup there are plans to change this behaviour. I had an obscure issue with Qt while I was working on it, and found it easier to update the other value after editing was done. Fused has since shown me a way to prevent the problem I was having, so I'll go back and fix this before too long!

Thanks for taking the time to report