Loading models&textures asynchronously into graphics memory


String extensions = gl.glGetString(GL10.GL_EXTENSIONS);

i can get the extentions supported from my device.
But when run this code this error occurs:


and a NullPointerException.

I think i use this method incorrectly.
I just pasted the method in the simpleInitApp() .
How can i use it correct?

thanks :slight_smile:

I think jme (3.1 at least (the git unstable)) has a inbuild class that you can query, the same that at startup time does the output in the console.

Anyway, maybee this helps.

Are you trying to use GPU compression? If so, which format are you trying to use?
For the DXT1/3/5 and ETC1 formats, jME3 already includes the constants in the Image.Format enum which you can use. For all other formats, you will need to patch the renderer in order to add support.

Is it possible to have a dds file with a ETC1 compression?

another question :smiley:
i use JME3 and want to have a texture with ETC1 compression.
What is the difference between a DDS File and a KTX file ? are both containers?

yes containers, DDS is directX ‘norm’ and KTX is khronos group’s norm (opengl)

Can one load both in jme3?
On android i tried to use DDS FIle with DXT1 compression and it failed. So i tried to use the ETC1 compression.
Is it possible to compress this DDS File with ETC1 ?
I have a tool that can compress png etc. with ETC1 compression. But what can i do when i have a DDS file an android?

I have an experimental KTX loader, but it doesn’t support compressed files yet

ok i’m now able to create a texture with ETC1 compression , but this error occurs :

java.lang.UnsupportedOperationException : Unrecognized format: ETC1 at com.jme3.renderer.android.TextureUtil.getImageFormat()…

When i look into the getImageFormat() method the ETC1 format is no case in the switch-case . But how can i use it then?

Well you probably can’t right now without chaning the engine.

I thought since this commit Added support for ETC1 compression (regular OGL only for now) · jMonkeyEngine/jmonkeyengine@b83603c · GitHub ETC1 support was added for Android or did I get that wrong?

That only added partial support … The renderer was rewritten shortly afterwards that removed it.

There’s no point in adding support for ETC1 at this point because there’s no means to actually load such files in jME3. DDS cannot support ETC1 because it is controlled by Microsoft who wants to push the DirectX specific compression formats (BC1-BC7).

The only way is the KTX container which is something @Nehon is working on.

So there do not exist any compression in jme3 for android application such that i can optimize the performance, right?
Thanks for all the answers :slight_smile:

You won’t get better “performance” from compressed images, just less memory usage.

Yes sorry i said wrong ^^ So less memory usage is not possible?

It is possible as soon as you implement it :smile:

thanks :smiley:

Some updates from my side, with the version of the repo ( Added support for ETC1 compression (regular OGL only for now) · jMonkeyEngine/jmonkeyengine@b83603c · GitHub ) the loading speed of the textures is amazingly fast now but the ObjLoader was quite slow in parsing the obj files on Android so I changed some stuff and created a pull request: Update OBJLoader.java by simon-heinen · Pull Request #245 · jMonkeyEngine/jmonkeyengine · GitHub . The speed improvement is quite good (from 71 seconds down to 15 seconds for 32k vertices on my One+ One) but I think there might be still some space for improvements. I tried my best but maybe you find some more places in the ObjLoader class to improve the loading speed. My learnings from the last hours is that on Android for some reasons the performance of all the basic Java util classes like Scanner and Pattern is horribly slow…

It is recommended to use the jME3 internal J3O format for loading models in production. The SDK allows you to convert OBJ files to J3O.

OBJ format is only for getting the data into jME3.

Yes I know but in my case the content is created by the user via holobuilder.com so it will be obj for now. Later we want to switch to dae as the default format to export to and use assimp to import it on the client side but for now im stuck with obj :wink: