Jump to content
The Dark Mod Forums

How to create a foggy cellar aka. make use of lights & particles


SeriousToni
 Share

Recommended Posts

Since I saw many good missions with foggy and dusty areas, I was checking the wiki for advice. However there's scarce information about how to achieve this (if you don't really know what you're looking for at least).

So I wanted to kindly ask the people who know the engine far more well than me and the ones who maybe already created a dusty indoor area. My goal is to create a cellar which has torches in it that looks foggy / dusty. I already have that cellar which consists of multiple rooms with their torches and some decal patches on the surfaces. Still it looks very bright and clean. How would I implement a foggy area here (also in terms of performance)?

  • I tried volumetric lights, which results in a really good looking result, however I notice a performance drop (because of the unnessesary shadow calculations I guess)
  • I tried a func emitter, but it seems to be emitting the fog even when the player isn't in that area (again, performance reasons could apply here if I would place multiple emitters there I guess). Also the particles are not bound to that area, so you can see them in the rooms above the cellar sometimes

I guess in the end it can be a mix of multiple methods. What's your suggestion? What technologies would you choose?

  • Like 1

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

I think the classic design is to first setup a standard fog light.

This is easier now since you can ensure that the fog volume does not affect specific entities that have "noFog" spawnarg

thus preventing fog leaking to the floor above ( etc).

Usually you use a darker fog texture and set it thin ( far fog distance parm ).

As for fog particles? func_emitters support hide distance so you should be able to prevent them from rendering where you don't want them.

I think Bikerdude and others use the above in combination with suspended ( floating ) dust particles and cobwebs to sell the final look. Try cracking open the basement area of Alberic's Curse to take a peek at an example.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

I tried with the fog light, like in Alberics Curse, however biker has applied the fog to the whole map. I wanted it to be only in the cellar, but at the end of the fog light I get a huge seem that looks like a water surface. So now you clearly see where the fog ends. Which looks really strange.

So must I make the fog light that huge that it covers the whole map and select every brush and entity that I don't want fog on with the nofog spawn arg?? :o

  • Like 1

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

3 hours ago, joebarnin said:

In my current work-in-progress I use a fog light for a cellar/basement type room. If I position the light correctly I can avoid the seam - I think I had to make the light extend into the walls a little bit.

I already extended the range beyond the walls. However that's not the problem. Problem is, when you go upstairs, before crossing the border of the fog light, it looks like a water surface. This doesn't seem to apply if you use a very bright light source after the border (which may be in your case), but this doesn't help me much, since I need this area to be dark for gameplay reasons.

 

2 hours ago, duzenko said:

The math behind the Doom3 fog frankly makes little sense

Ideally we should tweak the fog shader so that it's not giving seams, etc

Do you have a test map with the that bug for me to look at?

I'll send you a PM. Thank you very much for having a look. We should not stop the conversation here and update this thread still, for everyone else who might come into the same situation in the future.

How it looks ingame

EDIT: Even with the spawnarg "noFogBoundary 1" the effect is not completely gone. It gets rid of the "water surface", however the brushes above the fog boundary are now clearly darker than the ones within.

Edited by SeriousToni

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

You should try Obsttorte's fog script for a foglight in only one location. You would need to location-separate your cellar in such a way to ensure the fog fades in and out in not such an obvious way, that's about the only concern with it. A little antechamber usually does the trick. If you don't want fog anywhere else on the map, I believe you can just set the fog coefficient for the other locations to a really low value (or even to just the ones adjoining the cellar, so they clear the fog). I've used the script on a very old WIP and it still works great.

My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM!

 

 

Link to comment
Share on other sites

33 minutes ago, Spooks said:

You should try Obsttorte's fog script for a foglight in only one location. You would need to location-separate your cellar in such a way to ensure the fog fades in and out in not such an obvious way, that's about the only concern with it. A little antechamber usually does the trick. If you don't want fog anywhere else on the map, I believe you can just set the fog coefficient for the other locations to a really low value (or even to just the ones adjoining the cellar, so they clear the fog). I've used the script on a very old WIP and it still works great.

That's a cool idea. It's as you said - I'd need to rebuild my areas since it needs an antechamber. Currently leaving the cellar to the coal ramp does make the whole skybox turn foggy and then disappear in steps which doesn't look good.

Only option really seems to be to use particles if duzenko doesn't have any solution - but I won't give up hope haha - duzenko for the win! :D

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

8 hours ago, SeriousToni said:

Only option really seems to be to use particles if duzenko doesn't have any solution

Could you use particles just to mask the seam in your transition area?  I had some success in my current map doing this for some fogged-out geometry that was showing against the skybox at a distance, not sure how well it would do up close though.

