recently @iwgeric wrote to me about mipmap generation issue in blender importer.
At this moment Trilinear mode for mipmaps is always used for the newly imported texture.
But @iwgeric says that this causes too much memory usage on android system and suggest to use the blender option for mipmap generation.
There is an option for a texture that causes mipmap generation and I can easily read it.
I have made a few simple changes to the code.
I added the enum in BlenderKey:
[java]
public static enum MipmapGenerationMethod {
NEVER_GENERATE,
ALWAYS_GENERATE,
GENERATE_WHEN_NEEDED;
}
[/java]
along with proper variable in the BlenderKey class with the default value set to: GENERATE_WHEN_NEEDED.
Using this enum can ensure that the mipmaps are generated when the proper flag in blender file is set.
And my question is: shall I commit the code ?
Because someone left the note in the source code of TextureHelper to ALWAYS generate mipmaps for all textures.
This confused me and that is why Iād like to have your opinion on the matter.
Its okay to add this, import of blender models is quite specific and the way of setting the options via the Key works out well, also in the SDK. Just make the default use MipMaps. The comment is more about the common render situations on desktop.
@Kaelthas said:
There is an option for a texture that causes mipmap generation and I can easily read it.
Using this enum can ensure that the mipmaps are generated when the proper flag in blender file is set.
What flag in Blender will you use? The āMIP Mapā checkbox?
By saying ādefault useā you mean GENERATE_WHEN_NEEDED or ALWAYS_GENERATE option to be set ?
I think that GENERATE_WHEN_NEEDED would be better. The mipmap option is set in blender by default when you create new
texture. So if the user will not want mips then he will need to check this option out intentionally.
I tried testing this change. It looks like the mipmaps are not being generated when the texture is rendered (good). However, Android is not creating the Android Bitmap and compressing the image before loading to the GPU. Itās just sending the byte data for the image directly. This usually happens because the image data is packed inside the j3o file instead of staying as a separate file. Is it possible that one of the fixes is now causing the image to be packed inside the j3o?
[java]
Texture result = new Texture2D((Image) blenderContext.getLoadedFeature(image.getOldMemoryAddress(), LoadedFeatureDataType.LOADED_FEATURE));
if (result == null) {
//this will never be executed and here is the image loading performed either from image file or from inside the blender file
}
[/java]
And besides that you cannot be sure that this:
[java]
(Image) blenderContext.getLoadedFeature(image.getOldMemoryAddress(), LoadedFeatureDataType.LOADED_FEATURE)
[/java]
will not return null because the image might not yet have been loaded into blender context. This will give you NullPointerException.
Cool, thanks. Yes, definitely make a test like the following: register some folder locator to a folder with subfolders in the assetManager, load the model and its texture from the subfolder (e.g. loadModel(āModels/MyModel/MyModel.blenderā) and then store a j3o file in the same folder. Then load that j3o file again. It should be able to reference the textures by the full pathname of the textures that was used when loading the blend model, e.g. Models/MyModel/MyTexture.jpg. If its not, it will store the texture in the j3o.
Referenced textures are the #1 use case, packed or generated textures not so much really so these are what definitely has to work .
I spent some time on this today. My blend file has the MIP Maps checkbox unchecked and the images are external to the blend file.
The minFilter is still the default (no mipmaps) - Good
The texture is creating the Android Bitmap and applying compression - Good
The renderer is still generating mipmaps - Not so good
The TextureKey created in TextureHelper sets GenerateMips true which is causing the renderer to create the additional images. Can the line from TextureHelper that blindly sets generateMips(true) be removed? I think that is the last step.