Let's fix Cycles finally, and add MaterialX shaders
If you ever have wondered why Blender is utterly useless to anyone doing professional work.
This isn't a regression, it's always been this way in Blender, and it's causing incorrect Diffuse values, Halos, and other shenanigans contributing to the infamous "Cycles/Blender Look".
As all shader and Lights operations are inherently non-energy conserving "BSDFs" in Cycles.
And Blender devs just rest assured that their BSDFs "follow the Pixar paper", but then Renderman would have the exact same issues right? -but it doesn't.
This can't be explained away with a simple, "we followed the pixar paper". After investigating and hearing some more talks on the topic by renderman engineers, it is the case that the calculation aren't energy-conserving themselves, but that they clamp the results to fall in the expected range.
Even more baffling is the assurance that they followed the Pixar paper to a tin when Blenders BSDF has fewer Settings available than in renderman.
To be specific the settings that were outlined by Brent Burley's extended material model, introduced in "Extending the Disney BRDF to a BSDF with Integrated Subsurface Scattering" at SIGGRAPH 2015.
Has following missing settings, not present in Blender.
-Thin Surface
-separate controls for Transmission for Diffuse and Specular
-Transmission Distance.
-Transmittance Distance
Later crude additioins to Blenders "BSDFs" like the "Subsurface IOR" aren't outlined and are NOT present in Rendermans shaders at all. As the already existing IOR settings influence Specular and Subsurface. Having two different values is physically incorrect.
But let's not get lost in the past, and fix problems of yesterday, but make it new. This will also have the added benefit of Blender actually being compatible with most DCC apps.
Oh and please bring OSL support for GPU, thanks.
This is all I'm asking.
Also, I don't want to sound like a parrot but the last post about this is 2 years old.
5 Comments
Have you seen this? developer.blender.org/T99447
And also this: "Principled v2" feedback/discussion thread - Cycles Development - Blender Developer Talk
Definitely go there to talk in more depth about it.
As for OSL, I can't find where it is mentioned exactly, but I think it is planned, I guess the issue is that it will need time, and so far not scheduled.
There was an attempt at it back in 2016 developer.blender.org/D1745
But if I understand it correctly, it was canceled because that attempt was doing it the wrong way.
I like Brechts answer on this.
"Developer time should not be spent fixing bugs" Ok well, janky software it is. Probably the reason why this additional OSL subset wasn't approved but still.
The current one, isn't complete neither.
I also don't get his fixation on custom noise patterns in OSL, that's litterly the last thing I would think of to use OSL for. lmao
And the revision was not refused nor disapproved, it was abandoned by its author.
Besides, you paraphrased Brecht a bit too harshly IMHO ;)
That's not a dev saying devs shouldn't spend time bugfixing nor complaining that it isn't a complete GPU integration of OSL.
That is a dev worrying that, with the current resources they have at the BF, this revision isn't maintainable and won't profit people as much.
It's like when building a house and someone wants to come do the electric wiring. He won't be able to do all the remote control stuffm and will only take care of the garage, but he does it for free. Cool right?
But he does it by adding exposed wires here and there, burying some in walls, ceilings and grounds, leaving cut marks behind, rerouting lines somewhere else, and leaves everything undocumented. Sure, now the garage lights up, and the door automatically opens, but the toddler can play with exposed wires in the entire house, the lightbulbs explode after a week of activity and nobody knows how to fix the kitchen oven not turning on when the garage door is closed.
Not my best analogy, and harsh on the electric guy, but I think it's a bit the idea. Kind of. Probably.