[SOLVED] Alpha / transparent mesh without texture

Hello!

To demarcate the edges of the canyons from the background, I’m trying to draw an outline (without texture). Now I wanted to soften this outline by making it slightly transparent. But that doesn’t work.

Do I have to load a small black dummy texture? Can I also use alpha without texture?

Code:

	final Geometry triGeometry = new Geometry(geoName, triMesh);
	final Material mat2 = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md"); // create a simple
	mat2.setColor("Color", new ColorRGBA(0.1f, 0.2f, 0, 0.1f));
	triGeometry.setMaterial(mat2);
	triGeometry.setQueueBucket(Bucket.Transparent);
	mat2.getAdditionalRenderState().setBlendMode(BlendMode.Alpha); // activate transparency

were you trying use different color?

for me it looks fine, got no idea other than that color not passed properly.

Hey,
can you see the geometry when you apply a non-transparent material? I just want to make sure, that the Geometry is actually placed correctly in the scene.

The black edges can be seen in the picture. They are just a little “intense”.

Thanks for the suggestion: It is probably more effective for me to assign the correct color to each ground than to have the transparency calculated per frame.

Just out of curiosity the question: So it is not possible to use Alpha without textures?

Thanks

it is possible for sure, i just looked at some code i had for semi-transparent color.

noticed i have:

mat.setTransparent(true);

along with queueBucket and blendMode, so probably this is missing. (tho wiki say nothing about it, maybe because its auto-setup when setting png texture?)

also im using custom shader, but its almost like unshaded one.
also setting cullHint to never, but it should not matter.
also generating tangents, but it should not matter.
also im using parallel viewport for it with clear flags: false, true, false, but it should not matter.

I’ve literally never called this method in any code that I can think of but I have transparent textures all the time.

99.9999999% of the time of “I have transparency but it’s not transparent” it’s because blend mode isn’t set to alpha. I guess some tiny fraction of those times could also be not putting the object in the transparent bucket and it sorts weird and so looks non-transparent.

Both of which seem to be done in the code snippet. Though without a single class test case illustrating the problem it’s hard to tell if it’s really the issue.

Note that the 0.1 alpha will be almost totally transparent.

My suspicion is that what you are really seeing is that your transparent stuff is rendered first and picking up the framebuffer background and filling the z-buffer thus blocking anything else from rendering there.

You could prove that by setting an alpha discard threshold to 0.2… which should make the transparent pixels < 0.2 not even write anything to the framebuffer (not what you want but would prove it’s a sorting problem). Or you could set the viewport background to blue and see if your lines turn blue instead.

Just hard to say with the information provided.

1 Like

@JaRe Paul is right, i forgot it might be this. your post “texture work but color not” was very misleading for me i think.

just change viewport background color to confirm.

Yes it does. When I make the background blue, the outlines also turn blue.
The alpha is applied to the viewport and not to the triangles behind it.

Then i happened to be lucky that my transparent water surface worked properly … without me knowing why :slight_smile:

As long as i had to keep the order in a single mesh, i understood it.
But here I add node in node to a node. How should I keep the sequence in the scene here?
Is the order in which attachChild is called decisive?

If so, then everything is answered. I only add the water main-node after I added land main-node (that’s why water works). And this thread is just a stupid mistake.

JME will sort things for you but there is no perfect way to sort things.

If something must really always render after something else then you have to use a custom comparator.

…or if you use Lemur it’s already built in.

LayerComparator.setLayer(bottomSpatial, 1)
LayerComparator.setLayer(topSpatial, 2)

If Lemur is already initialized then you get that for free… but even if you don’t use Lemur you can just use that class and add it yourself to the GeometryList for that queue bucket.

I have already added Lemur to the project based on your recommendation from the other post and use it as a menu for the editor.
So I was able to try LayerComparator.setLayer. Works suddenly.
Cool, I could use it to control other things.

As an absolute beginner it might be helpful if the problem of sorting (1. sequence of points in the mesh, 2. sequence of nodes, 3. comparator) were explicitly explained in docu “Alpha/Transparency Sorting, Your Z-buffer, and You”. So not just what is right, but also how.

Many, many thanks to Paul (pspeed) and Radek (oxplay2). As always, the answers were helpful in several directions.

Regarding “but it should not matter”:
I can’t build custom shaders or calculate tangents yet. I don’t know how using parallel viewport would help. But I already use cullHint (for switch between distant and near nodes).

2 Likes

Philosophical note:
I assume that a new layer scoring can be reset at any time for a spatial.

LayerComparator.setLayer(spatial, scoringOfSpatial)

From [SOLVED] Transparent textures, alpha covers alpha problems

Today, with the standard Unshaded.j3md and LayerComperator, it would only have to be reduced to the mathematical problem of recalculating the layer scoring after each camera movement. I guess as a complete beginner.

JME is already sorting transparent objects back to front (painter sort). No need to do additional sorting on top of that.

The issue where layer comparator comes into play is for when sorting would be ambiguous (box inside versus box outside, triangle sticking through another triangle, etc.)… and especially where that order is easily determined.

That being said, the layer can be set at any time and it will be used. The only limitation is that within a set of children, you only get ten layers.