Blender issue with multiple uv sets

Hi all,

so I wanted to enhance my blender scenes with a little bit of uv mappings and stumbled on the setup knee deep into trouble.

So I thought ok, follow the satandard example provided by the docs, but event that oune did not work out. At least from a blender -> jme point of view.

@Kaelthas could you explain what to set up in blender to get texcoord2 getpopulated from blender, because nothing I tried worked so far.

The documentation states add a second texture, with its own texture coordiantes. I checked even the example file provided with the documentation and that one also shows the problem. The ogre file provided in that example does convert properly, as it contains 2 texcoords. But why does the blender importer does not create them?

I also noticed an issue filed for texcoord in the project, but that one is quite old and seems to hint at a solution already present.

link to the issue

link to the lightmap documentation and example file

Make sure you have latest blender loader. As texCoord2 was implemented recently into blender-importer.

In other way - ogre works perfectly.
For example, this (ogre) model works perfectly for lightmap:
https://code.google.com/p/jmonkeyplatform-contributions/source/browse/#svn%2Ftrunk%2Fshaderblowlib%2FShaderBlow%2Ftest-data%2FTestModels%2FLightBlow%2Flightmap

@ghoust

The importer tries to optimise the amount of uv types the model needs.
This is made because of two reasons:

  1. the memory usage
  2. the fact that jme supports up to 8 different UV coords buffers while blender can have more than 8 textures applied

In the first step, the importer reduces the amount of textures it needs. For example if your model has 2 textures and they are both without any transparencies, the importer will only use the top most in order to save memory (because the other one will not be visible at all).
And the second optimisation is joining the textures of one mapping type (color, bump map, etc.) and store them under one coord type in order to be able to load all of them if there are more than 8 textures and to save memory used for buffers.

But now that I think about it, maybe it would be worth to give user the ability, to disable these optimisations. This would allow to use all defined UV coordinates.
What do you guys think about it ?

@Kaelthas said:

In the first step, the importer reduces the amount of textures it needs. For example if your model has 2 textures and they are both without any transparencies, the importer will only use the top most in order to save memory (because the other one will not be visible at all).

Does this first step also apply if the first texture is used for color and the second for displacement (normal map) ?

Would a workaround for creating two texccords be to switch on transparency on the light map and off on the diffuse in blender to get the second uvs exported?

For the optimization: currently the focus is going by texture, why not turn it around and optimize it by uv coords? blender can have more than 8 textures applied, but this would not be 8 different uv sets used.

What I would expect is to the n textures exported and m texcoords exported. On my side I would be fine having an exception stating you have to many uv sets, or at least a warning about an optimzation trying to reduce the amount of a) textures, b) uv sets. But please do only optimize if it is needed at all.

My setup has 2 textures, each with its own texcoords, so why optimize? anything is within the limits…

@ghoust

The optimisations are being done even if you have less than 8 textures to reduce the general amount of memory used by the model. Remember that usually you have more than a single model in the game so every piece of saved memory is worth an effort.

It is made so also because it might be easier for developer to have separate textures in the model using different UV coordinates while the model is still being tested and altered during development. But the end effect will not need this separation.
And here is the reason why I think the ability do disable these optimisations shall be used. Because it might be an intention of the user to have separate UV’s to be able to dynamically replace textures at runtime.

And answering your last question about the optimisation way: by textures or by UV’s. The optimisation by textures can give better results since textures are much larger than a UV coordinates set. So it is better to join several textures into one than several UV’s. :slight_smile:

I will add a boolean setting to the blender key that will allow to disable these optimisations. I will let you know as soon as I make commit.
But I think the default value of this setting will be on optimisation favour so just remember to set it in the blender key.

@Kaelthas said: @ghoust

The importer tries to optimise the amount of uv types the model needs.
This is made because of two reasons:

  1. the memory usage
  2. the fact that jme supports up to 8 different UV coords buffers while blender can have more than 8 textures applied

In the first step, the importer reduces the amount of textures it needs. For example if your model has 2 textures and they are both without any transparencies, the importer will only use the top most in order to save memory (because the other one will not be visible at all).
And the second optimisation is joining the textures of one mapping type (color, bump map, etc.) and store them under one coord type in order to be able to load all of them if there are more than 8 textures and to save memory used for buffers.

But now that I think about it, maybe it would be worth to give user the ability, to disable these optimisations. This would allow to use all defined UV coordinates.
What do you guys think about it ?

This is my feature request too. I don’t need UV optimizations at all. As I import only meshes without any materials.

And i f i need to optimize anything - I do it directly in blender. I can delete unused UVs in blender with one click.

Please, add this feature. And it would be cool if this feature will be SWITCHED ON by default. Because we convert blender models in SDK-blender-converter which has no settings.

