I am getting a weird difference in my renders when rendering on the farm compared to my workstation. Speculars are blown out. Seems to be a reflectance issue. All nodes and local box are running 18.057.
Anyone ever encounter this before?
Top is how it should look (rendered on my box)
Bottom is rendered on the farm.
You can see on the bottom right how sharp the specs are.
Also wondering if theres a bug in multipass. I had specular selected as a separate pass. Wondering if maybe TRS is trying to merge the specular into the beauty when it saves the file? But I still get a separate specular pass. Weird.
And I wonder if you had a mixed farm, if you would see different speculars depending on which node rendered it (Mac or PC) or if they would all look blown out. I would hope they would all be blown out on a mixed farm. Then it is a controllable thing. (still not a good solution, but at least you would get consistent frames regardless of Node platform)
Do you have another network renderer laying around you could try a few frames on?
I would be tempted to add your mac as a render machine and run a few frames, making note of which one(s) the Mac renders. Of course this assumes you have lots of free time on your hands, which I’m sure you don’t.
Im using an offsite farm so cant really test. My feeling is that it is a TRS issue as I thought before. We tried rendering on a PC locally and getting the same results as my mac, so its not a mac vs PC thing afterall.
The test above was rendered on a node via TRS. Trying on another farm now that doesnt use TRS to see if theres a different result.Have no idea where this odd render difference is coming from.
its subtle and not the end of the world, but enough of an issue to create a very noisy animation with all those blown out specs.
i’ve seen this issue before - was doing a bunch of testing today to try to track it down better - of course before when i saw it was on deadline so just worked around it somehow can’t remmber
here’s what i have found out from testing
a file with bright specular is coming out extra specular IF and only IF the multipass is turned ON
files are saved to png but other formats show same blown out specular
R18 mac C4D - good
R19 mac C4D - good
R18 TRS MP on - bad
R19 TRS MP on - bad
R18 TRS MP off - good
R19 TRS MP off - good
R19 TRS MP on 8 bit rgb - bad
R19 TRS MP off 8 bit rgb - good
R19 TRS MP on 16 bit rgb - bad
R19 TRS MP off 16 bit rgb - good
R19 TRS MP off using DR - good
R19 TRS MP on output to TFF instead of PNG - bad (so seems not file format related)
R19 TRS MP on but extra MP spec channel off - bad
R19 TRS MP on, RGB off and output RGBA from MP - bad
also managed to grab a .b3d file from the TRS before conversion - and looked at it in picture viewer - it was the MP ON with no spec mp pass version - and it too was blown out looking in picture viewer - so that seems to negate the thought that it may be the TRS server somehow blowing the spec channel out in b3d to output format conversion.
all tests in the C4D app itself are good - and one test of command line render seemed good too, so it seems to be in a bug the Team Render render client that this Multipass ON = specular blowouts is happening
so another question if maxon is reading - is the command line version of C4D essentially a faceless C4D - in that it performs the b3d to output format conversion itself and sends that result to the third party render manager and does not need/rely on the TRS to do the conversion from b3d to output right? was thinking it must be so since there is no b3d to output format conversion taking place with the third party render managers.
strange but at least there is some more data to work with
This is really bizarre. Does the client use a different version of the render engine? Or maybe it composites the results together differently than the main app does?
Also–have you tried rendering in standard or physical?
I’ve been rendering my tests using physical. Havent tried standard yet.
This is interesting, and upsetting honestly. After reading this thread, we tested the behavior out over here at Cake, and verified it. Of note, we use Deadline primarily for our DR, and so we ran the test on deadline as well. That frame was identical to the regular single-machine render, meaning that the issue seems to be isolated and specific to TR.
So, while the fact that it happens at all is no good, at least we know that people needing to DR aren’t unilaterally hosed, they just need to venture outside the ecosystem.
FWIW, Deadline is a pretty fantastic, robust, and rock solid render manager, working just as well with After Effects as it does with Cinema.
Hopefully Maxon fixes this issue soon, but if not at least there are alternatives.
True, but then most things that are worth it do cost. Even without this glitch, I have found Deadline to be far superior to TR. If you do a considerable amount of local distributed rendering, it’s a worthy investment.
Having said that, I share your hope that the issue will be located and eradicated quickly, as those who for financial or other reasons must use the in-built system deserve to have a reliable, and workable tool, especially considering the cost of the program.
All I really wanted to do was help solidify that this issue is unique to TR, and not a flaw that extends to other DR managers.
Interesting; over the past year I’ve had consistent gamma issues that involve Vray, the Linear Workflow Checkbox, enabling Multipass, and Render to Picture Viewer vs. Team Render to Picture Viewer - issues that appear only on my workstations and not those of the Vray devs. I’ve found a workflow that I can use in production, but it’s still annoying. Now I’m wondering if it’s related to this somehow.