primary QMC ala PPT based on secondary LC - an idea

[Micha]

Preview ... Vlado could add some little code.
Memory ... for my sample scene no problem and with Win64XP no RAM limit.

So, if I need LC+QMC, I would prefer LC+PQMC.

[ene.xis]

ok did another test...

well memory wise...its not very usable at a certain point of complexity!(well not me at least as i m stickin with 32 bits for a while... )
other than that and the fact u have to guess when to stop literaly...wich is quite amusing! ...maybe it it could be paused/resumed....previewed somwhere inbetween....?

[rivoli]

micha pointed out that if u use qmc+Lc with ur bucket(s) of the size of the image ull be using this gi solution in a ppt similar way...as one can stop at any time...

I see, I think I got confused by the tests showed above. I just couldn't figure out how micha could provide actual examples of this method working.

[studioDIM]

I don't understand where this is different from a PPT in slightly biased mode, with adaptive tracing, maybe.
As i pointed out, it is already a resumable method through BlendImg.
And can work to "infinity" (65k^2 paths, to be precise).
LC is biased (given sample sizes > 1 pixel).
Using PPT in biased mode is a LOT faster, requires comparatively less samples, and the rQMC sampler already does a very good job at picking the correct samples when path tracing.
I'm honestly out of my depth here.

Lele

[Micha]

I don't understand where this is different from a PPT in slightly biased mode, with adaptive tracing, maybe.

PPT: if I understand right, the paths of the rays are quite long - several indirect bounces. Secondary and primary rays are calculated all time. In PQMC mode, first the LC calculate a raw lighting approximation within a few minutes and than the QMC mode calculate with primary rays only the final image - the important direct visible part of the calculation. The calculation spend more time at primary bounces than for secondary bounces. Also, the LC option "use for glossy rays" can be used to speed up the calculation.

And can work to "infinity" (65k^2 paths, to be precise).

Are you sure this is enough? Here a quote from Vlado at the help page:

At present, V-Ray can only generate 2^32 unique light paths internally. The light cache Subdivs spinner is limited to 60,000, which gives 60,000^2 = 3,600,000,000 unique paths. Since these are distributed across the entire image, for very large images it may be impossible to get enough samples per pixel for a smooth result. For example, a 2000x2000 image can be computed with at most 900 paths per pixel - which may be inadequate for a smooth result. In that case, using a traditional sampling method (QMC GI) may prove a better solution.

Using PPT in biased mode is a LOT faster, requires comparatively less samples, ...

My tests dosn't show me that PPT in biased mode is faster than PQMC, like my tests above show. So, I can not agree with you. What could be the reason? Maybe, the PPT mode is not right working at rhino. If this is the case, than I would be glad, if we find the bug. For example I see no effect of the sample size in PPT mode. Is this ok? In LC mode I see the sample size.

... and the rQMC sampler already does a very good job at picking the correct samples when path tracing.

Could you tell more, how rQMC and PPT can be used together? Or did you mean the standard QMC and full adaptive universal settings? Mean you progressiv path tracing or not? I like the progressiv enhancement of the image and try to get it with QMC too. The pure PPT lost to much time, because it refine the secondary rays more than necessary. Let's try to shorten this calculation part.

[studioDIM]

PPT: if I understand right, the paths of the rays are quite long - several indirect bounces. Secondary and primary rays are calculated all time. In PQMC mode, first the LC calculate a raw lighting approximation within a few minutes and than the QMC mode calculate with primary rays only the final image - the important direct visible part of the calculation. The calculation spend more time at primary bounces than for secondary bounces. Also, the LC option "use for glossy rays" can be used to speed up the calculation.

The ppt calculates automatically all the aspects of an image.
Including glossies, DoF, moblur and whatnot.

And can work to "infinity" (65k^2 paths, to be precise).

Are you sure this is enough? Here a quote from Vlado at the help page:

At present, V-Ray can only generate 2^32 unique light paths internally. The light cache Subdivs spinner is limited to 60,000, which gives 60,000^2 = 3,600,000,000 unique paths. Since these are distributed across the entire image, for very large images it may be impossible to get enough samples per pixel for a smooth result. For example, a 2000x2000 image can be computed with at most 900 paths per pixel - which may be inadequate for a smooth result. In that case, using a traditional sampling method (QMC GI) may prove a better solution.

That limit has been raised, and as i said (three times counting this one) the 1.5 release of vray for max includes a blendIMG utility wich allows for the override of those limitations. Do a search, discover for yourself.

Using PPT in biased mode is a LOT faster, requires comparatively less samples, ...

My tests dosn't show me that PPT in biased mode is faster than PQMC, like my tests above show. So, I can not agree with you. What could be the reason? Maybe, the PPT mode is not right working at rhino. If this is the case, than I would be glad, if we find the bug. For example I see no effect of the sample size in PPT mode. Is this ok? In LC mode I see the sample size.

It takes some getting used to the tools before you get the tradeoff between speed and quality. A couple of users saw personal tests i made where a slight bias to the ppt would lead to MASSIVELY faster rendertimes.
I wouldn't just point at bugs too quickly.
Give yourself a few months of experimentation first
The LC sample size is more obvious, but that's because it gets interpolated, whereas the PPT HAS to render a FINISHED image, and you wouldn't want to see the sample size, that's for sure.

