No more ideas… Sorry.
I can read and test your program in my computer if you want.
Here is a little test program. I hope everybody agrees that the image here shouldn't be compressed. But it does.
- the image I used has no antialiasing, just "clear" colors. There are diagonal lines on it
- the Box appears with "stairs"
- 32 bit and 16 bit give very similar results, however I can see small differences, so there is really a 32 bit mode
- I have no more ideas… :?
import com.jme.app.SimpleGame;
import com.jme.bounding.BoundingBox;
import com.jme.image.Image;
import com.jme.image.Texture;
import com.jme.math.Vector3f;
import com.jme.renderer.ColorRGBA;
import com.jme.scene.shape.Box;
import com.jme.scene.state.MaterialState;
import com.jme.scene.state.TextureState;
import com.jme.system.DisplaySystem;
import com.jme.util.TextureManager;
/**
*
* @author Pirx
*/
public class Main extends SimpleGame {
public static void main(String[] args) {
Main app = new Main();
app.setDialogBehaviour(SimpleGame.ALWAYS_SHOW_PROPS_DIALOG);
app.start();
}
protected void simpleInitGame() {
MaterialState mat = DisplaySystem.getDisplaySystem().getRenderer().createMaterialState();
mat.setEmissive(new ColorRGBA(0.5f, 0.5f, 0.5f, 0));
TextureState ts = DisplaySystem.getDisplaySystem().getRenderer().createTextureState();
ts.setTexture(
TextureManager.loadTexture("c:/java/netbeans/kanjigame/data/teleport.png",
Texture.MM_LINEAR_LINEAR,
Texture.FM_LINEAR,
Image.GUESS_FORMAT_NO_S3TC, 1, true));
Box b = new Box("box",new Vector3f(), 5,5,5);
b.setRenderState(mat);
b.setRenderState(ts);
b.setModelBound(new BoundingBox());
b.updateModelBound();
b.lock();
rootNode.attachChild(b);
}
}
If you switch the compression back on, does it look worse?
Oh BTW, I'm still trying to work out what the Japanese message you left for me was… I wonder if babelfish will translate it… mysterious 
Your code seems to be good and it work well here.
Sorry no more ideas.
I hope your problem will be solved by your new 3D card.
@Targ: I'll try it on other PCs. However, the strange thing is that this was working on the same machine for some time, and the only thing that had changed was JME…
@shingoki:
ああ aa Ah
日本 nihon Japan
語 ~go ~ language
の no (possesive marker)
べんきょう benkyou learning, study
します shimasu to do
か ka (question marker)
がんばって gambatte something like "do your best", "go on!" (from gambaru - "try hard")
aw how bitterly ironic 
But I will! I will try!
Tried to run my texture test on my laptop -> JVM crash (http://www.jmonkeyengine.com/jmeforum/index.php?topic=4554.0)
Hmm, tomorrow I try another PC…
Hi guys.
I'm having a problem like this. I'm trying to create a AnimatedTexture (multi-frame texture), and I'm not sure what's the best way to deal with texture coordinates (only uv?).
I tried to manipulate UV coords in other tests, but I got the same problem that I'm showing here.
I'm loading textures with the following:
protected Texture loadTextureUncompressed(URL url) {
return TextureManager.loadTexture(
url,
Texture.MM_LINEAR_LINEAR,
Texture.FM_LINEAR,
com.jme.image.Image.GUESS_FORMAT_NO_S3TC,
1f,
true
);
}
Before translation (should be ok, but the edge between the green and the red column has some weird pixels):
After translation (notice the green pixels on the left edge):
And I'm sure the translation is correct.
Ah, forgot to mention, I've tested both compressed and uncompressed png files.
Looks like you need to setup your wrap mode to be wrap_wrap.
The problem isn't the wrap. But thanks for the reply renanse. What I'm trying to understand is why there are some weird green pixels on the texture (the original image doesn't have it). And why some pixels are shown on the object edges after the translation (the same occurs when using UV coordinates).
Any idea?
screenshots - http://www.sharebigfile.com/file/97083/shots-tbz.html
Please, check the screenshots and you'll understand what I'm trying to do.
shot0.png shows the original texture on the left quad.
The problem is related to the weird pixels on the quad edges.
I guess the problem can be:
- UV coords
- image compression
- texture filters
Thanks in advance.
please try disable filtering and MipMap generation of the Texture
TextureManager.loadTexture(
url,
Texture.MM_NONE,
Texture.FM_NONE,
com.jme.image.Image.GUESS_FORMAT_NO_S3TC,
1f,
true
BlackBluegL, thanks for the answer.
The HEAD jme revision only has FM_LINEAR and FM_NEAREST for magFilter.
The "smooth" issue is partially solved, except for the "green -> red" transition. Seems to have alpha in some pixels, but I'm sure it doesn't have (in the texture file).
My UV coords are a bit wrong (I guess). But anyway, the texture has those alpha pixels between green and red frames.
What can be wrong about the alpha issue? I can upload images to explain, if necessary.
Thanks again.
Another question… Does JME have the glTexSubImage2D functionality ?
I'm recreating the wheel using UV coords for 2D textures. It's done in OpenGL, just wondering if JME has some API for that or if I need to extend a primary/basic class and implement myself. Or maybe change the com.jme.scene.state.lwjgl.LWJGLTextureState
I've found a topic about it – http://www.jmonkeyengine.com/jmeforum/index.php?topic=3605.msg28672#msg28672) – it's implemented already in some class?
jweyrich said:
BlackBluegL, thanks for the answer.
The HEAD jme revision only has FM_LINEAR and FM_NEAREST for magFilter.
The "smooth" issue is partially solved, except for the "green -> red" transition. Seems to have alpha in some pixels, but I'm sure it doesn't have (in the texture file).
My UV coords are a bit wrong (I guess). But anyway, the texture has those alpha pixels between green and red frames.
What can be wrong about the alpha issue? I can upload images to explain, if necessary.
Thanks again.
sorry FM_NEAREST
Solved… I found the problem.
I was using a non-power-of-2 texture… and it was being resized from 700x200 to 512x256 and not to 1024x256.
Heh. dumb dumb. Thank you guys