Indigo Renderer 3.6.4 Beta Release

[CTZn]

"albedo shaders must be gamma corrected;": According to whom? Why?
According to the sole me of course, I'll have to double check about that.

Here's what I got, from left to right:

RGB 0.25 0.25 0.25 @ brightness 1.0
vec3(0.25)
vec3(pow(0.25, 2.2))

[OnoSendai]

I'm curious about that !

Issue when loading back an IGM of a coating material: the substrate has no name and no type showing up, and Indigo will lost the reference to the node after the first material edit.

Same issue when loading back a double-sided material, win64.

Thanks for bug report, fixed.

[OnoSendai]

"albedo shaders must be gamma corrected;": According to whom? Why?
According to the sole me of course, I'll have to double check about that.

Here's what I got, from left to right:

RGB 0.25 0.25 0.25 @ brightness 1.0
vec3(0.25)
vec3(pow(0.25, 2.2))

When a user enters RGB 0.25 into the GUI, they are entering a value in a non-linear space, e.g. the colour will get raised to the power of 2.2 (gamma).

When you write a shader that returns RGB values, the values are used directly for the albedo, e.g. they are in a linear space.

[CTZn]

I got that point, there is no reason to jump to a nonlinear space just because one is using a vec3 wich does not necessarily describe a color. Vectors may retaliate !

However the consequences are immediately a bit blurry to me when writing albedo shaders. I've never been "correcting" vec3's outputs from their linearity while I should have, shouldn't I ?

If I'm making sense it would be handy to have a vec3 type of function that would handle the color space conversion, for albedo outputs mainly and preferably hardcoded ?

I'll be testing further myself to clarify a bit but I'd rather keep going on my fruit generator: apples, tomatoes and lemons from spheres hopefully (the apple object above is handmade) !

edit: you'd rather have a good week-end ;)