aRtBee opened this issue on Oct 17, 2011 · 76 posts
RobynsVeil posted Mon, 17 October 2011 at 6:32 PM
Unfortunately, I think in linear terms. Which makes concepts like Poser classes and OOP and gamma such difficult things to process. Blame my procedural programming background... it's held me back from "getting" some key things.
When we first discussed material GC, and coded for it, since the code looks like it would be processed linearly, I sort of thought Poser (Firefly) processes colours in some sort of sequence:
x = image that has been corrected by camera or whatever: can be seen and appreciated by human vision on the monitor as correct, or any colour that isn't part of the Color(0,0,0)/Color(1,0,0)/Color(0,1,0) etc group
gamma = 2.2
def antiCorrection(clr): return clr ** gamma
def Correction(clr): return clr ** (1 / gamma)
processColour = antiCorrection(Diffuse(x, .8))
shader = Correction(processColour)
So, whilst this looks like one could say: "we start with a colour here, anti-correct it, process it then correct it again", where and how this all happens can't be clearly identified as specific locations. I know this sound very difficult to understand, but that is the bane of linear thinking: I still do try to identify steps in a process (this happens in the POW node, this happens in the Diffuse node, now we give back to a POW node so that PoserSurface has the right information to give to Firefly to paint with) as opposed to just accepting that it's all sort of a finished product.
Which makes renderer GC and what all happens so obscure. Unless I stop thinking linearly. Then it makes sense.
Monterey/Mint21.x/Win10 - Blender3.x - PP11.3(cm) - Musescore3.6.2
Wir sind gewohnt, daß die Menschen verhöhnen was sie nicht verstehen
[it is clear that humans have contempt for that which they do not understand]