Past-present-future features of unbiased renderers

[Hybaj]

Ian : I don't understand. Have you seen the Vray video?? Probably not The Vray thing is described as a realtime preview. Not a word about truly realtime raytracing, Opengl or Direct-3d (check the chaoticdimension forum for yourself). From what you can see in the video it's too not 100% real-time and the lightning detail refines progressively when the camera stops. Low gi samples for being able have enough fps to rotate and move around and then when it stops it progressively refines. So in essence it looks like the same thing as yours(with some obvious differences).

So talk about imagination mr. Ian

And yeah let's see what will be the next holy grail in the MLT mutations

[CoolColJ]

multi-try coherent MLT that is fast even with bumpmap and SSS

speed is the main thing....

[IanT]

Ian : I don't understand. Have you seen the Vray video?? Probably not The Vray thing is described as a realtime preview. Not a word about truly realtime raytracing, Opengl or Direct-3d (check the chaoticdimension forum for yourself). From what you can see in the video it's too not 100% real-time and the lightning detail refines progressively when the camera stops. Low gi samples for being able have enough fps to rotate and move around and then when it stops it progressively refines. So in essence it looks like the same thing as yours(with some obvious differences).

So talk about imagination mr. Ian

And yeah let's see what will be the next holy grail in the MLT mutations

Hybaj,

What I wrote was British humour at its driest

I wasn't saying that the VRay realtime stuff was a figment of your imagination (yes I've seen the vid, it's very impressive) ... I was saying that the Radium realtime stuff must have been (because Radium is Java and some self-proclaimed programming "experts" have told me in the past that Java isn't fast enough to do anything like that). It's like the time scientists declared the bumblebee shouldn't be able to fly, given its proportions and wing size (but clearly it does)

Ian.

[IanT]

As far as Aeronoise goes

I think it works ok with bidirectional path tracing, but I'm not convinced if it will work that well with MLT, with MLT mutating all over the place!

You would need something else, some kind of priority system

Absolutely right Colin... something like Aeronoise(TM) is trivial to implement for pure bi-directional, but MLT presents all kinds of problems. As you pointed out, limiting mutation extent (not toohard to solve ... if you mutate the display pixel outside the area, you just wrap around) but also, the MLT algorithm adds samples to the image buffer (rather than averaging them) .. so one area receiving more samples than anything else would be brighter. The obvious solution to this is to record details of the aeronoised(TM) areas so that the tonemapper knows to expose them differently to the rest of the image.

Ian.

[Hybaj]

I guess it was obvious that our beloved math can solve a wide array of possible problems. Now the questions is, if it's worth the hassle to implement such a feature. That's what's this topic is all about.

Is it worth it?? I say confidently yes (even when I imagine the fuss with every ray shooting technique) since it's a great time saver and I bet all developers would love to use it even during their own tests.

[oodmb]

aeronoise shouldn't work horribly with mlt, what you would end up doing would be to break up the image into many parts and render each seperatly and the aeronoise just chooses the region where the image should be rendered. it would be a little complicated to set up though.