I understand.

However, I have already tried that method (I got it from the Advanced example).

It doesn't allow me to change "only" the texture ontop of the base texture. It will change both.

How do I change UV of just the blended texture?

Ok, here's a very simple example snippet of the outline of what I'm trying to do and it just simply doesn't work:
tm.addTexture("test1",new Texture("res/test1.png"));
tm.addTexture("test2",new Texture("res/test2.png"));
float scale=1f;
testInfo=new TextureInfo(tm.getTextureID("test1"),scale,scale,scale,scale,scale,scale);
scale=4f;
testInfo.add(tm.getTextureID("test2"),scale,scale,scale,scale,scale,scale,TextureInfo.MODE_MODULATE);
testObject=Primitives.getPlane(1,50);
testObject.build();
testObject.translate(0,50,50);
testObject.setTexture(testInfo);
testObject.compileAndStrip();
world.addObject(testObject);

As far as I'm concerned, the 2nd texture stage should surely be being textured 4 times as often.

No matter what I do with any of the uv.x or uv.ys, nothing changes.

Me again

I'm trying to scale the texture being modulated into the textures on my polygons using the longer add method in the TextureInfo class.

I have this line initially just for the normal texture:
texInf[i]=new TextureInfo(tm.getTextureID("layer"+i));

Originally I had this after it, to add a second texture to the surface:
texInf[i].add(tm.getTextureID("floorTexN"),TextureInfo.MODE_MODULATE);
^This works fine, but I wanted the second texture to occur more frequently (there isn't a nice way to tile texture stages)

So I found the long add method and tried something like this:
texInf[i].add(tm.getTextureID("floorTexN"),2f,2f,2f,2f,2f,2f,TextureInfo.MODE_MODULATE);
No difference.

Infact, all of these:
texInf[i].add(tm.getTextureID("floorTexN"),2f,2f,2f,2f,0f,0f,TextureInfo.MODE_MODULATE);
texInf[i].add(tm.getTextureID("floorTexN"),3f,4f,5f,6f,7f,8f,TextureInfo.MODE_MODULATE);
texInf[i].add(tm.getTextureID("floorTexN"),0.1f,0.1f,1f,1f,0.2f,0.2f,TextureInfo.MODE_MODULATE);
Look exactly the same.

The second texture stage doesn't tile or stretch at all.

This seems to be a bug to me, or am I doing something silly and should be using a different method?

EDIT:
I should point out, this is all without shaders. (I'm in the middle of coding a version that works without a shader to make things faster. - All I want is a fairly frequent multitexture.)

EDIT2:
Also for the record, if I manually tile the image loaded (from 256x256 to 512x512) it does work. (I just want to tile it to the equivelant of about 16384x16384 using texture tiling in the code.)

Nono, I'm saying, that's exactly what I already have. xD

I have 2 sets of textures, one set is unfiltered, one set it filtered.

I wanted to find a way to only edit one texture but it affect both filtered and unfiltered because if I edit 2 in 1 call, it slows the FPS down.

Maybe what's an option to use 2 textures instead of what xD?

I'm already using 2 textures.

(I'm having to update the shadow layer concurrently, which I don't really like. )

Just a quick question now:

Is there a way to set the GLFiltering based on an object rather than a texture?

If I'm having to update the non filtered one and the filtered one simultaneously the program slows back down.

I want to be able to update one and use that in filtered and non filtered form on 2 different objects. :O

!!!!!!!!!!! It's alive!!!!!! (I completely didn't see that method. How did I miss that. xD)

It makes sense now why it turned blue instead of using an alpha channel. (What with the whole BGR and ABGR stuff )

Thank you so much for your help.

I shall now concentrate on ironing out some other problems this method has and tone down how much I'm storing in arrays.

Aha!

I've got it!

But for some reason it turns everything blue xD!


Damn, I'm so close xD!

The performance is really nice with this, it's just turning everything blue for no reason.

(Also, saving works, so that's a miracle.)



EDIT:
There also seems to be a problem with the setPixel method.

If I set a voxel to a colour value of 0,0,0,0 it just shows up as black and ignores the alpha.

I changed it so it accepted ints instead of Colors and can't seem to get transparency at all.

If I set a pixel to 0 it keeps a transparent pixel the same but sets a non transparent one to black.

If I set a pixel to 0xFF000000 (the transparency mask I'm using) it sets the pixels to be non transparent (and blue of course).

I don't know whether these are issues to do with this blueing of the map that would disappear when it's fixed, but it's worth taking a note of.

I'm seriously stumped on why it turns blue still... I'm desperately looking for a solution to that one.

I copied that wrong, the line given with this. infront of source comes back with this error when attempting to apply:
Exception in thread "main" java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at voxeng5.Voxeng5$TextureChanger.apply(Voxeng5.java:828)
at com.threed.jpct.Texture.applyEffect(Unknown Source)
at voxeng5.Voxeng5.input(Voxeng5.java:458)
at voxeng5.Voxeng5.gameLoop(Voxeng5.java:363)
at voxeng5.Voxeng5.main(Voxeng5.java:60)
Java Result: 1

If I change it to just source, it works but doesn't actually draw anything on the texture.

I am converting the image into the int array with this code snippet:
public int[] getImagePixels(BufferedImage image)
{
    PixelGrabber grabber;
    int[] pixels = new int[image.getWidth() * image.getHeight()];
    try
    {
        grabber = new PixelGrabber(image, 0, 0, image.getWidth(), image.getHeight(), pixels, 0, image.getWidth());
        grabber.grabPixels(0);

    }
    catch (Exception e)
    {
        e.printStackTrace();
    }
    return pixels;
}

And converting the Image to parse into that as a BufferedImage using this method that was already present in my program:
private BufferedImage imageToBufferedImage(Image image,int width,int height)
{
BufferedImage dest=new BufferedImage(width,height,BufferedImage.TYPE_INT_ARGB);
Graphics g=dest.getGraphics();
g.drawImage(image,0,0,null);
g.dispose();
return dest;
}

I currently have the code sat with all this implemented, the speed is good when drawing but it doesn't draw anything. I'm missing like on thing out. xD

The major fallback of this is that there isn't really a way to save this back out after editing a texture. (Oh wait, or is that where getPixels() would come in handy? - And I'd just recreate the image from an int[]?)

Ok, I tried utilizing that code but it seems to be just as slow as the method I was already using.

I also can't get it to work.

Doing something like this:
PixelArray pixels=new PixelArray(pics[17]);
pixels.setPixel(512,512,Color.BLACK);
pixels.setPixel(513,511,Color.WHITE);
texs[17].applyEffect();
Just to draw some arbitrary voxels in the middle of a layer I could clearly see, didn't seem to change anything.

I don't know if I coded everything correctly because I had to fix this line:
System.arraycopy(source,0,this.dest,0,this.source.getPixels().length);
As it was giving me an arraycopy error.
I changed it to this:
System.arraycopy(source,0,dest,0,this.source.getPixels().length);
So the program runs but doesn't actually update anything. D:



I can't tell if the method really is as slow as mine or if it's because I had to create an array of ITextureEffects (1 for each layer), 2 an arrays of textures (2 for each layer) and each time a draw is called, it had to recreate the pixel object and convert the layer into a BufferedImage. (Which it was originally doing in mine anyhow. xD)

I don't really understand how to use an interface like this. (I only really know how things like KeyListener work with the main class, I don't really know how to use an interface on something.)

I'm also not seeing any examples of usage of this kinda thing.

(Also debating whether it'd allow me to save the images back out, but that should surely be a matter of creating java.awt.Images from int[]s yeah?)

:O

I don't understand how something with 3 methods (none of which seem to correspond to texel or pixel interaction) can do all that?

xD Please enlighten me, I really am interested in speeding this all up.

Wow... that's just ridiculous.

I wasn't even trying to solve it, all I was doing was making it more efficient and I replaced this line in the loadWorld method:
pics[i]=Toolkit.getDefaultToolkit().getImage("user/"+name+"/layer"+i+".png");
with this:
pics[i]=ImageIO.read(new File("user/"+name+"/layer"+i+".png"));
And suddenly it all works 100% fine.

What the hell is wrong with that line that should make it behave like that? xD

I was dead sure everything was good and working, but sure enough, on the 2nd call of that line, it wouldn't work. Somehow, this new ImageIO method is doing what I really wanted, whilst doing the same thing on 1st call. D:

EDIT:
I am still intrigued as to whether there is a way to make the editing of voxels faster with some other methods. :S

Whilst the engine is powerful, it would be open to much more possibility with faster texture interaction.

Ok, I'll give you a quick rundown of how it all works just to set some grounding for what I'm doing/attempting:

The voxel world is generated out of 20 .png images with ARGB pixels, the images are loaded in into 2 textures.
The first is a texture with GLFiltering on, so the texels are blurred. The second is the exact same image load but without GLFiltering.
(I've been storing the texture IDs for these textures in an int[] array instead of having to use the string references each time I want to change things.)
The textures are put onto plains with transparency turned on. This obviously means that the see through parts on the textures enable the user to see other layers through a higher up one.
The plains are separated in the Y dimension so that the textures appear to create voxels and occupy 3D space purely by the fact there are 20 1024x1024 layers.
Where the engine so far implies I'm using 1 plain per image, equating to 20 layers and 20 plains, this isn't quite accurate.
This leads to a very flat and blocky feel. To make the voxels seem more volumetric, I have another number of intermediate layers, these still use the texture of the overall layer, but are placed inbetween those main layers. (This number is not determined yet; on my laptop, I use from about 2 to 5 intermediate layers, and on my desktop I use between 8 and 20)
All of this combined means that the number of plains being rendered with an ARGB texture can range between 40 and 400 depending on what I'm doing and where I am. (This means the framerate, even on a good computer can be as low as 60 or 70.)
The other thing I'm doing is with the 2nd texture that is loaded, with the GLFiltering on texels. This is simply used as the bottom of the stack of duplicate layers to add shadowing, so that needs to be regenerated alongside the normal unfiltered texture used in the majority of the layers.
(A side point is that the top most layer also has normal mapping on it but that seems to be working fine, so ignore it for now, if I took it out, the engine functionality would not change and nothing more/less would break.)

Here's a quick picture showing all of this stuff:


This is just a quick comparison of what it would look like without normal mapping or the shadow layer:


Right, that explains how the engine works.

What I'm doing now, is simply allowing the user to save the world after editing with F5 and load the world with F9.

All I am able to do when I'm in the actual program is draw voxels in empty slots (where the alpha value is 0) with the left mouse button and remove them with the right mouse button. This is all working brilliantly (if a little slow, but we'll get to the ITextureEffect in a bit).
This is where all the creating buffered images and drawing stuff comes from.

In order to edit the texture data (the voxels) I need to be able to manually set pixels (or even better, texels) to a value. To do this, I'm having to keep a record of the image loaded for the textures and use it when drawing pixels on mouseclick.
I've got to get a graphics context for an editable image, draw the record image for the texture being edited onto it, draw what I'm drawing onto that (usually a single pixel, a line or subtracting some pixels) then reload that into a new texture. (As I said, this all works fine.)

This all worked perfectly when I did this in Slick2D as well, so I know the procedure, it's just messing up with things like replaceTexture for some reason.

The saving is working. If I save my map and alt tab to where the 20 .pngs are saved, I can see the pixels have been edited.

For some reason when I load the images a 2nd time from file though, it seems to latch onto the old version as opposed to the new loaded version.

If you can see a much more concise and more efficient way to edit texture data that I can save to and load from files, I welcome it. - The method I'm using right now, while I understand what it's doing, it is really slow, and is having problems clearly.
(Could ITextureEffect achieve all this?)

Ok, I've changed it to replaceTexture and eliminated some of the repeated lines that I clearly don't need.

This is the loadWorld method that gets called once at the start and any other time the user presses F9 (to reload a previous version of the world after editing.)

/**
* Load the entire world
* @param name The name of the world to load
*/
private void loadWorld(String name)
{
System.out.println("Loading "+name);
// Load each layer image
for(int i=0;i<layerNumber;i++)
{
Texture t=new Texture("user/"+name+"/layer"+i+".png",true);
Texture t2=new Texture("user/"+name+"/layer"+i+".png",true);
t.setGLFiltering(false);
tm.replaceTexture(ids[i],t);
tm.replaceTexture(idgs[i],t2);
pics[i]=Toolkit.getDefaultToolkit().getImage("user/"+name+"/layer"+i+".png");
}
System.out.println("Loaded "+name);
}

This is one of the places where voxels are edited (when clicking the mouse, it adds a voxel to the layer), it uses replaceTexture successfully, and edits pics[] (which is an array of java.awt.Images for saving/loading/creating textures from)
for(int testing=layerNumber-2;testing>-1;testing--)
{
BufferedImage dest=new BufferedImage(mapSize,mapSize,BufferedImage.TYPE_INT_ARGB);
Graphics g=dest.getGraphics();
g.drawImage(pics[testing],0,0,null);
int digX=mapSize-((int)digger.getTranslation().x+1),
digY=mapSize-((int)digger.getTranslation().z+1);
// If the pixel is transparent
if((dest.getRGB(digX,digY)&0xFF000000)<0)
{
testing++;
dest=new BufferedImage(mapSize,mapSize,BufferedImage.TYPE_INT_ARGB);
g=dest.getGraphics();
g.drawImage(pics[testing],0,0,null);
dest.setRGB(digX,digY,0xFF808080);
g.dispose();
pics[testing]=Toolkit.getDefaultToolkit().createImage(dest.getSource());
tmp=new Texture(pics[testing],true);
tmp.setGLFiltering(false);
tm.replaceTexture(ids[testing],tmp);
tm.replaceTexture(idgs[testing],new Texture(pics[testing],true));
break;
}
g.dispose();
}

For some reason, if I load at startup, edit the layers, save the map (it works fine up to here, the images really do save correctly) then load the map again, if I edit the map after this 2nd load, it will use the images from the first load and ignore what I just saved... - The textures literally revert back infront of me to the previous versions and what I drew between 1st load and 1st save disapears.

What is going on there

EDIT:
Here are some pictures showing exactly what happens at each step:

This is an area of the map after the first load

This is an area of the map after drawing some voxels on it (editing the images and replaceTextureing)

This is after saving, obviously, nothing changed, it's written the files successfully though

This is after drawing some new voxels (just to prove the load worked)

This is after loading (note, it loads correctly)

This is after drawing fresh voxels on the newly loaded map (note all the stuff on the right of the tree is gone )