I’ve recently started working with fog and had some issues with it. I’ve made a simple example that shows it as shown below.
On the left you see two planes, the one in the back is a plane with a non-transparent textured bitmapmaterial, the one in the front is a plane with a transparent textured bitmapmaterial (using a PNG, alphaThreshold = 0.5).
On the right I’ve put a fog method on both materials. As you can see the front plane nearly disappears, leaving a few pixels left (as if alphaThreshold changed to 1.0).

I can fix it using two seperate fogmethods and applying them on the materials separately: material1.addMethod(fog1); material2.addMethod(fog2); (instead of material1.addMethod(fog1); material2.addMethod(fog1);)

It seems I should not be using the same fog method for two different materials (or at least for transparent ones and non-transparent ones).

Is this intended? (Personally I’d like it if I can have one fog method for all materials and if I need to adjust it simply change that one fog method)

—Apprentice

Ok, I now seem to be having this issue on two non-transparent textured materials. Should I always be making separate fog methods for each material?

—Apprentice

No idea but
Been doing it like this
//loading stuff merging etc
//then
var fm:FogMethod = new FogMethod(200);
for each(var m:MaterialBase in MaterialLibrary.getInstance().materials) //<- I made materials public
{
if (m is BitmapMaterial)
BitmapMaterial(m).addMethod(fm);
}

Not noticed an ‘visual difference’ between

BitmapMaterial(m).addMethod(fm);
and
BitmapMaterial(m).addMethod(new FogMethod(200));

Do you also have transparent materials with an alpha threshold to which you are applying the fog to?
If not, could you test this? Just want to make sure I’m not the only one with this problem which would indicate that I’m doing something wrong and I’d like to know about that.

Acutally it does make a difference.
Didnt notice it As I was in the cab view.

if I dont use new method for each material the tree and cab body go white.
Cab doesnt have alpha but does have enviro so that also goes white.

Ah, thanks John
Ok, so the question remains: Is this a bug or is the standard usage to make a new (fog) method for each material? If this is standard usage then if we want to remove the fog then we need to have stored each created fog method for every material as we need to supply it in the removeMethod. Not very convenient, but you can’t have everything

I think that the standard usage of fog does not require one fog method per material. Definitely not.

Let me do some tests to check if there is something wrong with fog in the current state of Away3D 4.x.

Will keep you posted!

There definitely seems to be quite a few problems with fog right now. I’ve posted a new issue on github: https://github.com/away3d/away3d-core-fp11/issues/95

The issue reports a much simpler case problem. We need to start solving from that point and move up to the situation you guys are discussing. This examples shows that it fails for basic bitmap materials: http://www.lidev.com.ar/tests/away3d/fog_and_bitmapmaterials/
Move around with the camera and you’ll see the cubes turn blue.

But for sure, I believe that fog methods should not be created per material.

Thanks for your reply and your issue report