For the Nifty JME2 renderer I’d like to add a workaround for graphics card that don’t support none power of 2 textures when loading textures. The Nifty LWJGL renderer already does that. It will calculate the smallest power of 2 texture that will fit the image being loaded and just loads the image into the bigger texture.
Well, I’ve tried it but so far I’ve failed 
mostly because of my lack of JME2 knowledge tho. Currently I use “TextureManager.loadTexture()” to load the texture which will stretch the image to power of 2 size.
Do you have any hints how I can accomplish:
a. load an Image with it’s original size.
b. create a texture that is power of 2 and at least the size of the image loaded
c. put the loaded image into the texture
I’ve solved a) and b) but need help with c) or if there is another way to achieve this?
My code so far is something like that:
[java]TextureKey tkey = new TextureKey(url, false, Image.Format.GuessNoCompression);
Image image = TextureManager.loadImage(url, false);
int texWidth = 2;
while (texWidth < image.getWidth()) {
texWidth *= 2;
}
int texHeight = 2;
while (texHeight < image.getHeight()) {
texHeight *= 2;
}
// I’ll need to create a JME2 texture of size texWidth * texHeight and somehow (?) get the image into this texture. Any idea? :/[/java]
Thank you!
void
The jME2 renderer already handles this automatically, you don’t need to worry about it.
what? 
A Nifty user has send me the following log:
[java]2010.11.06. 21:24:26 com.jme.scene.state.lwjgl.LWJGLTextureState load
WARNING: (card unsupported) Attempted to apply texture with size that is not power of 2: 32x27
2010.11.06. 21:24:26 com.jme.scene.state.lwjgl.LWJGLTextureState load
WARNING: Rescaling image to 32 x 32 !!![/java]
This is with hardware that doesn’t support none power of 2 textures. So what jme2 renderer do you refer to?
Well, I know that the image will be rescaled to power of 2 (the last line in the log) but in this case it is required that the original image size will be retained This is because Nifty assumes the original image size so that sub-image rendering will be calculated correctly, f.i. when using the Nifty resize Image Mode (http://sourceforge.net/apps/mediawiki/nifty-gui/index.php?title=Resizable_Images_%28ImageMode%3Dresize%29_explained ).
Did I misunderstand your answer or so, Kirill?
Yeah but even if the image is rescaled, it won’t change anything. The UV coordinates are still from 0 to 1 regardless of resolution.
So either way it should work.
I know but when I assume that the original image is 32x27 when I calculate UVs (and not 32x32) it will not work
Well, keeping the original image size (and not the rescaled width/height) might work indeed. I’ll think about this some more and try it. Thanks!
It will work. Try it 
Use it on the original coordinates.
Hi,
I was the one who reported this problem in the nifty-jme-renderer. Actually jme resizes the loaded texture to the nearest power-of-2 size (sometimes enlarges, sometimes reduces(?)).
As I see nifty does not use uv coordinates, but somehow uses the exact pixel sizes. This way, when a 32x27 image is put on the screen, jme resizes it to 32x32, but nifty only displays the upper part of the resized image (32x27 pixels), cropping the bottom. (I’m not sure about this, but this is my understanding of the problem: the result is that the bottom part of some images (esp. the rescaled images which is a fantastic feature of nifty) are missing.)
What should be done, to keep the current behaviour of nifty (in lwjgl/slick/etc renderer it is already working correctly so we should not change the uv coordinates but we should fix the texture loading problem) is that the 32x27 image should be loaded on the 32x32 texture without resize! the rest of the texture can be transparent (preferred) or black or anything.
The bug clearly exists as I have the test code and the screenshots
The problem is that neither void or me are experienced in jme deep enough to find a solution to the problem and fix it in the nifty-jme-renderer.
hi gaba!
the patch you’ve send in the meantime looks good to me and has been commited to the nifty jme2 renderer!
thanks!
void
I refuse to believe this is the issue. There’s something else, a hidden factor. This is not virtually, mentally, or physically possible :o
Hi,
I was actually wrong when describing the problem. I looked into the problem and found that the problem is that the image was resized and the original size was unknown. I used that right after loading teytures still have the original size and stored this value.
I wanted to post that ignore my last post but I could not post anything nor edit my last post (I got some weird error message).
Gaba
So essentially when nifty asks for the size, you want to return the original, and not modified size.
I suspected that to be it …