Maybe spilling a volumetric light out of your foggy area and over the seam would help mask it.  I haven't had the occasion to try it, so it may or may not help at all.

Link to comment
Share on other sites

18 hours ago, SeriousToni said:

I already extended the range beyond the walls. However that's not the problem. Problem is, when you go upstairs, before crossing the border of the fog light, it looks like a water surface. This doesn't seem to apply if you use a very bright light source after the border (which may be in your case), but this doesn't help me much, since I need this area to be dark for gameplay reasons.

 

I'll send you a PM. Thank you very much for having a look. We should not stop the conversation here and update this thread still, for everyone else who might come into the same situation in the future.

How it looks ingame

EDIT: Even with the spawnarg "noFogBoundary 1" the effect is not completely gone. It gets rid of the "water surface", however the brushes above the fog boundary are now clearly darker than the ones within.

Do you prefer control over fog via light material keywords or spawnargs?

Link to comment
Share on other sites

2 hours ago, duzenko said:

Do you prefer control over fog via light material keywords or spawnargs?

Well I don't mind personally. I would say from my understanding that spawn args are easier to modify maybe?

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

Try this exe 

https://drive.google.com/file/d/0B9OoHSmkeSeNZWdyZFliQkNsVTA/view?usp=sharing&resourcekey=0-4XspmLMtaTte6z6CuIB42g

with this fog light

{
"classname" "light"
"name" "light_fog1"
"_color" "0.114 0.082 0.063"
"light_center" "0 0 0"
"light_radius" "496 400 64"
"nodiffuse" "0"
"noshadows" "0"
"nospecular" "0"
"origin" "432 696 -184"
"parallel" "0"
"shaderParm3 " "800"
"texture" "fogs/delta1_fog"
"volumetric_light" "1"
"volumetric_noshadows" "1"
"volumetric_dust" "0.0001"
}

Use volumetric_dust to control fog density

It still gives noticeable banding though, especially with postprocessing and 32 bit color

Regret your test map is missing a lot of brushes and materials, is mostly black for me

Link to comment
Share on other sites

First, thank you very much for your help.
But I think I don't quite understand, I'm sorry! I need to use this exe for the new fog but what happens if my mission gets released later on?

"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Link to comment
Share on other sites

14 hours ago, SeriousToni said:

@duzenko Wow! This is creating a perfect fog with no seem! It works like a charm! :)

Thanks, I'm sure there's going to be at least some issues with it. 

Credits due to stgatilov, his work in the volumetric shader isIused here. Perfect on first try is not my style, lol

  • Like 1
Link to comment
Share on other sites

15 hours ago, SeriousToni said:

First, thank you very much for your help.
But I think I don't quite understand, I'm sorry! I need to use this exe for the new fog but what happens if my mission gets released later on?

Should be in the next beta. The exe is for quick feedback.

  • Like 1
Link to comment
Share on other sites

Mmm... I imagine "fog light" is a special kind of light, which does not light any surfaces, but instead applies some "fogging" on everything.

With the recent change, one can switch implementation of "fog light" to exactly the same code as in volumetric lights but setting "volumetric_*" spawnargs.

It is clear that shadows are ignored in this case because they are never generated for a fog light anyway.

What is no clear however: what about projection and falloff textures?
What is the meaning of these textures for a fog light?
Is this meaning correctly handled by the volumetric implementation?

With the way @duzenko did it, shader just takes average texel color of each texture, and multiplies output color on both of the averages.

  • Like 2
Link to comment
Share on other sites

2 hours ago, stgatilov said:

Mmm... I imagine "fog light" is a special kind of light, which does not light any surfaces, but instead applies some "fogging" on everything.

With the recent change, one can switch implementation of "fog light" to exactly the same code as in volumetric lights but setting "volumetric_*" spawnargs.

It is clear that shadows are ignored in this case because they are never generated for a fog light anyway.

What is no clear however: what about projection and falloff textures?
What is the meaning of these textures for a fog light?
Is this meaning correctly handled by the volumetric implementation?

With the way @duzenko did it, shader just takes average texel color of each texture, and multiplies output color on both of the averages.

projection and falloff are used to control fog density? I assume they make the fog less or more dense, depending on the pixel brightness in the falloff texture? For example to create less homogeneous fog, or simulate smoke?

Btw this UE3 tutorial show some cool fog systems that I think, some can be replicated with current TDM fog system or at lest give you some ideas about how to improve it.

Link to comment
Share on other sites

2 hours ago, stgatilov said:

Mmm... I imagine "fog light" is a special kind of light, which does not light any surfaces, but instead applies some "fogging" on everything.

With the recent change, one can switch implementation of "fog light" to exactly the same code as in volumetric lights but setting "volumetric_*" spawnargs.

