GLTF to J3O Texture Filtering Issue

[JohnLKkk]

see：https://hub.jmonkeyengine.org/t/gltf-to-j3o-texture-filtering-issue/47197
It is normal for the SDK to directly preview gltf files, and the results are consistent with gltfViewer. J3o should also be consistent with these gltfViewers, rather than forcibly converting to nearest neighbor filtering.

And, most gltf importers use Linear as the default filtering option (users can adjust to nearest individually, but Linear is the default priority), as discussed in the post: "Lets say many new users try it out, and they do not even know about this “hidden” setting and they might think this is engine issue(i mean they might think thats how engine work)."
This is just my personal suggestion, based on the texture filtering configurations in actual game projects I have worked on.
The advantages of linear filtering (trilinear):

1. Saves texture bandwidth (optimizes texture cache)
2. Smooths visuals
   I really can't think of any advantages of nearest neighbor filtering, except for achieving pixelated material effects like in MC. It doesn't seem to have many advantages, so why does j3o default to nearest neighbor filtering? If anyone knows, please tell me, thank you.

[oxplay2]

like in hub topic, i think i found the issue(this is related to some other fix, that apparently stopped j3o from storing tex filter):

in J3MOutputCapsule.java#L173

            //Min and Mag filter
            if (tex.getMinFilter() != Texture.MinFilter.Trilinear) {
                ret.append("Min").append(tex.getMinFilter().name()).append(" ");
            }

            if (tex.getMagFilter() != Texture.MagFilter.Bilinear) {
                ret.append("Mag").append(tex.getMagFilter().name()).append(" ");
            }

[tonihele]

like in hub topic, i think i found the issue(this is related to some other fix, that apparently stopped j3o from storing tex filter):

Nice, if that is the case. A new bug should be filed on the jME issue side about that.

[oxplay2]

We are still not sure, since Ali say its working fine for him, currently we want verify if issue were somewhere else.

[JohnLKkk]

We are still not sure, since Ali say its working fine for him, currently we want verify if issue were somewhere else.

I did not get separate .j3m files generated when using jmec, so the texture filtering was still incorrect nearest neighbor filtering.
I think this issue has existed since 2019 (because my post above is from 2019), however, once I follow these steps:
SDK → gltf → j3o, then open the j3o, manually click “create .j3m” for each geometry, that particular Geometry will have correct texture filtering effects, but I have to manually click “Create .j3m” for every Geometry.
I think the J3MExporter that @Ali_RS mentioned does something similar (generating separate .j3m for the j3o), but I was using an older version of JMEC, so no .j3m was generated.
Although .j3o + separate .j3m works fine, generating only .j3o results in anomalous texture filtering, so this is a GLTFtoJ3O issue that has persisted (at least since 2019).

Please note the step I mentioned in 2019 that standalone j3o must manually click “create .j3m” or use something like J3MExporter code to get correct texture filtering results. So I think this is a GLTFtoJ3O (non-separate j3m) issue.
https://hub.jmonkeyengine.org/t/gltf-import-texture-problem/43949%EF%BC%89

[oxplay2]

Just an update comment:

This issue is solved for non-SDK within:
jMonkeyEngine/jmonkeyengine#2132
jMonkeyEngine/jmonkeyengine#2134

But JohnLKkk replaced Jars in SDK for 2134 pr updated JME code and it didnt helped for SDK.

@tonihele you will verify right?, since just replacing jars might not be enough to test.
So maybe it will just work, but need update Jars different way.

[neph1]

Is this resolved?