I think this issue may need to be reopened（https://hub.jmonkeyengine.org/t/gltf-import-texture-problem/43949）, this feature is really important…I’m using the latest SDK, I randomly downloaded a gltf model from https://sketchfab.com, 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… @rickard
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.
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.
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.
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?
Try downloading glTF models directly from Sketchfab, and import them in UE5, Unity3D, Godot, or even more simply in GLTFViewer（https://gltf-viewer.donmccurdy.com/）, you will find they default to Linear as the priority option. Then when you convert these models to j3o, it becomes nearest neighbor filtering.