I have created a single mesh with a texture with transparent parts, however in certain direction (looking in the positive x direction from my current position) the transparent panels look straight through to the sky rather that to the part of the mesh behind the transparent section.
I have set the blend mode to alpha
[java] mat1.getAdditionalRenderState().setBlendMode(BlendMode.Alpha);[/java]
and put the geometry in the transparent bucket
[java]levelGeom.setQueueBucket(Bucket.Transparent);[/java]
so Iām at a loss as to why the transparency is behaving so oddly and Iād very much appreciate any pointers people may have
See the screenshot as to the problem
http://imgur.com/gXxHZ
The complete code is too huge to put up, but here is the part primarily concerned with graphics
[java]
ArrayList<Vector3f> vertices = new ArrayList<Vector3f>(); // points
ArrayList<Vector3f> normals = new ArrayList<Vector3f>(); // normals
ArrayList<Vector2f> texCoord = new ArrayList<Vector2f>(); // tex cords
ArrayList<Integer> indexes = new ArrayList<Integer>(); // indexes
ArrayList<Vector4f> verticesColor = new ArrayList<Vector4f>();
ArrayList<Block> blockIndex = new ArrayList<Block>(); //this allows for easy addition and subtraction of blocks to the mesh buffer because we know where each block is
ArrayList<Updateable> updatables=new ArrayList<Updateable>(); //this is the list of blocks in this chunk that are updateable and so want to register to a chunk update
Mesh mapmesh = new Mesh();
boolean meshmapCreated=false;
Geometry oldGeometry; //both old and new are held so new can be put in before old, leading to no time when the geometry is missing
Geometry newGeometry;
Boolean dirty=false; //this indicates if the mesh needs to be redrawn at the end of the cycle
//and also requires that a connection check be run to ensure that
//all of the chunk is still connected
public static int lengthX = 16;
public static int lengthY = 256;
public static int lengthZ = 16;
Node geoConnectionNode; //this is the to which all things should be connected
AssetManager assetManager;
Block mapCells[][][] = new Block[lengthX][lengthY][lengthZ];
private Vector3d centreOfMass_LocalCoOrds;
// mass inherited from collidable;
public Chunk(int originX, int originY, int originZ,AssetManager assetManager, Node connectionNode)
{
worldX=originX;
worldY=originY;
worldZ=originZ;
this.geoConnectionNode=setUpNodes(connectionNode);
this.assetManager=assetManager;
seed();
updateGeometry();
}
public void updateGeometry(){
oldGeometry=newGeometry;
newGeometry=createGeometry();
String matDefName = āCommon/MatDefs/Misc/Unshaded.j3mdā;
Material mat1 = new Material(assetManager, matDefName);
AWTLoader loader=new AWTLoader();
mat1.setTexture(āColorMapā, new Texture2D(loader.load(UConstants.textureMap.getMap(), true))); //a whole load of stuff to convert an image to a texture
mat1.setBoolean(āVertexColorā, true);
mat1.getAdditionalRenderState().setBlendMode(BlendMode.Alpha); // activate transparency
newGeometry.setMaterial(mat1);
//detachment of old geometry after attachment of new geometry so there is no āseamā
if (oldGeometry!=null){//will be false on first time
geoConnectionNode.detachChild(oldGeometry);
}
geoConnectionNode.attachChild(newGeometry);
dirty=false;
}
private Geometry createGeometry(){
Vector3f chunkOrigin=new Vector3f(0,0,0); //Geometry is created about (0,0,0) and then tranlated and rotated by nodes
//for centre of mass
float totalXWeighted=0;
float totalYWeighted=0;
float totalZWeighted=0;
float totalMass=0;
vertices.clear();
normals.clear();
texCoord.clear();
indexes.clear();
verticesColor.clear();
for(int i=0; i<mapCells.length;i++){
for(int j=0;j<mapCells[0].length;j++){
for(int k=0;k<mapCells[0][0].length;k++){
if (mapCells[j][k]!=null){
mapCells[j][k].createGeometry(chunkOrigin, vertices, normals, texCoord, indexes, verticesColor);
}
}
}
}
//centre of Mass
if (isStatic()){
mass=(double)Integer.MAX_VALUE; //big value to simulate infinity
}else{
mass=totalMass;
}
centreOfMass_LocalCoOrds=new Vector3d((totalXWeighted/mass),(totalYWeighted/mass),(totalZWeighted/mass));
updateMeshMap( vertices,normals, texCoord,indexes,verticesColor);
// Creating a geometry, and apply a single color material to it (itāll be textured later(sort of - weāve already defined which bits of the texture to use, but not defined the texture itself))
Geometry levelGeom = new Geometry(āOurMeshā, mapmesh);
levelGeom.setQueueBucket(Bucket.Transparent); //because some textures have transparency
return levelGeom ;
}
private void updateMeshMap(ArrayList<Vector3f> vertices,ArrayList<Vector3f> normals,ArrayList<Vector2f> texCoord,ArrayList<Integer> indexes,ArrayList<Vector4f> verticesColor){
mapmesh=new Mesh();
meshmapCreated=false;
Vector4f[] c4 = verticesColor.toArray(new Vector4f[verticesColor.size()]);
int colorIndex = 0;
float[] colorArray = new float[verticesColor.size()4];
//Set custom RGBA value for each Vertex. Values range from 0.0f to 1.0f
for(int i = 0; i < verticesColor.size(); i++){
// Red value (is increased by .2 on each next vertex here)
colorArray[colorIndex++]= c4.x; //0.1f+(.2fi);
// Green value (is reduced by .2 on each next vertex)
colorArray[colorIndex++]= c4.y; //0.9f-(0.2f*i);
// Blue value (remains the same in our case)
colorArray[colorIndex++]= c4.z;
// Alpha value (no transparency set here)
colorArray[colorIndex++]= c4.w;
}
Vector3f[] v3 = vertices.toArray(new Vector3f[vertices.size()]);
/Vector4f[] c4 = verticesColor.toArray(new Vector4f[verticesColor.size()]);/
Vector3f[] n3 = normals.toArray(new Vector3f[normals.size()]);
Vector2f[] v2 = texCoord.toArray(new Vector2f[texCoord.size()]);
int indx[] = Uts.convertIntegers(indexes);
if (this.meshmapCreated==false){
//its the first time set up
mapmesh.setBuffer(Type.Position, 3, BufferUtils.createFloatBuffer(v3));
mapmesh.setBuffer(Type.Normal, 3, BufferUtils.createFloatBuffer(n3));
mapmesh.setBuffer(Type.TexCoord, 2, BufferUtils.createFloatBuffer(v2));
mapmesh.setBuffer(Type.Index, 1, BufferUtils.createIntBuffer(indx));
mapmesh.setBuffer(Type.Color, 4, colorArray);
meshmapCreated=true;
}else{
//needs to be set up for the first time
VertexBuffer posBuffer = mapmesh.getBuffer(Type.Position);
posBuffer.updateData(BufferUtils.createFloatBuffer(v3));
posBuffer.setUpdateNeeded();
VertexBuffer normalBuffer = mapmesh.getBuffer(Type.Normal);
normalBuffer.updateData(BufferUtils.createFloatBuffer(n3));
normalBuffer.setUpdateNeeded();
VertexBuffer texlBuffer = mapmesh.getBuffer(Type.TexCoord);
texlBuffer.updateData(BufferUtils.createFloatBuffer(v2));
texlBuffer.setUpdateNeeded();
VertexBuffer IndexBuffer = mapmesh.getBuffer(Type.Index);
IndexBuffer.updateData(BufferUtils.createIntBuffer(indx));
IndexBuffer.setUpdateNeeded();
VertexBuffer colorBuffer = mapmesh.getBuffer(Type.Color);
colorBuffer.updateData(BufferUtils.createFloatBuffer(colorArray));
colorBuffer.setUpdateNeeded();
mapmesh.updateCounts();
}
mapmesh.updateBound();
}[/java]
Transparency - in certain directions transparency is transparent through to the sky instead of to th
This is because geometry in the transparent bucket is sorted back to front but there is no really accurate way to do that for all objects. By putting everything in the transparent bucked (even the solid background parts) you make this even harder.
I donāt know how your scene is constructed exactly but it looks like the big green solid thing is considered to be āin front ofā the blocks near the topā¦ probably because itās near edge is closer to the camera than those blocks or something.
Arranging a scene with transparency can be difficult though you can specifically control the sort order if there is a logical way to do so.
I pretty think i am encontering the same issue, the transparency affect my Node, if i set my Trees to be Translucide so i can see all the leaf correctly, it seem the tree are drawed before the terrain for some reason i cant fix this, and if i use Transparency, the Postprocess water is draw before my tree, but correctly for my terrain, and my tree arent draw over my terrain anymore, still i cant use any of the 2 renderbuquetā¦ I wonder if this is the same issue
edit:
While setting my tree model on transparent
While using translucide
http://i.imgur.com/zKm7j.jpg
@richtea
Yeah looks like a sorting issue but I have had several issues with alpha blending as well, and some of them still persist. I work almost exclusively with semi transparent objects, and eventually went with a completely different rendering alternative for semi-transpareny (alpha to coverage), because I just couldnāt get regular alpha blending in order (and also I was going to include support for that anyways).
Canāt really say what the bug is, or if there even is one, but Iām starting to suspect that. There are two reasons. One is that the default OpenGL alpha test was āabandonedā some time ago, but is still in the pipelines afaik. There was several different types of alpha checks (and I think still is) in the lighting material. Also, someone made a benchmark, and pointed out that alpha sorting was faster in jME then in other engines. This sounded good at the time, but I guess that speed has to come from somewhere.
Again, Iām not saying thereās definitely a bug and that thereās no point in trying to get it right, but there are some really weird problems. Just thought Iād let you know.
Ok, Iām going to say this again.
It is impossible to properly sort Geometry for rendering every case of alpha. Repeat: impossible. Even at the triangle level it cannot be done as itās trivial to create cases where one triangle overlaps another and is not sorted properly.
So all rendering pipelines will implement some kind of compromise. JME sorts on nearest point on the bounding shape as I recall. You can implement your own sortingā¦ for example making sure that land always sorts behind treesā¦ though land is solid and should not be in the transparent bucket anyway.
Yes, it is true that you canāt sort perfectly in every theoretical situation. The system is still not good because it only works error-free in the most trivial cases. Batching is also getting more common, and that makes bounding box based alpha sorting very inprecise. Every person who wants to do something more then draw a few transparent quads canāt be forced to write advanced primitive sorting algorithms, or have to resort to Commodore 64 graphics. Itās being handled tho. Alpha blending is a mess in itself, I suppose, but alpha to coverage is starting to work better due to some recent contributions and patches, namely by Nehon. Actually itās not just just working better, itās working great (as far as I can tell). AtoC not a direct substitute for alpha blending tho.
I still think there might be a bug somewhere, but itās hard to find.
@androlo said:
Yes, it is true that you can't sort perfectly in every theoretical situation. The system is still not good because it only works error-free in the most trivial cases. Batching is also getting more common, and that makes bounding box based alpha sorting very inprecise. Every person who wants to do something more then draw a few transparent quads can't be forced to write advanced primitive sorting algorithms, or have to resort to Commodore 64 graphics. It's being handled tho. Alpha blending is a mess in itself, I suppose, but alpha to coverage is starting to work better due to some recent contributions and patches, namely by Nehon. Actually it's not just just working better, it's working great (as far as I can tell). AtoC not a direct substitute for alpha blending tho.
I still think there might be a bug somewhere, but it's hard to find.
Yeah, but you criticized JME's handling of it versus other frameworks... suggesting that it picks speed over correctness or something. You have two options: 1) sort geometry, 2) pixel perfect alpha. Frameworks that do the sorting for you are doing (1). JME just sorts them faster. (2) is not so easy on modern hardware though there are tricks. In many ways, JME's way is better than other frameworks I've used because it handles some geometry sorting edge cases that centroid sorting or centroid + size sorting, etc. don't. But even at the triangle level there are trivial (not contrived or theoretical) examples that fail to sort properly using any method.
Alpha to coverage is ok except that my understanding is that it only works with AA on. There are a lot of folks that have to leave AA disabled and then you must fall back on something. I've had to tell Mythruna users to just leave it off until they see if the game even runs first.
I would like to give a comment about what you said, Terrain should not be transparent, still mine isnt transparent and tree where draw before it for some reason the bucket keep on taking the terrain as a background to my tree visualy, i dont know if it can be one of the reason why the whole transparency doesnt work. I did apply
matRock.getAdditionalRenderState().setBlendMode(BlendMode.Off);
terrain.setQueueBucket(Bucket.Opaque);
and it keep on making it appear behind the tree, anyway i will find a way to sort everything right once i only have this to do, for now i will keep my tree with out transparency
@n3cr0 said:
I would like to give a comment about what you said, Terrain should not be transparent, still mine isnt transparent and tree where draw before it for some reason the bucket keep on taking the terrain as a background to my tree visualy, i dont know if it can be one of the reason why the whole transparency doesnt work. I did apply
matRock.getAdditionalRenderState().setBlendMode(BlendMode.Off);
terrain.setQueueBucket(Bucket.Opaque);
and it keep on making it appear behind the tree, anyway i will find a way to sort everything right once i only have this to do, for now i will keep my tree with out transparency
Something weird is happening in your scene then. Are you layering multiple viewports or something? Have you turned off Z-write or Z-test on the terrain or trees?
The second picture is especially suspicious since it looks like the ground is drawn first and that the trees are ignoring the Z-buffer values or that the z-buffer was cleared somehow.
Alright I will Try to take a look at what you said, it would clear all my problem from the transparency, I am mostly using the Jme3 documentation to write my program terrain, anyway thank you to point this out, if i get it to work properly i will reply here, other wise make a new topic to give the code simple.
@n3cr0 said:
Alright I will Try to take a look at what you said, it would clear all my problem from the transparency, I am mostly using the Jme3 documentation to write my program terrain, anyway thank you to point this out, if i get it to work properly i will reply here, other wise make a new topic to give the code simple.
Sound good. Yeah, a simplified test case will be ideal for tracking this issue if you can manage to make one... assuming you don't find the issue yourself, that is.
@pspeed said:
Sound good. Yeah, a simplified test case will be ideal for tracking this issue if you can manage to make one... assuming you don't find the issue yourself, that is.
I found what's causing the main bug, it s the fpp = new FilterPostProcessor(assetManager);
I removed the PostProcess water, and the problem continu, then i removed the whole fpp, and my tree draw perfectly, even just by adding an empty fpp to the viewPort the tree get all bugged. Anyway i dont know what to do about this, Maybe you know a way to debug it?
@n3cr0 said:
I found what's causing the main bug, it s the fpp = new FilterPostProcessor(assetManager);
I removed the PostProcess water, and the problem continu, then i removed the whole fpp, and my tree draw perfectly, even just by adding an empty fpp to the viewPort the tree get all bugged. Anyway i dont know what to do about this, Maybe you know a way to debug it?
Are your trees in the transparent or the translucent bucket?
@pspeed said:
Are your trees in the transparent or the translucent bucket?
Translucent, in transparent the Water is over the tree and hide them
Thatās why then. The trees should be in the transparent bucket. Translucent is for very particular things.
If there is a problem with the water then thatās a separate issue that should not be solved with the translucent bucket in this case.
Or maybe this is a recent bug with some recent changes? Do you run JME stable (good) or nightly (less good)?
I think i am running the latest stable if i downloaded it from the main download page
I got some info too
System Info:
Product Version = jMonkeyEngine SDK 3.0beta
Operating System = Windows 7 version 6.1 running on amd64
Java; VM; Vendor = 1.7.0_03; Java HotSpotā¢ 64-Bit Server VM 22.1-b02; Oracle Corporation
Runtime = Javaā¢ SE Runtime Environment 1.7.0_03-b05
Java Home = C:Program FilesJavajdk1.7.0_03jre
System Locale; Encoding = en_US (jmonkeyplatform); Cp1252
Maybe i realy did something wrong somewhere.
@n3cr0 said:
I think i am running the latest stable if i downloaded it from the main download page
I got some info too
>System Info:
Product Version = jMonkeyEngine SDK 3.0beta
Operating System = Windows 7 version 6.1 running on amd64
Java; VM; Vendor = 1.7.0_03; Java HotSpot(TM) 64-Bit Server VM 22.1-b02; Oracle Corporation
Runtime = Java(TM) SE Runtime Environment 1.7.0_03-b05
Java Home = C:Program FilesJavajdk1.7.0_03jre
System Locale; Encoding = en_US (jmonkeyplatform); Cp1252
Maybe i realy did something wrong somewhere.
You get the latest stable by letting the SDK updated itself. In the SDK, go to Tools -> Plugins and see if there are updates to install.
...that may fix your problem, actually.
I did a major update over the missing plugin, and made my problem worst
Are the trees still in the translucent bucket?
if you are using the translucent bucket and filters you need to add a TranslucentBucketFilter at the end of your filter stack, so that the fpp handles the bucket, instead of the render manager.
Try it it should works
EDIT : wait minute, why do you have to put your trees in the translucent bucket? Transparent should work. Only thing I see that could cause your issue is that you set your tree material to not write depth for some reason i canāt explain.