... and the rQMC sampler already does a very good job at picking the correct samples when path tracing.

Could you tell more, how rQMC and PPT can be used together? Or did you mean the standard QMC and full adaptive universal settings? Mean you progressiv path tracing or not? I like the progressiv enhancement of the image and try to get it with QMC too. The pure PPT lost to much time, because it refine the secondary rays more than necessary. Let's try to shorten this calculation part.

Vray leverages on a unified qmc architecture.
Every sampling option passes through a qmc evaluation.
Again, search around and discover for yourself, a lot has been written already on it.

Lele

[Micha]

The ppt calculates automatically all the aspects of an image.
Including glossies, DoF, moblur and whatnot.

Strange, I find no relation between what you say and what I say befor. Or you have overseen, that "use for glossy rays" is a special option for LC only. Look at my tests of PPT and PQMC with&without "use for glossy rays".

That limit has been raised, and as i said (three times counting this one) the 1.5 release of vray for max includes a blendIMG utility wich allows for the override of those limitations. Do a search, discover for yourself.

This is right, I know. But I would prefer a method with automatic blendimg or unlimited progressiv calculation without extra steps of manual work.

Give yourself a few months of experimentation first

I forget to introduce myself:
Short the Vray for Rhino forum statistic: total post 1307 - [19.43% of total / 3.72 posts per day] - more than any other user/moderator - hundred of bug reports - several user tutorials. So I would say, I have used VfR more than every other user.
Befor a few years I have used Rhinoman|AIR (renderman renderer) and a half year Maxwell beta (all my portfolio work based on AIR and Maxwell, - I find no time to update the web page with Vray images). Since the beginning of this year I earn money with my VfR work - architecture and design viz. Here you can see my VfR work from beginning to now - later images use LWF. My commercial projects of the last half year are hidden by NDAs.

So why ignore the tests above - the PQMC produce a smoother image with less noise than the PPT one. Like I sayed befor, if PPT can be faster, than I would like to know, how VfR could produce it too. If we find a way, I would like to write a PPT user tutorial for VfR user. VfR user will be happy, I'm sure. Often potential user say: I like to use maxwell, because it is so easy to use. I would like to show to potential users, VfR can do it too and can do more, if some time is spended to learn this few parameters/methods.
But maybe the RC3 PPT is much improved over Vray 1.49.73 PPT. The next SR/beta for Rhino 4.0 will base on the latest Vray. But, until, I'm curious to see a quick simple comparsion between PPT vs. PQMC of a Max user.

[studioDIM]

sure, let's trade CVs, mate
I said it before, and say it again: use the same tools we do, then we'll be able to talk in a more comparative fashion.
PPT hasn't changed much from 1.47.03 (max, again), then and now it works well when used properly.
I know zip of VfR, its limitations and specific implementation bugs.
I won't comment on it.
All i can say is that when properly lit, a scene rendered with ppt will refine and converge quickly, and with little noise.
Share the scene (for the sake of comparison) and we'll have a go.

Lele

[ene.xis]

yeaah...
this thread is pointless...
at ur 27 th post here and u have claimed a new - and better - rendering "process", argue about knowledge of older users...disregarding they r showing us a way to achieve better results within the current release...all this with one test scene, a lot of phisychal (in)coherence and some confused GI concepts...

i m not doubting ur capacities or neglecting ur achievments...but ur posture is way too harsh!

...oh...and regarding the last couple of days no wonder u get that post count in the other forum! (joking of course!)

[Micha]

...
PPT hasn't changed much from 1.47.03 (max, again), then and now it works well when used properly....
Share the scene (for the sake of comparison) and we'll have a go.
...

Fine, now it will be interesting. For example here you find the scene:
http://c4d.tistory.com/

[Micha]

yeaah...
this thread is pointless...
at ur 27 th post here and u have claimed a new - and better - rendering "process", argue about knowledge of older users...disregarding they r showing us a way to achieve better results within the current release...all this with one test scene, a lot of phisychal (in)coherence and some confused GI concepts...

Should I better confuse with more than one test scene.
I started to test this scene, because I have seen the nice results of vray at the fryrender forum. So, my goal was to get this result with VfR too. So far no extra scenes are necessary.

...but ur posture is way too harsh!

Sorry, I'm to enthusiastic and maybe I find not the right words. Excuse me.
It's a pity, that my images comparsion PPT vs. PQMC tell not enough. I would be happy if somebody could show me a way to improve my PPT rendering.

...oh...and regarding the last couple of days no wonder u get that post count in the other forum! (joking of course!)

... you help me to increase my post count here.

[Micha]

OK, here a test that show a disadvantage of the usage of more than one bucket: if one of the buckets has a more difficult calculation than the other, than the noise pattern of the buckets dosn't match. Maybe, Vlado could find a fix for that problem.

right half image show more noise than the other half

[ene.xis]

Should I better confuse with more than one test scene.

not necessarly...but one is driven to easily accept thet u might be jumping to conclusions (well...and u r!)

[Micha]

Be creativ and try to be open for new ways. Problems can be solved. Maybe Vlado like the method and see ways to solve problems.

[ene.xis]

micha...
what problem?
wich method? i see what u mean...but its not thinkable to use such process in production memory wise! u do realize this?