Strip Rendering Problems

[giancarlo_007]

Hi guys,

Just wondering if anyone can shed some light on why i'm getting variations in my strip renders using backburner. The two links are images of the same scene, one built up of 70 strips and one 35 strips. On the wood texture there are issues with the colour balancing creating lines the relative size of the strips. Not sure what could be causing it and if its just a certain slave computer that isn't rendering the scene correctly.

Its rendered using a Pre-calc Ir and Lc method on a shared place on the network. Never had this problem before and its only happened since I upgraded the machines to Max 2008 and V-ray SP1.

Anyway, hope someone might suggest a possible answer.

Many thanks in advance

Giancarlo

[Clifton Santiago]

Is your wood material reflective? Do you get scene origin or bounding box errors? If so, they can cause render errors (slight differences) between machines (both with DR buckets, or BB strip renders) on reflective or refractive materials.

If not, check that you are not running two instances of vray spawner on your render nodes. When I upgraded to 2008/1.5 SP1, I tried to have Vray spawner 6 and 9 running simultaneously so I could go back to Max 8/RC2 if needed. Somehow they conflict creating slight differences between DR buckets. Once I disabled vray spawner 6, the differences went away.

I now have a script that disables 6 and enables 9 (and vice-versa) across all nodes, without having to login and change each one.

[QuakeMarine1]

dont use split scanline for rendering
backburner render an overlapping between the strips of minimum 12 pixel top and bottom
so you render in total 24 pixel for each stripe without sense
in worst case you have more overlapping then image
use DR !

about the problem
check the "region and country " settings in your OS system
both/all PC should have the same or it will interpret the "." and "," in a wrong term
additionaly check if you have "LUT and gamma correction" enable (inside 3dsmax - properties)

[Clifton Santiago]

Everyone knows there is overlap with strip rendering and its slower than DR. But it has its place. Before SP1, there was no way to cue DR. You don't want multiple people sending DR to the same nodes simultaneously. And if your stills were taking longer than 10 hours via single node rendering, the only way to do the rendering was via strip rendering. Just try to render a 32,000 px wide rendering without strips (like I had to do the other day).

With SP1, for the first time, you can now cue DR via BB so you don't need to use strips in most cases.

But that's not the issue here. Whatever the specific problem, it is causing different machines to render differently (raytrace errors) so one will have the same problem with DR as with strips. In this situation, the DR buckets will render portions of the image diffently just like the strips.

[giancarlo_007]

hi clifton,

the material is reflective using a black and white reflective bitmap. i was using the strip rendering straight from backburner and didnt involve spawner although i am looking in to using that from now on. can you run dr spawner and backburner together? as in use backburner to queue the dr spawner jobs?

[Clifton Santiago]

Yes you can. It was a feature of 1.5 final, but didn't work until SP1. I got it working perfectly about a week ago, with the help of another forum member. Check this thread:

http://www.chaosgroup.com/forums/vbu...ad.php?t=40100

In the second reply, gregory lists the correct procedure for making it work.

[giancarlo_007]

thanks guys,

going to run a few tests on BB using DR as the renderer, it sounds easy enough to set up on SP1 so hopefully should be no problems and even cut down render times.

thanks again

[jonahhawk]

I'd like to give another good reason for using strips and how they can be faster than DR. If you have way more than ten nodes on your farm, over 100 in our case, sending a large image is way faster with strips. We always send images at 32px strips. Lots of small tasks for each large image. This frees up more machines sooner for other jobs/tasks. The faster nodes can get in and get more done, working the strips around the slower ones.

We just rendered a 10kx10k image on the farm. It basically took 2400 render hours. The farm finished it in one day. If the 10 node limit is still there with DR, this image would have taken a week.

@Clifton- I want to thank you for your posts and help with BB and strips. Your info has saved us several times.

I have one more question for you. How do you deal with BB doing double gamma on 8bit strip images? Sometimes we just need to have the BB output to be the final image for a client/design team to view. I guess, my short question is: what is your gamma setup?

thanks, and sorry for the hijak.

[Clifton Santiago]

I didn't know that BB doubled the gamma. It works great for me...

I use DR on BB instead of strip rendering now (we don't have 100 render nodes unfortunately), but even with strips I didn't have a problem. BTW, the DR limit is 10 machines per license, additive. If you have your license networked, you can have more than 10 machines working on DR on one image. In our case, we have 3 vray licenses which means 30 nodes (if we had 30). So you just need to have 10 licenses...

My LWF gamma setup is old-school : I have gamma 2.2 in Max settings w/bitmap input gamma of 2.2, w/affect colors and editor checked. I render to MFB and save as .EXR 32-bit. I don't normally do anything with gamma settings in color mapping. As long as I open the images in photoshop, they look correct, i.e. they match the MFB. One thing I have noticed though, if you open the strips before they are assembled the sRGB profile has not been applied yet, and they appear dark. So Max is not applying the gamma settings until the end. Maybe in the case of 8-bit images, the strips are corrected, and then corrected again when assembled. But specifying an override gamma of 2.2 in the save settings of the 8-bit format, should fix that.

[jonahhawk]

Cool, thanks.

I guess I'm old school too. I do it exactly the same. EXR works but with any 8 bit format, the gamma is burned into the strips and then again in the assembly. That is, when I set the gamma to 2.2 in the file save dialog.

Thanks for the tip on the licenses. I don't know how many we have but there are at least ten users in our office and then more in other offices. I don't think we have run out of them.

incidentally, our "farm" is simply the BB service running when employees log off. We're a large architectural firm and have potential for a few hundred nodes, at night. During the day, however, we average about 30 or so. We did just install a new Render Boxx with two quad core, dual proc nodes in it. 16 cores, but two nodes. that will be sweet with dr when we have time to install SP1.

Thanks for the info everyone.