I’ve come across a strange bug( i think ) that affects distributed rendering.
When adjusting a background plate material using the color correction map in max2009x64 the rendernodes don’t seem to respect the gamma correction setting I specify in the advanced lightness rollout(buckets coming back un gamma corrected). If I return the gamma to 1 and then set the gamma from within the file dialog in the bitmap itself, the rendernodes do respect the gamma-correction. This sees to suggest that the problem lies specifically in the color-correction map rather than any other gamma setting specific to the render nodes. This may be a max bug rather than a vray bug, but its definately a frustrating problem.
Can anyone replicate this issue? I have a feeling it can be intermittant as I don’t always have this problem.
No replies? This bug is killing me!
I’ve restarted my rendernode, replaced all the ini files in the rendernode to match the files on my workstation, removed any color correction, and still, my render node is getting the gamma setting wrong.
I know I must have messed up a setting somewhere… any suggestions?
Isn’t this just a check box in the preferences panel called “Load enabled state with max files”? So by leaving it off, the machines allways use whatever they were set up to use?
Do a search on your node’s hard drive for “max.ini” (make sure you include hidden files and folders in your search). It used to be in the Max directory in program files but since Max2008 it’s hidden in something like:
C:\Documents and Settings\Supervisor\Local Settings\Application Data\Autodesk\3dsmax\2009 - 64bit\enu
Then add the LoadEnableState=1 line under , mine looks like:
Our render nodes don’t have a Max license so it’s quicker to change the ini file than to use the PLU thingy to export a workstation’s license to every node.
My max.ini file matches the values you quote above, yet when I set a material gamma (through the file dialog) to “use system gamma”, the rendernodes are not applying the correct gamma.
If I set the gamma (through the image file dialog) to “override” then the node appears to respect the new gamma… but I don’t want to have to manually over-ride every map!
So, with my gamma settings in the max.ini file being correct, what other reason can there be for the nodes using the wrong gamma? and what steps can I take to avoid this problem?
I’m having a bad day…
Gamma problem is back. Can someone open the file below and see if they have the same issue when rendering on DR? Gamma is wrong for DR buckets.
I’m working exactly on that bug ! Actually working on the new solidrocks 0.75 version, i’ve exactly the same problem…
I’ve made a tool named “Share Lightcache”.. It permits to prerender the lightcache (and only the lightcache) on your main PC, save it, then launching immediatly a slave rendering, with all slaves in “from file” mode with the saved file. With this method, slaves starts immediatly the render, without having to calculate a useless lightcache.
But, while testing this tool, some beta testers and myself have encountered the same problem, with different gamm-ized buckets problem..
A beta tester told me that it happends when it modify the color mapping (!??)
we can discuss around this problem with pleasure until we’ll find a way
I’ve not noticed any pattern to the cause of the problem. It’s weird that merging the elements into a new file fixes the problem. The question is; is it a bug with vray or with 3dsmax?
I’ve reported it to my reseller and they have raised a support tag with aDesk… it will be interested to hear their take on it. I assume they can dig into a maxfile in more detail to find any corrupted data.
Your lightcache tool sounds interesting, although I didn’t realise the slaves calculated redundant lightcache data.
i’m still working on it i tell you informed of any news on it. As SR manages deeply all gamma stuff in max, i’m deep inside
about ShareLC tool, yes, many users uses the faster PC as main pc, and slower ones as slaves… with this kindof configuration, slaves takes more time to render the useless lightcache than main pc.. so they starts late the second pass with a lag. SolidRocks just automates the avoinding of this problem, doing that for you
For this scene you might as well disable the 3ds Max gamma correction altogether; the settings you have chosen don’t have any effect on the scene bitmaps or output.
Thanks for looking at the file Vlado, but the strange thing is that when I load the file I posted on the forum, the gamma is 2,2 with input gamma at 2.2 and output at 1.0
According to Tedi, the file has default gamma (1.8) and input/output 1.0 .
Any reason why we report different settings? I do have “load enable state with max file enabled” .
Well, it appears that 3ds Max only remembers whether the Gamma was on or off in a scene. It does not transfer the gamma values as such. Since on my machine, they are set differently than your machine, we get different results.
This means you probably need to ensure that all the render slaves have the same input and output gamma settings.
We could probably make V-Ray to transfer those values with the scene for DR also, but right now you’ll have to do this manually.
As far as I was aware, my nodes are all setup with the same gamma. Infact the main node in question was previously my workstation so will be running all my defaults. In anycase, I copied my max settings (under my login username) to the node and the problem remained. It was only once I checked all aspects of the node setup that I could only conclude that there was some issue with either max or vray and the file. The fact that merging the scene into a new maxfile fixes the problem clearly demonstrates that there is some kind of corrupt setting within the maxfile.
I managed to finish this specific project without the problem occurring again, but opening the file included in this thread brings the strange node behaviour back again.
My bet is its max that’s causing some corruption of the file, and nothing vray related.
Can you try the file again and use the following gamma settings? It would be good to check that the fault is recreatable on another DR setup.
Enable Gamma : ticked
Load Enable State : ticked
Gamma :2.2
Affect color : ticked
Affect Material editor : ticked
Input Gamma : 2.2
Output Gamma : 1.0
I’ve had autodesk look at the file also, but they threw it back in my face due to the involvement of a third party plugin…
