Getting the texture id form Texture2D

Can someone tell me how can I get the OpenGL texture ID from a simple Texture2D object ?

Just curious, why would you need this?

I’m trying to port some code from my Engine (which is written in C++) where I’ve already designed a template to manage the Textures. I’d like to integrate this template with the JMonkeyEngine, and to do this, I need the access to the OpenGL Texture ID.

Well the thing is that a Texture/Texture2D and Texture3D do not know they are being backed and rendered by OpenGL hence they don’t know of any id’s.

I understand, thanks for the precision. I don’t know anything about OpenGL texture ID, but I have the feeling that you are trying to do efforts that a scenegraph like JME is intended to save :smile:

@DannyJo so the Texture2D class isn’t where I should be looking for the ID. All right, I’ll read the source code and try to figure out how jme3 handles the bindings.

@methusalah Indeed, jme3 seems to handle things like rendering quite gracefully :smile: . But I’ve only been using it for one day, I think It’ll help me better understand the Engine.

Actually looking closer you might be able to do something like this.


That was my first guess, but unfortunately it doesn’t seem to be it. (And for some reason, it always return -1, which is an invalid number from what’s written in the description).

Looks like the OpenGL texture ID is the same as the Image id.
Here is the binding :

Something is wrong with my Texture initialization then.

An image gets an ID when its first used. You could preload the texture by using a call like Renderer.setTexture().

1 Like

Many thanks @Momoko_Fan it helped much for boosting an app but I have too many textures and it’s really slow compared to none-JME ways, i.e. working with primitive renderer like android ogles. Do you have any idea to preload textures faster? There seems to be “context.boundTextures” , “statistics” and “setupTextureParams(tex);” have the potential for making the process faster as I found out from the source. Also I’m sorry that I’m still using JME 3.0 but it’s for failing of NBAndroid of netbeans8.2.

You can examine the source and make the necessary changes, for example, create a list with keys equal to the file name, and add identifiers to the values. In my opinion, it will be faster. And create a get method for the list.

As I expected generating and binding textures only take about 1ms but mipmap stuff, making efficient bitmap for android and compression takes about 500ms for each texture! Well I ran some tests on the source, the bottleneck is: “OGLESShaderRenderer”->“setTexture”->“updateTexImageData”->“TextureUtil.uploadTextureAny”.
Totally it’s matter of mipmap and compression, but changing texture params has no impact on performance!!! It seems that it always go to mipmap and compression section! Also there were few lines for making hardware mipmap.

I want to use hardware mipmap or even no mipmap at all, no compression and no android efficient texture making. Is there any solution for it?

Forcing “needMips” var to false results black textures and I found no solution for it yet!
Thanks @AdiDOS , I’m already doing something like what you’ve mentioned, it’s not matter of inside model textures which may require considerations that you said, I’ve already got an array of textures like animation.
My app has about 60 textures and without JME it takes about 3 seconds to load but in JME it takes 30 seconds to load!
Maybe I should ask this on another thread.

Try it:

	TextureKey key = new TextureKey("Interface/Logo/Monkey.jpg", true);
	Texture tex = assetManager.loadTexture(key);
1 Like

Nice “key.setGenerateMips(false);” could about reduce 8 seconds from 30 seconds of loading, but “Bilinear” and “BilinearNoMipMaps” have no effect, seems to be only hardware hint. what is “key.setAnisotropy”? Any more ideas for faster load?

I have no ideas. So it is not known where the time is lost.


Probably as that influences on:

I do not know how the android is doing with vertical synchronization. But perhaps you will have to give it up, at least for the time of loading.

If you only load textures a loop, then this can be a problem.

Thanks @AdiDos I couldn’t find any solution from source code. Be glade for other suggestions but it seems that android section of JME breaks if “OGLESShaderRenderer”->“setTexture”->“updateTexImageData”->“TextureUtil.uploadTextureAny” be revised or truncated and it’s essential, I mean that textures on android get black. Though I’m relatively satisfied, good luck.