I like the combination of LC+QMC. It produce images in high quality within a good rendertime. Often I use the universal method, but I don’t like set a fixed noise level. I would wish, we could get a mix of LC and PPT. The process could be: first a LC is calculated and than the final pass would refine the image ala PPT without predefined limit. Maybe we could call it PPT QMC mode.
Often if I use LC+QMC I think, I could render a little bit longer to get less noise, but to start again with new noise threshold is not a good solution, because I lost the previous calculation time. Or I set a to fine noise threshold and during the rendering I see, I have not enough time to finish my render within my deadline.
And now … with a trick this method can be tested immediately with a restrictions: the continious preview is not working.
(1) render a light cache for a scene and save it
(2) set read light cache
(3) set primary engine QMC and universal settings with very low noise level
(4) set bucket size at full image size - Attention: dual core user must set the bucket at half images size
(5) start render
(6) stop the rendering if you like
The disadvantage of the pure PPT is, that infinte bounce are used, primary and secondary engine are not independent. My idea is, to limit the secondary part with the LC calculation and let run the primary engine in “PPT” mode only.
Now I’m curious for the answers.
This christmas present - I will call it progressiv QMC (PQMC).
My previous PQMC tests has enabled “use for glossy rays” at the LC. Here at test with correct raytraced reflections (good to see at the table-leg). Again, better than the standard PPT.
I’m not sure i understand what you are proposing here, to be honest, so i’ll just limit myself at the exposure of some facts:
I think i read somewhere that LC is akin a photon mapping with 100 bounces (hardcoded).
LC does calculate both primaries and secondaries, however it’s used, anyways (hence the ability to use it for glossies or direct light storage).
So darkening the materials, or lowering the secondary multiplier would already cut the path tracing before the hundredth bounce, speeding up the rendering.
Supposing ppt works the same, a dark material with proper exposure makes the rendering a lot quicker, cleaner and manageable…
And ppt renders can be “resumed” at will.
One just has to use the external merging utility Vlado provided, and render different frames of a “fake” animation with “time independent” unchecked, so to vary the noise pattern and allow proper interference between different frames, to achieve a cleaner final render.
Lowering the LC multiplier would cause a wrong light distributation. So it is no way. The advantage of the LC is, that after a short time the lighting of a room is calculated (black dots are gone). If you let it render longer, the image will not be brighter. So, the LC give the basic for the lighting.
QMC - I don’t like to set a fixed noise threshold. I would like to see a continious refinement of the image. The primary QMC works for primary bounce only, so we could get a speed enhancement compared to the full PPT.
EDIT: extra advantage of this method - no limit of the rays per pixel like with PPT. I suppose, this method could render endless.
Vlado, could you make, that bucktets are updated with the current calculation every minute or so? So, this would be the simpliest change to get this PQMC method full working.
“Progressiv” QMC means, that you can let render the whole image and stop it every time you like and you get an image with an constant noise level based on the QMC method. Good results I get with noisethreshold 0 and full adaptive QMC 1/100.
If you use a smaller bucket size than your image size and you stop the render process, than a part of your image is rendered only. My PQMC method bring together the advantages of PPT and QMC.
I’m not sure I’m following what you propose, but I guess that if you stop the rendering half way, even with your method, you’d still get only a part of the image rendered.
I don’t see how this can be progressive qmc. at the end of the day what you’re describing is good old qmc with precalculated lc for secondary bounces, isn’t it? no matter how big or small those buckets are.
You are right, render times are long. My comparsion is PPT vs. PQMC only. Also I hope, this method is an inspiration to find more shortcuts for easy to use progressiv rendering.
Did you mean the PPT should be faster? Maybe the Vray for Rhino incarnation does something wrong. I would like to find the problem.
I must have lost something along the way, how this is different from standard qmc+lc? apart from the bucket size and the increased amount of memory needed for rendering with two of such size?
I think they want the QMC to work similar to PPT. Where it will keep refining the solution with out having to stop the render and increase the settings.
So we use the same method, but my method could rendered without to predeterminate the noisethreshold. Only I need an update of the preview every few minutes. The predeterminated noisethreshold is an disadvantage: if you set a fine noise, you could misss your deadline, if you set a raw noise you lost quality. The PQMC could help to get the maximum quality by this method in a limited time frame.
Example: the scene setup is ready and I think, I could let render the scene over night. Which noisethreshold should I use?
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…but u have no preview(!) and yes it must use alot memory…
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! :lol: …maybe it it could be paused/resumed…previewed somwhere inbetween…?
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.
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.
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.
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.
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.
…but id stick to standard qmc+LC!
)