Thanks.

2 Likes
@Kaelthas said: @ghoust

I will add a boolean setting to the blender key that will allow to disable these optimisations. I will let you know as soon as I make commit.
But I think the default value of this setting will be on optimisation favour so just remember to set it in the blender key.

@Kaelthas I respect you a lot and i know that you want to make it cool. But take a look:
We convert blender models to j3o in SDK (not in code mostly). Rightclick - convert blender j3o. And we need the optimizations to be switched off by default. This is really important.

In Unity3D - I can import fbx model with all UV maps without any issues. And Unity does not make any strange optimizations.
All optimizations should be made by a user directly in blender.

In other way - you will need to make changes for SDK blender-plugin to switch optimizations off.

I would second mifths position, though for the sdk plugin I have one suggestion how to make both use cases happy.

You can expose settings in the options panel. That way any user could set a flag if he wanted to use that optimization or not. Even if you would decide to be generally on, the users could override this setting if they wanted to.

how about that?

@ghoust said: I would second mifths position, though for the sdk plugin I have one suggestion how to make both use cases happy.

You can expose settings in the options panel. That way any user could set a flag if he wanted to use that optimization or not. Even if you would decide to be generally on, the users could override this setting if they wanted to.

how about that?

The issue is that blender-sdk-plugin is made by a different person. And @Kaelthas does not maintain it. So, we need good default settings. Without optimizations.

That’s my point.

I agree too, you should not care what texture use what UV set, if there are 3 uv sets in blender you should have 3 texcoord buffers filled in JME.
Of course your optimization can come in handy if you have more than 8 uv sets. Or just if you decide you need it…
But you should turn it off by default.
Idk about others, but usually i build my blender models with what purpose they are made for in mind. So I try to optimize my Game models so that they import seamlessly in JME.

@nehon said: I agree too, you should not care what texture use what UV set, if there are 3 uv sets in blender you should have 3 texcoord buffers filled in JME. Of course your optimization can come in handy if you have more than 8 uv sets. Or just if you decide you need it... But you should turn it off by default. Idk about others, but usually i build my blender models with what purpose they are made for in mind. So I try to optimize my Game models so that they import seamlessly in JME.

And this is why I wish we had some Python guru would could write a blender plugin to analyze the models for JME compatibility. Would save so much time, I think.

OK guys,

I just made a commit :slight_smile:
The blender key now has the field:
[java]
protected boolean optimiseTextures;
[/java]
with proper getter and setter.

By default the optimisations are disabled so you should get all the UV coords you prepared in the model.
Just be careful not to exceed the count of 8 because the model might not look like you wish unless you enable the optimisations.

@ghoust
Let me know if it works for you. If not then I will fix the bugs as soon as possible. :wink:

3 Likes

@Kaelthas the example file 2UVSets.blend now creates two uv sets as expected, but the shaded result does not look right. Same goes for my own scene, which with the ogre exporter does look good, so my materials applied to the converted model should work, but they do not look good, twisted, very dark.

I guess the UV coords are not right. I will have a look at that later.

Fort the “very dark” issue, try to generate the tangents.

@ghoust
if you send me a link to your file I will take a look as well.

@Kaelthas the link to the basic example I try to get working is the one from the lightmap example, notice the dark/black areas on the upper side, after creating tangens:
@nehon tangents were generated, images below…

http://code.google.com/p/jmonkeyengine/downloads/detail?name=LightMap.zip&can=2&q=#makechanges

My own scene is more than 100mb zipped (mostly because of textures used), will have a look at how to reduce the size.

the std. lightmap example looks that way:

from above:

from below:

and this is the ogre exported one in the final after tangents get generated, with the same material applied as the one above…:

In addition I found out, that the current buffer contains 72 texcoord2 tupples, while the ogre exported has 48. This by itself must not mean anything, as the new one with 72 with removed duplicate entries also boils down to the 48 values, but only 10 values from the ogre file match with 10 values from the blender export. the other 32 values have no corresponding entries. This seems odd.

@ghoust said: @Kaelthas the link to the basic example I try to get working is the one from the lightmap example, notice the dark/black areas on the upper side, after creating tangens: @nehon tangents were generated, images below...

http://code.google.com/p/jmonkeyengine/downloads/detail?name=LightMap.zip&can=2&q=#makechanges

My own scene is more than 100mb zipped (mostly because of textures used), will have a look at how to reduce the size.

the std. lightmap example looks that way:
…

alt=“” />

Did you try to flip textures?

@Kaelthas , btw, do you know that Ogre and Blender models have different flipping for textures? Is it possible to unify, so that Ogre and Blender models were used in the same way?

Thanks.

1 Like