Objects in an overlay scene shouldn’t be affected by mist. That’s one way to make a object not be affected. That’s also the only reason i can think of why you’d want an object not to be affected.
It’s not an only reason why I want seperate mist but anyway thanks for advice.
If you want a sky-box, then you’ll want the mist to be constrained to the ground. (ground fog), so that you can see the sky, and things fade out nicely to the horizon.
Not sure how easy this will be to set up in a 2D shader though. I’ll do some more research on this tonight.
Yess i need that to the skybox. How well that someone understands me. I began to think that hasn’t any solution. Anyway I am not expecting that you will invent a solution but it would be nice.
Look at that beatifull sky (without scattering and mist)
Yours mist shaders are so nice but after mask shader i can’t seen clear sky. Terrain have heavy size, skybox is so far. Recently I was trying to set my sky overly. Unfortunatelly the effect ist horrible and I get down framerate.
Damn, I nearly had a solution but it didn’t work. 
A 2d filter will affect all scenes below it, but not scenes above it.
How about making a mask of the furthest value on the depth texture?
Try this:skybox.blend (473 KB)
If it doesn’t work on the ATI card, add “f” after every float, like this:
depth = 1.0f
In this case you just need to add a background scene with your skybox, and make sure the skybox and background scene camera match the orientation and location of your main scene and camera.
this works because the depth texture seems to only be getting data from the main active scene. it doesnt detect the cube in the background scene at all.
perhaps an “if” statement to check if the depth buffer is over a certain value would be faster… Sdfgeoff, you did some good work on this, you could probaby get it working better than mine.
Nice work guys,
SdFGeoff I can’t wait to check out your new tools,
@ Smoking mirror Yes, I did it similar in previous post.
Position and Orientation was copying by global variables etc.
but effect in my opinion is not so good. I see slippage, a skid of some frame in copying Orientation.
Maybe I magnify it but when we set some shaders like scattering, it makes sensible with environment.
But if other solutions doesn’t exist, I’ll be forced to accept that.
@youle
Sorry that I didn’t test it before. I hadn’t much time to checked blender resources topics.
Maybe your shader is fast and tricky. But have not so good performance with big scenes (lots objects).
The reason is like just you know that the all off object must have seperate define shader.
Other case is problem with displaying textures of LoD’ed objects added in real time in plural amount.
Anyway this is my hypothesis, it musn’t be real reason of that. In other sitiuations it works fine for me ( look at the mountains). Otherwise its strange that fog mask works but with double effect :3
I heard a long time ago that the mist in Yo Frankie! was done through node-based shading.
Essentially, the key component here is making a color mask with the Camera Data node, the upside is that you will not have the issues you’re seeing now with the 2D filter, the downside is that every material will have to be node-based and the node system for BI in general (the same as the BGE) is not near as slick as that for Cycles.
Yes, nodes may have a similar problem to the per object shader…
In my example I added a background scene because I wanted to “flatten” the background. But if you use SDFGeoff’s setup with his ability to define mist by blender units you can just add an if gradient > very far distance argument to avoid coloring the skybox. You don’t need the background scene.
In a related point, when using a skybox I usually get it to match the position of the player because then the skybox can be smaller without any chance of the player moving outside of it. A smaller skybox allows you to have a smaller z buffer range (Near and far clipping values closer together) which is good because it reduces the chance of z fighting.
Alternatively, if the skybox is in a background scene and you have mist in the main scene, you could get something similar to a colored mist that doesn’t obscure the background.
Background scenes also allow for things you couldn’t do with an ordinary skybox such as animation.
Here, try this:
sdfgeoof_mist_clipping.blend (528 KB)
I added a clipping function to sdfgeoff’s mist and set the z buffer of the sky box in the materials tab to -1000.
Now the skybox is in the same scene but not affected by mist.
Great work sdfgeoof and smoking_mirror!
Hmm, I would have done things a little differently. Rather than look at the factor figure, I would have done it based on distance. Because you have the camera end-clipping, I would have had the mist the way it normally is, but 1 or 2 bu at the end of the camera range where mist isnt’ applied.
Both work I suppose, and your way is more processor efficient.
I’m afraid I’m bashing my head on a math problem at the moment. So here’s the challenge for you:
Given Phi (the curly symbol for the angle), ‘a’ and ‘b’ calculate x. The green circle is of radius ‘a’
Yes, it is statically determinate, yes, it is relevant to mist. Currently, my mist shader draws the mist at distance ‘a’ as the black horizontal line. You’ll notice this if you set the distance between near and far really small and turn the camera. By subtracting distance ‘x’ from distance ‘a’ I can turn it into the proper distance from the camera.
I’m sure there are some nice approximations to this, but I haven’t figured them out.
@smoking_mirror:
My graphics card threw an error on your script. Line 33 needs to be:
factor = 0.0
Ah yes. I started working on my own shader which dealt with gradient as a vec4 so i couldn’t set it directly to a zero float. Then I switched over to yours but forgot to change it to deal with a float.
Anyway, the point is that the desired result is possible, though there’s probably a better way to structure it as you say.
If we move the if statement up to affect depth instead of factor, we get a more controllable result:
#version 120
uniform sampler2D bgl_RenderedTexture;
uniform sampler2D bgl_DepthTexture;
uniform float near;
uniform float far;
uniform float camNear; //camera clipping start
uniform float camFar; //camera clipping end
uniform float R;
uniform float G;
uniform float B;
float linearize(float depth)
{
return -camFar * camNear / (depth * (camFar - camNear) - camFar);
}
void main()
{
float depth = linearize(texture2D(bgl_DepthTexture,gl_TexCoord[0].xy).x);
if (depth>99.9f)
{
depth = 0.0f;
}
vec4 dif = texture2D(bgl_RenderedTexture, gl_TexCoord[0].st);
vec4 fog = vec4(R,G,B,0.0f);
float factor = clamp((depth-near)/(far - near), 0.0f, 1.0f);
gl_FragColor = mix(dif, fog, factor);
}
On a side note, I read that we are supposed to declare floats by using an “f” suffix (That’s aparently what some ATI cards have trouble with), but when I do that normally I get an error (C7520) openGL does not allow “f” suffix on constant literals.
Well, last night I read that part of the problem is not declaring the version of GLSL used. When I add
#version 120
To the beginning of the code, it no longer gives errors about the “f” suffix. As a point of interest, does anyone know which version number we should actually use? I pulled 120 from an example script I found on the web, but I don’t really know what’s the current standard for the BGE. I tried version 140 as some posts said Blender can use that these days, but it says that “gl_fragcolor is deprecated” which is not an optimal result. 
RE: math.
I’m afraid I’m not that good at math, I usually just tweak the numbers a bit and decide if the result is more like I want or less like it, then continue from there. Sometimes it works sometimes it doesn’t. 
I do find though that most math problems have a particular name, and if you can find out the name you can find a solution on line.