I have a problem with overlapping ColorMaterial + TextureMaterial using alpha: I experienced it with both the previous versions and the Gold one. Look at the attachment JPG.

I have a table with active areas and fiches on it: the fiches groups have a shadow, that is a 3D model with a simple texture on it, to simulate a very basic shadow effect. The texture has alphaBlending = true, obviously.
The active areas are plain models overlapping the table image, using a ColorMaterial with an alpha: when the mouse moves on them their color changes, and in some area of the table, about the top half of the stage an empty square appears around the fiches shadows.

In the image you can see a correct shadow on a highlighted area (green circle), and some wrong ones (red circles).

If I use a ColorMaterial without alpha this does not happen and the shadows overlap correctly.
Do I miss a setting?

If I use Blendmode.MULTIPLY for the shadows, as someone suggested, a new problem appears: the background texture disappears! I don’t know why, it is another problem I will study later. Anyway I must use alpha for the shadows, as I use the same textures for other entities like dices shadow, and I have to change their opacity.

Edit: I found out that disabling the alpha in the ColorTexture and using a BlendMode like ADD the problem appears anyway: the problem is caused by both alpha and blendmode.

Am I right in my understanding that the light green areas in the bottom and left hand side of the picture are separate planes that are overlaid the table?

In that case, this might very well be a Z-sorting issue. Please try changing the positions of these objects so that they are further from each other to help the pre-sorting algorithm.

Note by the way that semi-transparency is disproportionally heavy when rendering things on the GPU, so try to consider alternative ways of achieving the effect with the light green overlays. For example, try splitting up those areas of the table into separate meshes, with a second material, and use ColorTransformMethod to fade them towards yellow using the fragment shader instead of having a separate object overlaid on top of it.

Yes, they are separate meshes (all of them imported from a single Mesh containing the 71 objects) overlayed to nothing, as the table is a background texture showing a prerendered table.
I thought about the Z-sort problem possibility, but the problem persists even if I position the active areas lower on Y.

I am using transparent ColorMaterials as it would be a hell of a mess creating the 71 pieces of texture: I do not need extreme performances, as it is a pretty static game, and during the dices animations the areas are not active. Anyway the game runs very well even in debug mode.
If you tell me there are no alternatives I will try the ColorTransformMethod way, hoping that my boss will not get angry because of the time it will take :|

It should take you almost no time at all. You don’t have to have 71 different textures. You can use the same texture for all meshes, just map the meshes onto different areas of the texture using their UV coordinates. This is something that you should be able to do in a modeling package in an hour or less.

There might be a way to fix this using the approach that you have used so far, but it’s ultimately not an optimal approach for GPU based content, and you would be wise to try to remedy that regardless.

Well, you’re right, maybe it will take less than a hour, sorry but my brain is frying.
But… what if I needed a sliding active area or transparent overlay? Maybe I will need one, so I would be at the starting point with the same problem.

Yes, if it needs to slide you can’t rely on ColorTransformMethod. Personally I would probably have implemented an overlay image using the secondary UV set, and a UV transform to move it around. But that would require some AGAL work. So lets try to sort out what you already have instead.

Can you try distributing the different planes even further apart?

Well, after a few sperimentation I found something interesting: moving a single area down on Y axis, farther from the camera I managed to fix the opacity glitch moving it by 550 units.
Moving the whole set of areas down on Y axis I fixed the glitch by moving it by 370 units only: weird.

Maybe I have a good idea about the possible problem: the camera distance. As the rendering uses a camera with a pretty tiny FOV, about 4, and I had to position the camera very far from the center of the scene (-2950, 20150, -15450) to reproduce the nearly-ortogonal view, I am pretty sure that the glitch is a consequence of an approximation, like with the projected shadows on very far objects. Farther the object is from camera, lesser precision we have, and the alpha glitch could be a consequence.

Yes, that is our conclusion as well. David has implemented a potential fix in the dev branch. Please try pulling the latest version of that branch from GitHub and try there. If you are unfamiliar with Git and/or branches, you can download the dev branch in a zip file from this URL: http://github.com/away3d/away3d-core-fp11/zipball/dev

Nice! It looks like the glitch has gone!
Thanks!

Do I have to do some more experimentation for you?

Thanks for letting us know. As long as it works and didn’t break your use case in any other way we’re happy. We will wait to hear what other people who reported similar issues say, and then probably merge this critical fix into the master branch, depending on whether we are able to assess it’s stability.

We need no more from you at this point. Just let us know if this fix seems to have broken anything else!

Ok!
Thank you very much!

Hi Richard

I have tried David’s potential fix, but with no success.

I will try explain what is happening.

The camera moves from ISO view to a pawn focused view (represented in the two attachments) and back into ISO view after the pawn has moved. In both attachments you will see a green glow (TextureMaterial facing up, 20 points above the game board) is added to the foot of the pawn. The bright foot of the pawn is the glow being rendered as it intersects the pawn.

When the pawn is on the left most square (in the ISO view) the glow renders correctly until the camera moves in to focus on the pawn. Nowhere in the top half of the game board does the glow render correctly, neither ISO view nor pawn focused view.

When the pawn reaches the right most square the glow and the camera returns to the ISO view the glow renders correctly as the camera reaches it’s destination. Very much the same effect as the left most square position.

As the pawn moves to the bottom of the game board the rendering improves. When the pawn is located on the bottom most square and the camera in ISO view position the glow renders correctly. Only when the camera reaches the pawn does the glow render incorrectly.

Interestingly even though both the board and the dark blue surface are Meshes only the board renders over the glow and never the dark blue surface. This could be the the surface is mush larger its furthest point is always farther than the glow’s.

You must hear this a lot, but again, thank you for the great library that Away3D is.

Let me also mention that when I added the glow (which is a Mesh) to a ObjectContainer3D and added the ObjectContainer3D to the scene instead, it worked!

And there lies the reason why I am labeled a “Newbie”.