I’m using for the first time the ppt mode of vray to render a lift with loads of glossy (inter-)reflections…
It’s SO quick i’m getting excited every time i push the render button.
Previous tests with standard rendering methods led to very long rendertimes (over 9 hours on my AtlhonXP 2250 mhz) and lots of grain, even at the highest subdivs levels.
Ppt is resolving loads of tiny modelling detail with great accuracy, and converges VERY quickly to an acceptable noise level, no matter what i throw at it.
I hope i’ll be able to post an image when the job’s done.
Yeah, I’d like to see what you mean by an acceptable noise level. My tests have required loads of time to get it to a level I think would be good for broadcast TV.
here's a crop of a testrender (watermarked, sorry…) at 288*512
Edit: ALL the surfaces in this picture exhibit some degree of glossy reflectivity (from 0.975 to 0.6), even though it’s not quite visibile at this size. There isn’t one surface without them.
I’m not speaking about broadcast animations, though.
Rather, architectural/design viz.
I left it running when i left home to do some shopping for food, and came back.
I’d like to stress that this was clean-ish after under 10 minutes of rendering(250 or so samples per pixel).
This was stopped at 1h51minutes (1155 samples/pixel).
I will let you know more precisely what kind of sampling is needed to get it properly cleaned at the target resolution of 1024x2048.
While ppt doesn’t work in DR mode, you still can split an image across several machines. However, this would only work for still images:
(*) Uncheck the “Time-independent” option of the QMC sampler.
(*) Uncheck the “Clamp output” option in the Color mapping rollout, since we want HDR output.
(*) Even though you are rendering a still image, set the rendering to an animation range.
(*) Make sure you are rendering the animation to .hdr images.
(*) Use backburner to render the animation.
(*) Blend the resulting images in an image processing program.
Since each image has a different noise pattern (because of the time-independent option), blending them would have the effect of averaging the noise and thus reducing it.
Rendering to .hdr images is essential, as otherwise you will not get a correct averaged result. Programs that process .hdr images correctly are rare, but if anyone is interested, I can get them a program that does the last step - blends a number of .hdr images into one final image.
I used this approach to render the image for the “Caustics II” thread, although in that case I used photon mapping and not ppt, but the principle is the same.
I’ll give it a try as i get to the studio on Monday
BTW, results are really really good as things stand.
I asked just as an icing on the cake
one more question, though:
is there a difference in rendertimes if materials’ diffuse value + reflection value exceeds 255?
I’ve seen a thread on a competitor’s forum (one that has a similar, but less efficient method that ppt :lol: ) that explained how that would change for the worst the rendertimes and the quality of the output image in terms of contrast.
I can’t say I noticed a huge difference so far, but some higher range noise did pop up with a plastic that exceeded the 255 value.
Was it my perception, or it does matter to an extent?
“Unbiased” and all of that is getting to my imagination, i guess…
Now now..
So i rendered my 2048 image overnight, stopped at 5 and a half hours, and am happy, but it’s not quite there yet.
So i move to frame 1, render for another couple of hours, then blend the new image back in the old one.
Voila’, VRay’s ppt has a “Resume rendering” function
Oh, and it’s not disabled in this release, either… :twisted:
Now, what was the proggie you were talking about, Vlado?
I was thinking of using combustion with some weird blendmode on rpfs or exrs, but i guess there’s better…
Photogenics can do it? It seems spot on for HDRI painting and retouching…
Ideally the images should have similar noise levels, yes. Otherwise, you have to weigh them appropriately based on the noise levels (e.g. more noisy images should have lower weight). But it’s easier if all images are similar (e.g. with the same number of light cache subdivs).
There’s a usability problem there though: i’d have to know what number of subdivs is good enough before rendering the final frame, rather than doing like i am doing now, cranking subdivs to 65k and stopping at leisure when the results have converged enough.
EDIT: The problem seemd to be in the fact that using Max’s own VFB (and interrupting the render) would save images as clamped, while using VRay’s HDRIs are saved properly.
So there is no usability problem, as long as the speed of the network PCs is the same, and the renders are started at (roughly) the same time.
I’d try the weighing, knowing which is the procedure… :roll:
Well, instead of setting high subdivs and stopping the render, you’d have relatively low subdivs, but render lots of frames… in this case, you can also at any moment grab the rendered frames and do the final image.
If you start it at the command line without arguments, it will print a short usage notice. Currently supported formats for both reading and writing are .png, .hdr, .bmp, .jpg, .tga
