Huh… with a start and end distance… there is no real need for density. And actually… the way the fog filter works now… there is no need for it either, is there? It just changes the max distance closer and closer by uping it. If density should always end at 100%… adjusting it is sorta pointless. Otherwise, it wouldn’t be very realistic looking fog, right?
@t0neg0d said:
Huh... with a start and end distance... there is no real need for density. And actually... the way the fog filter works now... there is no need for it either, is there? It just changes the max distance closer and closer by uping it. If density should always end at 100%... adjusting it is sorta pointless. Otherwise, it wouldn't be very realistic looking fog, right?
If the fog "intensity" is increasing linearly over the range (min to max whatever that is) then it's not realistic anyway. Light doesn't really attenuate that way. Usually (like in fixed function opengl) it's some kind of exponential curve to simulate the actual attenuation. Linear was one of the options and I still remember being able to control the min and max distance... though my memory is fuzzy. We frequently used black linear fog to simulate local lighting.
If there was a min, max, AND density then I'd expect density to control the shape of the curve. Otherwise, if it's just going to be linear then a min and max is the only thing that makes sense. Density is a meaninglessly fuzzy term in that case.
1 Like
Thanks! That’s the explanation I was looking for.
@pspeed said:
The opaque bucket is rendered front to back to minimize overdraw. Transparent bucket is rendered back to front so that blending happens properly.
erf yeah i inverted things. I edited the post
Paul is right about the distance too. I made that a long time ago so I forgot.
Also the maths are not from me, i couldn’t have come up with this kind of equation 
There was a missing wiki page on render buckets so I created it and added the info from this thread as it’s actually something I’d looked for in the tutorials a few times and not been able to find:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:jme3_renderbuckets
2 Likes
@nehon said:
Paul is right about the distance too. I made that a long time ago so I forgot.
Also the maths are not from me, i couldn't have come up with this kind of equation :p
Some stupid observations about the differences between shader-based fog and the filter.
1. The end result color in both are different. The filter is much brighter (closer to the color you define).
2. There is less banding with the filter... which is definitely nice.
As for the depth change...
You can do some neat things with the change I put in there... but, as compared to GLSL implementation of fog, both are wrong. The one that is there currently mirrors what most articles demonstrating how to implement fog show... gl_Fog (or whatever it is defined as) has a list of 5 params... Going from memory here... but they are:
fogStartDistance
fogEndDistance
fogDenisty
someKindOfCurveBias
andSomethingICantRemember
I don't know what the difference between density and bias would be with a start and end distance... but, shrug... someone found a reason for them.
I'll see if I can find this info again.
Anyways... just some interesting observations about equations that make no sense to me and the cool effects they produce. >.<
Here is the GLSL documentation for glFog:
http://www.opengl.org/sdk/docs/man/xhtml/glFog.xml
The params are:
GL_FOG_MODE
params is a single integer or floating-point value that specifies the equation to be used to compute the fog blend factor, f. Three symbolic constants are accepted: GL_LINEAR, GL_EXP, and GL_EXP2. The equations corresponding to these symbolic constants are defined below. The initial fog mode is GL_EXP.
GL_FOG_DENSITY
params is a single integer or floating-point value that specifies density, the fog density used in both exponential fog equations. Only nonnegative densities are accepted. The initial fog density is 1.
GL_FOG_START
params is a single integer or floating-point value that specifies start, the near distance used in the linear fog equation. The initial near distance is 0.
GL_FOG_END
params is a single integer or floating-point value that specifies end, the far distance used in the linear fog equation. The initial far distance is 1.
GL_FOG_INDEX
params is a single integer or floating-point value that specifies i f , the fog color index. The initial fog index is 0.
GL_FOG_COLOR
params contains four integer or floating-point values that specify C f , the fog color. Integer values are mapped linearly such that the most positive representable value maps to 1.0, and the most negative representable value maps to -1.0 . Floating-point values are mapped directly. After conversion, all color components are clamped to the range 0 1 . The initial fog color is (0, 0, 0, 0).
GL_FOG_COORD_SRC
params contains either of the following symbolic constants: GL_FOG_COORD or GL_FRAGMENT_DEPTH. GL_FOG_COORD specifies that the current fog coordinate should be used as distance value in the fog color computation. GL_FRAGMENT_DEPTH specifies that the current fragment depth should be used as distance value in the fog computation.
Because this is a really important part of creating atmosphere (which is everything in the game I am working on as realism just will never happen for me alone), I think I am going to try and port over this version of fog, including the blend mde. I’ll share it once done.
Also note: IMPORTANT!
The end distance is only used when calculating LINEAR fog… the start distance is used for all other modes.
I know this thread is from 2012 but it was helpful to me, I’ll just say that if you are going to use this fix you should replace
float depth= (m_FrustumNearFar.x / 4.0) /
(m_FrustumNearFar.y - fogVal *
(m_FrustumNearFar.y));
in the .frag with
float depth= (2.0 * m_FrustumNearFar.x) / (m_FrustumNearFar.y + m_FrustumNearFar.x - fogVal* (m_FrustumNearFar.y-m_FrustumNearFar.x));
as it was not applying the fog to a portion of the frustum… works as intended now I believe.