It is clear that shadows are ignored in this case because they are never generated for a fog light anyway.

What is no clear however: what about projection and falloff textures?
What is the meaning of these textures for a fog light?
Is this meaning correctly handled by the volumetric implementation?

With the way @duzenko did it, shader just takes average texel color of each texture, and multiplies output color on both of the averages.

What it does now is not ideal of course

Initially I tried to revise "new fog" path in fog.fs but quickly realized we already have a superior solution in volumetric

We might want to copy-paste it into the fog shader and further tweak it there 

Link to comment
Share on other sites

1 hour ago, HMart said:

projection and falloff are used to control fog density? I assume they make the fog less or more dense, depending on the pixel brightness in the falloff texture? For example to create less homogeneous fog, or simulate smoke?

Yes, logically, it could control fog color, which is the same as density in some sense.

But @duzenko disabled sampling (because it's expensive), so fog color/density is constant for every fog light.

1 hour ago, duzenko said:

What it does now is not ideal of course
Initially I tried to revise "new fog" path in fog.fs but quickly realized we already have a superior solution in volumetric
We might want to copy-paste it into the fog shader and further tweak it there 

Why is it not ideal?
What changes do you think about?

Copy-pasting is not a good idea, I'm going to remove all code duplication in shader code after 2.10 is out.

 

I simply wanted to understand: how does projection and falloff texture influence the old fog lights, and what is the desired behavior (if it is different) ?
But nobody has answered any of these questions yet.
Currently I have no idea how the new volumetric-based fog relates to old fog lights in terms of textures 😥

Let's first decide where we are and what we want, and then discuss how to achieve that 😀

  • Like 1
Link to comment
Share on other sites

Doom 3's fog design is pretty strange.

It re-uses the light architecture to define the volume but it treats the player as the "light_center".

The projection image is then projected outward from the player's eyes.

From that description ( via the GPL source ), one would expect the "lightFalloffImage" would have an effect on the outward density from the player?

 

From old doom3world.org discussions I recall that it was claimed that the falloff image instead defines the vertical density of the fog in relation to the real light_center. Thus, one could potentially make the transitions smoother by making sure the falloff image was darker near the boundary areas via estimating the radius distance to the real light_center. Not very practical. Looking over the code, I do not even see where lightFalloffImage is handled by fog. It seems to only get the projection image and "fog enter image" that is auto-generated in image programs so I think lightFalloffImage is ignored by fog?

https://github.com/TTimo/doom3.gpl/blob/aaa855815ab484d5bd095f347163194ac569abcc/neo/renderer/draw_common.cpp

RB_FogPass

// find the current color and density of the fog

lightShader = backEnd.vLight->lightShader;

regs = backEnd.vLight->shaderRegisters;

// assume fog shaders have only a single stage

stage = lightShader->GetStage(0);

( nbohr1more: doesn't the lightFalloffImage count as a stage?

if so, what happens to materials which include it? )

 

// texture 0 is the falloff image

GL_SelectTexture( 0 );

globalImages->fogImage->Bind();

( nbohr1more: why are they calling a projection image a falloff image ? )

 

// texture 1 is the entering plane fade correction

GL_SelectTexture( 1 );

globalImages->fogEnterImage->Bind();

( nbohr1more: this image is auto generated, is it somehow altered by lightFalloffImage ? Not that I can tell )

 

qglDisableClientState( GL_TEXTURE_COORD_ARRAY );

qglEnable( GL_TEXTURE_GEN_S );

qglEnable( GL_TEXTURE_GEN_T );

// T will get a texgen for the fade plane, which is always the "top" plane on unrotated lights

( nbohr1more: this seems to track with the Doom3world description of "vertical density"

but is it really controllable ? )

 

fogPlanes[2][0] = 0.001f * backEnd.vLight->fogPlane[0];

fogPlanes[2][1] = 0.001f * backEnd.vLight->fogPlane[1];

fogPlanes[2][2] = 0.001f * backEnd.vLight->fogPlane[2];

fogPlanes[2][3] = 0.001f * backEnd.vLight->fogPlane[3];

// S is based on the view origin

float s = backEnd.viewDef->renderView.vieworg * fogPlanes[2].Normal() + fogPlanes[2][3];

fogPlanes[3][0] = 0;

fogPlanes[3][1] = 0;

fogPlanes[3][2] = 0;

fogPlanes[3][3] = FOG_ENTER + s;

qglTexCoord2f( FOG_ENTER + s, FOG_ENTER );

 

  • Like 2

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

2 hours ago, stgatilov said:

I simply wanted to understand: how does projection and falloff texture influence the old fog lights, and what is the desired behavior (if it is different) ?

But nobody has answered any of these questions yet.
Currently I have no idea how the new volumetric-based fog relates to old fog lights in terms of textures 😥

Let's first decide where we are and what we want, and then discuss how to achieve that 😀

LOL the fog lights are the worst

I converted them from texgens to GLSL, and in the process I realized I don't want to spend any time on analyzing the math behind it. Feel free to dump the generated fog texture to a .tga and try to make something off it. I think mappers never liked it too.

I suspect (!) that whatever implementation D3 had was a compromise they had to settle on because they were limited with texgens. I want to think about it as a rudiment, that we're better off without.

And we'll save on draw calls too.

Talking about desired behavior, I'd love the fog to account for diffuse texture alpha. This way we'd be able to fog translucent objects properly.

Link to comment
Share on other sites

Quote

Talking about desired behavior, I'd love the fog to account for diffuse texture alpha. This way we'd be able to fog translucent objects properly.

I guess you already realized that translucent objects with volumetric shader doesn't really work.

You need depth buffer to detect distance, and after you draw a new layer of translucent surfaces, you need to update this depth buffer. Some technique of order-independent translucency (depth peeling or alpha lists) can do this, but it is too expensive to be used in a game engine.

Link to comment
Share on other sites

9 hours ago, nbohr1more said:

From that description ( via the GPL source ), one would expect the "lightFalloffImage" would have an effect on the outward density from the player?

From old doom3world.org discussions I recall that it was claimed that the falloff image instead defines the vertical density of the fog in relation to the real light_center. Thus, one could potentially make the transitions smoother by making sure the falloff image was darker near the boundary areas via estimating the radius distance to the real light_center. Not very practical. Looking over the code, I do not even see where lightFalloffImage is handled by fog. It seems to only get the projection image and "fog enter image" that is auto-generated in image programs so I think lightFalloffImage is ignored by fog?

https://github.com/TTimo/doom3.gpl/blob/aaa855815ab484d5bd095f347163194ac569abcc/neo/renderer/draw_common.cpp

The main point which can be seen there: projection and falloff textures from material have no effect.
They bind hardcoded textures in their place, which probably contains some math baked in.

It means that we should do the same.

Link to comment
Share on other sites

I think there is one problem with using current volumetrics for fog.

The volumetric lights is some dust/moisture in the air, which should have two effects:

  • emittance: the dust emits light towards viewer (in fact, reemits the light coming from a strong light source)
  • fogging: the dust makes objects behind it less visible

For a volumetric light, "fogging" effect is much weaker than "emittance" effect, up to the point that it is negligible. At least that's how it works on small light volumes, and we designed volumetric light for small light volumes only.

A volumetric light generated by bright sun/moon inside a room adds some intensity, approximately proportional to the width of light volume seen in considered direction. The objects behind light volume are not toned down. If you there are dark and lit areas behind volumetric light, both will become brighter. Our volumetric light works via additive blending, and color is proportional to distance covered by light volume (double the distance, and the amount of light is doubled).

Fog is not generated by light source, thus "emittance" effect makes no sense for it. It covers large distances (often just everywhere), thus the "fogging" effect happens. But fogging effect works differently: it does not light up the picture, it makes the color of background object weaker, replacing it with its own. If you see dark and light area behind fog, dark area should become brighter (closer to gray), and lit area should become darker (closer to gray). Fog should be implemented as alpha translucency (DST * (1 - src_alpha) + SRC * src_alpha), with alpha value computed as exponent of the distance covered by light volume (if fog/background colors are used in 50:50 ratio, double the distance, and it will become 75:25 ratio).

Also note that additive blending (as used in volumetrics) is order-independent, but alpha blending (as should be used in fogging) is not. It means that translucent objects inside fog inevitably look wrong: either they are fogged as if they were near the closest solid object behind them, or they are not fogged at all. I don't think there is a way around it, just saying that this problem will return compared to the "light everything up" additive behavior.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recent Status Updates

    • duzenko

      The final solution for low-end GPUs:
      r_skibSubviews 1 r_skipInteractions 1 r_shadows 0 r_ambientMinLevel 0.6 tdm_lg_interleave  0
      If you don't get 60 fps after this then either your CPU is really slow or it's a map bug
      EDIT. tdm_lg_interleave is probably not required since r_skibSubviews supersedes it.
      · 15 replies
    • jaxa

      What's the console command to show the player coordinates (for beta testing)? I think it used to be using getviewpos like this but it seems to have been improved since? @AluminumHaste
      · 5 replies
    • thebigh

      'tis nearly time
      · 0 replies
    • Acolytesix  »  Wellingtoncrab

      Yeah ok, let's do this  
      · 0 replies
    • jaxa

      I should be able to beta test some missions. Built a new 5700G + GTX 970 system.
      · 7 replies
×
×
  • Create New...