0
$\begingroup$

I'm using Cycles Render and exporting my model as .obj and .mtl files. I have a simple green diffuse material, but in the .mtl file, the color becomes a much darker green. The viewport color and the material color are the same (I know that the wavefront obj/mtl files use the viewport color).

It SHOULD be Kd 0.121568 0.364705 0.149019 (hex #1F5D26)

but it's exporting as Kd 0.010962 0.087569 0.015506 (hex #031604 dark )

Why is this happening?

.mtl file:

newmtl PineTree.001
Ns 96.078431
Ka 1.000000 1.000000 1.000000
Kd 0.010962 0.087569 0.015506
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.000000
d 1.000000
illum 2

Blender material:

Blender material

Improve this question
$\endgroup$
1
  • 2
    $\begingroup$ You are going to need to research colour management, and in particular transfer functions. Also note that Cycles is a scene referred model, which means your notions of 0.0 being black and 1.0 being white are incorrect. $\endgroup$
    – troy_s
    Feb 5, 2017 at 19:38

1 Answer 1

Reset to default
0
$\begingroup$

Like Troy said it's a color management convertion. In cycles colors aren't bounded to 0/1 range, this is scene referred datas. In .mtl files colors are stored in a 0/1 range, the display referred datas.
Look the Wiki for description of Wavefront .obj, scroll down to the section "Material template library" and subsection "Basic materials"
It's said that : "Color definitions are in RGB where each channel's value is between 0 and 1."

So with that in mind you couldn't expect a 1/1 between Cycles internal values and exported bounded values. Plus I don't know if you're aware that Hex values are gamma corrected in Blender. It looks like there is a transfere curve, I guess an EOTF curve, see here for more details : the-importance-of-terminology-and-srgb-uncertainty, the whole article is worth reading but there is a section about the sRGB EOTF transfer curve.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Thank you! Do you know how I could correct for this? The difference in color is pretty striking $\endgroup$
    – Nikki
    Feb 6, 2017 at 2:27
  • $\begingroup$ You could use the OpenColorIO Python bindings and roll the data properly through the correct transform. That would be an ideal, and a second less ideal solution would be to roll a custom sRGB EOTF function. $\endgroup$
    – troy_s
    Feb 6, 2017 at 5:10
  • $\begingroup$ I would add that for this topic knowledge is essential. $\endgroup$
    – Mareck
    Feb 6, 2017 at 11:47
  • $\begingroup$ Thank you both. I think I'm going to manually edit the mtl files. It's not worth it for me to spend the time learning about this and then write an algorithm to fix it. This must be a bug with blender. $\endgroup$
    – Nikki
    Feb 6, 2017 at 16:51
  • $\begingroup$ These are pretty unsatisfactory answers. I'm using Blender to model for Color 3D printing, and it's tendancy to take skin tones and transform them because it's "right" is just wrong. If assign a material #C39B7F, I expect #C39B7F, not #8B5436, which is what I'm getting. I've tried fixing the color curves, I've tried adjusting the scene's gamma correction, but whatever I do I can not get a 1-to-1 predictable color. $\endgroup$
    – Cymon
    Apr 5, 2019 at 5:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .