Recent searches
Search options
Apparently Blender .obj importing is a bit broken for emissive objects: it imports a [10,10,10] emission value as raw color (which should be in 0..1), while leaving the emission strength at zero (meaning the object does not, in fact, emit anything)
@lisyarus is this about emission per surface area vs emission per full area conversion maybe?
@breakin Btw I've already tracked the issue in code, look here if you're interested: https://projects.blender.org/blender/blender/issues/135073
@lisyarus Makes sense! Converting between material systems is a lossy and sometimes not fun exercise but good if it becomes better!.
@breakin @lisyarus I spotted the same issue in my own code ( https://avoyd.com/ ) yesterday when I added support for emissive factors > 1.0 in my non-texture based export pipeline for .obj. Many thanks for submitting an issue (you beat me to it)!
As you found, using a texture map for emission fixes this, and that's the main approach I use to export material parameters, but it's harder to edit so I still keep this option available.
@dougbinks @breakin I've just submitted a patch, hopefully this will be fixed in the next Blender version :)
@lisyarus @dougbinks @breakin out of curiosity, is there any kind of agreement what color space the mtl quantities are in? is emissive linear? are Kd/Ka linear? what about textures that don't advertise their color space?
(we're currently doing lightmap baking with user-provided .objs that are usually emitted from some adobe/autodesk product and I've been struggling to get the full-pipeline srgb story straight...)
@artificialmind @lisyarus @breakin I think colour values are linear but textures are expected to be sRGB.