We had this problem on mulitple projects meanwhile:
The problem becomes apparent when network-rendering through Backburner. Some machines seem to interpret single bitmaps differently, looking like different gamma values, but that is a vague guess. Maps are always included.
The weird thing is, that it is only affecting single bitmaps here and there, but in the end it made animation rendering quite unpredictable sometimes. Even if we tried to nail down the gamma-value in the bitmap dialogue, the problem persisted.
The machines in our studio are mostly very similar in architecture (I7, Win 7 Pro, Max 2014Design, same Vray-Built, etc. ). Weirdly we really had one half of a dozen that rather preferred to render the image one way, the other half differently.
Could not nail it down yet
Here’s a small video preview:
And we had this in several projects now, sorry, actually a lot of them. I am happy to mail a scene to you, if you provide me a contact.
It seems to be a bug in 3ds Max 2014 (not sure if it’s fixed in 2015) because of the auto-gamma setting for textures that was introduced; it seems like this is causing a lot of issues. I’m not yet quite sure that there is something that we can do about it, though we will try. For the moment, the most reliable way to fix this seems to be to use the VRayHDRI loader rather than the 3ds Max Bitmap texture.
I might try to render the whole thing with scanline/mental ray for testing …If you can do that, it will be very helpful to determine if this is specific to V-Ray. We’ll also try this with your scene that you posted.
Ah, I did not post the scene, since I can’t make the model public, but I can send it to you if you give me the right adress - got it packed already … or should I send it to support@chaosgroup.com ?
We’ve did an extensive tests on the sent scene including rendering with V-Ray 3.00.08 / Scanline / Mental Ray but we were not able to reproduce the issue at all.
May be we are missing something from your pipeline or from the scene or from the workflow and that’s why the issue does not occur here.
We have tested a few scenes on that matter but all of them worked fine here, there might be something else involved here so we need to know every detail like:
versions , service packs, installed plugins, user account types, firewalls, log files,recorded videos/gamma setting and etc.
Since we are still not 100% sure that this is V-Ray issue it would be very very helpful for us if everyone who gets this issue convert all Bitmap-nodes to VrayHDRI-ones via Vray HDRI Converter tool and let us know if the issue is still there even if all the textures are loaded via VrayHDRI-map.
1. As I already pointed out, I could reproduce the error in a simple scanline scene, by just applying the texture to a simple standard material. No Vray involved, but Problem still there.
2. Using VRayHDR = problem gone, thanks guys! (s. attach.)
In our case back we could really distinguish between computers that would behave like A and others like B. We ended up splitting the animation in two rendergroups, but obviously that is suboptimal :(. Maybe your machines are all behaving “unisono”.
Strange is still: The texture at hand is a JPG, no much I/O settings there to remember ?!? I know that HDRs and TIFs were problematic storing fileinformation, compression, Depth, etc… … but JPGs?
Thank you very much for the feedback.
Glad to hear that VrayHDRI map solves the issue.
At least we have a workaround until Autodesk provide fix about this bug.
