2x[Idea] adaptive sampling+adaptive Supersampling (I guess)

[Kram1032]

I got an idea for adaptive sampling, now. No idea, if it can be called "unbiased", though.

what about counting every single ray, shot to a particular pixel (or also sub pixel, if that's necessary, precision wise) and list it as a "used" or "unused" (killed, before, or because of it reached a light source) - if you use that data correctly, you get a map, where there are harder to sample areas, which need more passes

Also interesting would be, using new poison disks, after each pixel sampling pass, if that's not done, already. - even if the pixel is split in only four sub pixels, as it's the case at SSF 1, as far as I know, the pixel still gets anti aliased better and better, due to new sub-pixel positions

What do you think, about that, Ono?

[OnoSendai]

Indigo already uses sub-pixel sampling positions.

[Kram1032]

yes, I know.
That's what super sampling does, as far as I know, but I meant, a changing poison disk, after some time, or something.
(super sample factor 1 means, splitted pixel in 4 parts, 2 means, 9 parts, 3 means, 16 parts - OR 2 means 16 and 3 means 32, or something like that... right?
How ever it works, doesn't really matter, but what about "simply" changing the poison disk pattern, after using each sub pixel, at least once? - that's my idea, more or less)
Or does it do that, too, already?

And what about the other idea?
Or would it be slower, to track rays as used/unused, than it actually would fasten things up?

unused/used rays per pixel = relative amount of needed paths.... if EVERY path is unused, some thing's definitely wrong... (or sub pixel, if that wouldn't be too slow // if it wouldn't be accurate enough to use that info on pixel level)

[vux]

i dont know that my idea is normal, in though.
But I think that maybe Indigo need per-material sampling
What you think about that. I think it is good for only areas that need sampling...

[Kram1032]

that was discussed, already...
The problem is, you need to find out, how much which mat *really* takes longer to converge, than others...
that either gets extremely complicated for (especially new) users or needs to calc a lot of extra stuff... (especially for SSS for example: the higher the scattering coefficient, the longer it needs to converge - absorption works the other way round: the higher, the faster, as more rays get killed... and what's about CBC? I dunno... it needs ~7x longer to render, with cbc on)
besides from heavily indirect light situations, the method I (tried to) describe/d here, would be automatically aware of that... I think... ^^

[alex22]

It actually sounds really cool. With unused paths you mean rays that get kill by to much absorbtion before they reach a light source?
Similar to this you could count the mean number of bounces to reach the light source. The more bounces, the noiser it probably is.
What you could also take for sampling is the distance of the first intersection from the camera. Those intersections very far away aren't that important is near ones.

[Kram1032]

My idea was making a quotient of used paths, shot in that pixel's direction to unused (as you said, absorbed too early) rays

yeah, if you know how (I don't have a particular idea, right now), you also can take into account the actual bounce count
The more often a ray bounced, the more indirect it was...

I've no idea, what exactly to use that information for, though...
maybe, for sorting out more clearly, usable paths from unusable paths, by "smartly" detecting every killed rays' paths for similarities and finding "patterns", that aren't so important to shoot rays to (especially for diffuse, phong and glossy transparent mats, that might come in useful: "which random directions, I don't need to use" [hum, that sounds biased ])