SDK import error

Hello,

Im working on textures right now and testing importing from blender with SDK importer.

When importing I get this error,

The texture Diffuse Color has linear color space, but the material parameter DiffuseMap specifies no color space requirement, this may lead to unexpected behavior.
Check if the image was not set to another material parameter with a linear color space, or that you did not set the ColorSpace to Linear using texture.getImage.setColorSpace().
  1. The colorspace for the texture is sRGB not linear.
  2. There is one material, one image, one texture. Not possible to have a different material for image if one doesn’t exist. Its not set in code either.
  3. After import, the colors are dull compared to original, if I create the .j3o material file they are the same as original file. Ogre export is perfect with no changes needed.

I have tried setting and unsetting everything I can in blender but the error still shows on SDK import. Is there a setting I am supposed to set somewhere to make this error go away and the model to import directly without having to use a material def file?

Thanks in advance.

Edit: I should add there are no other images, materials, or textures in the drop down lists for each respectively.

Actually this is a warning and I think I also had that from time to time.

The question is if that really is the Source of your dull looking colors.

Do you only see this upon Import or each time you open the model? (In the latter case you can maybe specify that in a custom Material (setting the Colorspace)

This might be a Bug in the blender Importer

Sorry for the delay,

The error only shows on import.

The color difference is always there after import each time model opened or just used in the scene.

If I use a custom material file and only set the color map / diffuse map then the colors are correct whether using unshaded or lighting def.

Generating a .j3m from the object using the SDK also works but adds shininess and Parallax height.

Commenting out the set material line brings the dull colors back.

Well then you could also set the Material in the SDK so you don’t need to have that line in code as a Workaround.

I guess one could try to find that Issue in Blender Importer, but chances are low that it’ll be fixed. If you want to go on that adventure though, have fun :slight_smile:

Ill eventually try to help on SDK but as I know nothing about doing so it would require another several week distraction for me to learn what’s going on.

I suspect there is some obscure buffer being read somewhere that shouldn’t be, but that’s just a guess based on my experiences with the importer not being able to distinguish between unused materials or textures sitting in a drop down list and those that are linked to an object. Unlike the Ogre exporter which seems not to have a problem doing so.

I find myself having to backtrack a lot and clean up unused things when using the importer because of it.

I’m really not partial to relying on Ogre (even though it works best) since its not open source anymore, we have to rely on others not associated with the Ogre developers to update the blender script, and its quite expensive.

You did confirm its not something I am doing to cause it, at least not something that’s blatantly obvious.

Thanks again.

Note: We are talking about jme3-blender which is a engine module, the SDK is only the fancy window around it.
The Problem is I tried looking at the blender sourcecode but the .blend file format isn’t so easy to understand and the importer itself is a bit complicated.

Technically you can also try xbuf which bypasses the blend file problematic by having an own file format and is a blender addon. The SDK is even able to read xbuf and convert it to j3o directly, you only need to export xbufs from blender using the addon

This is the key. I just realized what you meant by this after watching the JME SDK Usecase Demo 2 by Norman. I have been doing this in my own version of blender trying to apply the things I learn in the wiki to what I know about blender. I can create and do just about anything I want in blender but that doesn’t mean its the right way for the SDK.

I think its to do with how I am mapping things. After I work with the SDK blender UV mapping box I think I will find out what I am doing wrong or what settings are off in my version.

Shot in the dark here (I use ogre) you didn’t tick ramp, or untick clamp by accident (at the bottom)?

No.

I was using texture paint and its set to generated. You unwrap to a blank image in the uv editor. After painting it I was saving the image which changes the source from generated to image under textures/image panel/source. This is what causes the error to show. If I don’t save the image it will import with no errors but the SDK will set the colorspace to Linear so the colors all look like there’s a white film over them, ie dull looking.

There’s a blurb in the wiki that says,

Its important to note that each used texture will create one separate geometry. So its best to either combine the UV maps or use a premade atlas with different texture types from the start and then map the uv coords of the models to the atlas instead of painting on the texture.

I think what’s happening is once I save the image I need to remap it as if its an atlas. I haven’t tried it yet.

Ok, after more testing of things I even get the error using jme3-blender files.

Using a texture atlas made no difference.

Just in case its me here’s what I did,

Selected Diffuse in textures.
Loaded Atlas for texture.
Set Packed.
Applied Triangulate modifier to cube.
Smart UV Project unwrap.
Selected atlas image in UV editor.
Aligned map to model.
Saved.
Converted blend to .j3o
ERROR.

I will stick to material def files because they are perfect.

I confirm having the same issue as well.
I also used “Texture painting” in Blender

The only fix I found was using Ogre exporter.

Bumping this old thread, since I encounter the same issue for a long time now.

I created an issue for it on GitHub with some more information in it and a possible fix:

I’ll create a PR for it as soon as I get some feedback of the more senior monkeys around here :wink:

1 Like

A little bump for this issue and related PR.