reflectance inconsitency between workstation and TRS


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.


It appears that there is a difference in how the speculars render on a Mac versus a PC.

My workstation is a mac. The farm is PC. The PC’s produce the blown out reflectance speculars. Anyone know why?


Hey Joel -

Is this Physical, Standard, or other render engine?


extra text


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.


These days I don’t call it rendering anymore. I call it “experimental output on a deadline.”


LOL :slight_smile:

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.


Seems like the issue here is how TRS handles a job that has multi pass turned on.
In this case I rendered a beauty pass and also had several channels active in multi pass.

When we turn OFF multi pass in the file and render on the nodes via TRS we get correct results in the beauty render.


hey joel

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



Thanks Dann for the info!

When I have a chance (deadlines today!) I’ll send off to Maxon.
I kind of remember reading about a multipass issue like this before. I dont understand why however its only happenning on TRS.


ok another test came to mind to try to narrow down the culprit!

this does not seem to be a TRS (Team Render Server) issue so we have be careful to say TRS as it is not the Server apparently

it is the Team Render client - that appears is doing it

to try to confirm this i just sent the same test with MP ON from my C4D app using the Render Queue to the TR render nodes (so NO Team Render Server involved)

result - blown out still

R19 C4D using RQ MP on RGB - bad
R19 C4D using RQ MP on RGBA from MP pass - bad

so this avoided TRS completely and does seem to squarely point the problem at the Team Render client - as the C4D app performed the b3d to PNG conversion using the Render Queue

and the C4D app itself renders the project GOOD when rendered within the app (not using the Team Render nodes)

hope this helps maxon track this bug down



sorry dupe post


Thanks again!

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.


ok to test this i just took the same scene and changed the render engine to Standard

had to run one via the Team Render client using the RQ
and another using the C4D app itself

as obviously the Standard result looks slightly different then the render from the Physical Render engine

the Standard Render engine using the RQ and TR looks less shiny then the physical render from C4D (the good version) but still kinda more shiny

the Standard Render engine using the RQ and TR compared to the Standard Render engine right from C4D itself - looks more “correct” i.e less shiny and much closer to the Physical render result

so it does seem Standard Render also blows out the specular when rendered through Team Render Client



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.


yes but the “alternatives” costs extra money for a third party render manager and command line rendering options. so hopefully now that it has been identified it can be caught and fixed.

the other option is when rendering and needing multipass is to do one render of just the main RGBA standard beauty pass

then the next render of all the multi-passes and trash the RGB beauty pass from that job and use the first.

at least that costs no more money and uses standard Team Render, but does cost in render time expended and a tad more organizational planning



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.