Well I suggest (and willing to do if other think of it as useful as well) to add assertions in the texture uploads to the graficcard, that query the renderer for the supported maximum texture sizes.
If it is tried to upload a larger one, instead thrwoing a meaningfull exception instead of a org.lwjgl.opengl.OpenGLException: Invalid value (1281).
Since the 1281 is kinda hard to track down, if it happens for example on load of a whole level as j30, while the former can exactly tell what the problem is, what the maximum supported size would be, and which texture is affected.
Also i guess it would make sense to give a interface to the renderer that allows the user to query the engine for the supported sizes.
Eg load low quality models if the hardware does not support the high res textured ones.
Currently there is no way in jme3 to aks thos values without using lwjgl directly. Adding this to the renderer would allow to have a abstracted way to do so, and also allow the jogl2 renderer to implement this functionality.
I guess it is also very useful on android devices, where the actual values might vary even more than on desktop computers.
I agree in every word.
But more than that we need a proper interface to check for gl capabilities without having to use direct calls to what ever ogl wrapper we use.
I agree, but I also think, we have to start somewhere without doing to much changes in one iteration, this would probably be a good start.
i remember that many games had problem because of texture size.
that also could help to manage quality of textures, so it’s good news.
donations should go in that way too! 
@EmpirePhoenix said:
I agree, but I also think, we have to start somewhere without doing to much changes in one iteration, this would probably be a good start.
Yes, but maybe, you should look into the Caps enum and change it so it could return this kind of info.
Right now the way to check caps that is renderManager.getRenderer().getCaps().contains(Caps.WhatEverEnum).
There are also static methods "suports" in caps that check if a textures, frameBuffer,colorBuffer, shader are supported by the renderer.
Could be nice to have metrics like the number of supported varyings/uniforms in shaders, texture max dimensions, max number of bonded textures and so on.
Also you can get extended infos by checking GL extensions
(with lwjgl it's GL11.glGetString(GL11.GL_EXTENSIONS))
IMO we should add what's in there as additional elements of the enum. On the top of my head, cube maps supports, 3D texture supports and so on.
Hm tha caps enum alone is to limited, since this needs gl context specific calls. It would make more sense to query the active render, maybee by passing a enum, eg Renderer.getMaxSize(Caps.TextureSize) or somethig similar.
It’s gonna clutter the renderer code which is already cluttered enough.
What’s the problem with renderer.getCaps().getIntValue(Caps.TextureSize) for example?
this way the code stays in the caps and it’ s generic enough.
@Momoko_Fan what do you think?
Well the getCaps simply does not contain the info i need.
I need to do some gl11 calls, but in jogl they will be different, so I want this abstracted, so that the jogl renderer (or any possible other one) simply needs to implement this and everything is fine.
caps contains info that are put by the renderer during initialization, and doesn’t have info by itself. you just have to add the needed values during the renderer.initialize() method.
this way you keep abstraction and avoid to add more methods in the renderer
@nehon said:
What's the problem with renderer.getCaps().getIntValue(Caps.TextureSize) for example?
this way the code stays in the caps and it' s generic enough.
@EmpirePhoenix said:
Well the getCaps simply does not contain the info i need.
To clarify, I think nehon is suggesting adding the functionality he mentions. Not suggesting that it is already there. So it _would_ contain the info you need after it has been fixed to expose it.
OK, it has been fixed so at least the error when the texture resolution is too high is more understandable now.