GLTF to J3O Texture Filtering Issue

I think this issue may need to be reopened(, this feature is really important…I’m using the latest SDK, I randomly downloaded a gltf model from, and imported using the SDK, none will have LinearMipmapLinear, while using other engines (including ThreeJs), it seems to ignore nearest by default, and forcibly sets texture filtering to Linear. Is it possible to provide an option to forcibly set texture filtering to Linear when converting j3o? Otherwise, my only way is to click to generate Material for each geometry, which will automatically force Linear filtering when generating the Material.j3m file, as follows:


This can be manually resolved when there are few models, however, if you import a gltf with 10,000 geometries, you will start to go crazy…

When I import the same model into other engines, they will default to using Linear as the priority filtering option (in most cases Linear is the primary texture filtering approach considered), so can an option to force the default be added in the SDK? Otherwise I can only manually click to generate Material.j3m files for 10,000 geometries…

Even when importing the original GLTLF file into Blender, Blender also defaults to using Linear filtering mode. I didn’t see texture filtering options in exporting gltf from the latest Blender version. I currently don’t use older versions of Blender (because I need some features that require newer Blender versions), and I believe Linear is really the default priority choice in most cases, so providing such a setting when importing gltlf and converting to j3o would be very meaningful…

Sorry I’m not familiar with the SDK source code. It would be great if SDK developers are willing to fix this. Otherwise, I may study the SDK source code and fix this issue when I have time in the future… :smiling_face_with_tear:


Does it load fine if you convert it in code, without using SDK?
Afaik SDK uses its own material parser and not the one provided by the engine.

1 Like

And by the way, you may alternatively use JmeConvert library for converting your gltf models to j3o.

1 Like

As far as I can tell, jME does support this feature in GLTF. If it is not present in the file, it is not set and jME will use the default filtering.

The SDK uses jME to convert the model. Of course the SDK can add some automation glue and create a material for each geometry. But is this a desired feature?

Should we change jMEs GLTF loader to put linear by default? Or change jME texture handling so that regardless of the source, non-specified will use linear.


Thank you for the reminder. I haven’t tried JmeConvert yet, I will find time to experiment with it. Thank you. :wink:

1 Like

Can a feature be added, for example configuring texture filtering options when converting to j3o in some tab page or dialog options in the SDK?

I’m sure it can be. It will just create a lot of material files I suppose. I don’t know any other way to do it.


I’m not familiar with the SDK code. If you are willing to add this feature, I’d like to thank you in advance! :wink:

1 Like

I used jmec, it also didn’t set texture filtering to Linear by default…

@pspeed @Ali_RS
I opened an issue here:

As said on the issue, JmeConvert is just calling JME to load these and will just do what JME does.

The benefit of JmeConvert is that you can write simple groovy scripts to do bulk processing on Geometries/materials/textures during the conversion process. The groovy script to convert all of the textures would only be 4-5 lines.


I understand what you mean, but for texture filtering options, shouldn’t this belong to more common basic functionalities? Perhaps the batch processing workflow could be directly integrated into jmec? This way others wouldn’t have to write their own batch script code to execute during the jmec conversion process. :face_with_monocle:

1 Like

I think I can batch process the texture filtering settings I need during Jmec conversion by writing scripts, but others may also write common scripts for this part… Perhaps we could have an option integrated in jmec?

Or you or someone could write the 4-5 line groovy script that works for anyone and share it.

The whole point of having the option to specific scripts on the command line is not to have to write in 100 different options for everyone’s pet “I think it should be done this way”.

“I think it should do tangent generation, can we have an option for that?” “No wait, only if there are normal maps.”
“I want minecraft style textures so can there be an option to set all textures to nearest?” “oh, but only for lit materials.”
…etc., etc… etc…

Everyone wants something a little different. That’s why the scripting support is there. You can literally do anything you want. Swap textures out. Give the embedded materials asset keys so they get written out as .j3m. Mark nodes with an asset key so they get separated out as shared asset links.

The sky is the limit. All with a little groovy code.

1 Like

You’re right that everyone will have their own specific batch script needs. I’m just thinking about this from another angle - perhaps at some point in the future I should add some potential built-in configuration options to Jmec or the SDK’s j3o conversion to make basic functionality operations, like what I or some others need, more convenient.

Here is a script that will iterate over all of the texture parameters and print them:

import com.jme3.scene.Geometry;
import com.jme3.material.MatParamTexture;
model.findAll(Geometry.class)*.material.params*.findAll { it instanceof MatParamTexture }.each { param ->
    println "texture param:" + param

Should be easy enough to modify it to set the textures as you like then your jmec will have the option you request.

It’s just that instead of:

jmec -target foo blah blah -convertTextureFilterToLinear yourModel.gltf

It would be:

jmec -target foo blah blah -script convert-texture-to-linear.groovy yourModel.gltf

Almost no different… except 1000000x more flexible and the JMEC code stays unbloated and easier to maintain.

Moreover, someone might contribute a whole library of such useful scripts and provide endless “additional options”.


It seems min and mag filter are not set on your gltf file? I guess that is why jme picks the default one (the default is specified on Texture class I think).
So you either need to set it in Blender material texture settings before exporting to gltf or as Paul said simply write a small script to change texture filters on convert.


Sorry, I didn’t see the option to set texture filtering when exporting glTF in Blender 2.9+. Also, I didn’t export from Blender, but downloaded directly from Sketchfab and used it. I tested about 15 models, downloaded directly and converted to j3o, they all used nearest neighbor filtering by default.
Just my personal suggestion: I used several other engines to use these glTFs downloaded directly from Sketchfab - UE5, Unity3D, Godot, even glTFViewer - they default to Linear filtering instead of nearest neighbor (unless you manually adjust a texture filtering option after import).
What I’m trying to say is, could JME consider and refer to how these other engines handle this? I believe they do it this way for their own reasons (I guess one reason is Linear is the priority in most cases).
An even simpler approach would be to provide a tab page to configure filtering methods when converting j3o in the SDK… You might say: others may prefer nearest neighbor filtering, but these don’t conflict - because I think the GLTF importers of other engines (more than just one or two, at least 5 that I know) handle texture filtering this way by default.
So I’m thinking, should JME’s GLTF importer adopt a similar approach as the importers of these game engines? :face_with_monocle:

Try downloading glTF models directly from Sketchfab, and import them in UE5, Unity3D, Godot, or even more simply in GLTFViewer(, you will find they default to Linear as the priority option. Then when you convert these models to j3o, it becomes nearest neighbor filtering.


I just discovered that when I directly preview GLTF (instead of J3O) in the SDK, the default filtering option is linear:

While when I convert to j3o… (even using Jmec for conversion gives the same result):

@oxplay2 You’re right, loading GLTF directly defaults to linear filtering. Maybe the J3o default option should also be consistent with the GLTF previewer? (i.e. use linear filtering)

1 Like

This was exactly my question earlier. That should we change either the GLTF/GLB default or jME default?

jME defaults to low quality graphics everywhere. I think this is somehow a calculated move. And I don’t question it that much. I don’t know what others think about this.