Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Blastfrog

Fog as fade to background instead of solid color

Recommended Posts

This would be a cool feature in my opinion. Too bad I don't have the chops to even begin to implement such a thing.



What do you think about it as an idea?

One useful application could be having the BSP cut off areas that are 100% obscured by fog to make really huge areas faster. By really huge, I mean about the size of the biggest areas of the Serious Sam games.

Share this post


Link to post

Silent Hill!

Could be used with a control sector similar to how fog works. Would need to find a line number which is unused by every port though.

Share this post


Link to post

Don't know whose version of FOG you are referring to ("instead of solid color").

DoomLegacy has a FOG linedef that produces several versions of FOG.
The DoomLegacy FOG is applied as a translucent texture, that is dynamically generated.
Some of the FOG is suitable as ground FOG, some is more dense, some is for cloudy water.
It has parameters in the texture fields that adjust the FOG.
It also allows a texture to be used to create the FOG, which affects the fog color and pattern.
The DoomLegacy FOG drifts dynamically. The top of low level fog can be seen to wander and change angle dynamically.

Implementation is complicated.
From outside the fog, the fog is rendered as translucent sheets. How many sheets depends on the kind of fog.
Some kinds of fog have a translucent sheet at each linedef, in order to give some depth effect to the fog.

When the player is in the fog, a fog sheet is drawn right in front of the player's eyes.

Share this post


Link to post

When I say fog, I mean Hexen/ZDoom style fog. Same as light diminishing except that it applies to everything behind it and not just the contents of the sector.

I was suggesting that instead of using a single RGB value to fade to, it could blend against a skydrum.

Look at the skybox version of the Citadel in Half-Life 2. Not implemented in remotely the same way, but the same kind of end result I'm talking about.

Share this post


Link to post

That's actually not this trivial.

For the software renderer fog just means a different colormap. To use the same algorithm to blend with an actual image, you'll need as many colormaps as there are colors in that image and probably change a few other things as well.

With a hardware renderer I do not think it's doable with Doom's rendering output without using an offscreen framebuffer for the sky to blend against and a special shader.

Share this post


Link to post

I wonder how simple/difficult it would be to make the renderer fade into the sky texture. That could even be done using Vanilla as a base, probably, since there'd be no need to add a way of defining the image to fade to. And then of course areas rendered in darkness could be safely removed from being drawn. The blending via transparency seems like it'd be intensive for large areas, of course.

My theory, anyhow. (He said, knowing next to nothing about the id Tech 1 engine/renderer.)

Share this post


Link to post

The "proper" way to do it would be to create a tranmap lump that had 32 levels of progressive blending between all the colors (or, really, 16, and then have logic to reverse the order of the lookup for the other half). Then in the core drawing routines add code so that instead of looking up a final color for each pixel using the colormap lump, take the texture color at that pixel and the sky color at that pixel (which you would need to add in the code for, obviously) and then use the colormap level to construct your pointer into the tranmap lump, like &finalcolor = &tranmap + ((256*color1) + color2)+(65536 * colormap_level) or something.

Of course, the tranmap lump would be a megabyte by itself, which I guess is no big deal but seems inelegant.

Sodaholic said:

One useful application could be having the BSP cut off areas that are 100% obscured by fog to make really huge areas faster. By really huge, I mean about the size of the biggest areas of the Serious Sam games.

You could basically do this right now anyway with linguortal technology

Share this post


Link to post
Linguica said:

Of course, the tranmap lump would be a megabyte by itself, which I guess is no big deal but seems inelegant.


That's why beyond a certain point (e.g. too many tranmaps), it would more convenient to use HiColor/TrueColor extensions to software renderers, and use specialized column drawers instead: they will look better and probably be simpler to implement than trying to shoehorn everything into 256 colors.

Share this post


Link to post

FOG is done in DoomLegacy at the low level draw routine. Most of the FOG draw routines (32bit,24bit,16bit,etc) using some very specialized RGB math to apply the FOG as a translucent pattern. The FOG pattern itself is dynamically generated, so it is not a static texture.

DoomLegacy FOG works in software draw and hardware OpenGL draw.

The DoomLegacy FOG has hard edges. I would like to soften the edges in some future patches.

I am not sure of the properties of the Hexen FOG to offer any useful comparison.

Share this post


Link to post
wesleyjohnson said:

FOG

I didn't know Franz-Olivier Giesbert was involved in Doom Legacy.

Share this post


Link to post
Graf Zahl said:

No matter how Legacy calls it, that's not Fog!


Sounds like fog to me. And it works in SW and HW, and looks better than any other implemented solution atm.

Share this post


Link to post

This looks like it'd be really good looking and very fun. I can't wait for it to become a feature in something, shortly after GZDoom gets vertex lighting.

Maybe that's almost likely.

Share this post


Link to post
wesleyjohnson said:

Don't know whose version of FOG you are referring to ("instead of solid color").

DoomLegacy has a FOG linedef that produces several versions of FOG.
The DoomLegacy FOG is applied as a translucent texture, that is dynamically generated.
Some of the FOG is suitable as ground FOG, some is more dense, some is for cloudy water.
It has parameters in the texture fields that adjust the FOG.
It also allows a texture to be used to create the FOG, which affects the fog color and pattern.
The DoomLegacy FOG drifts dynamically. The top of low level fog can be seen to wander and change angle dynamically.

Implementation is complicated.
From outside the fog, the fog is rendered as translucent sheets. How many sheets depends on the kind of fog.
Some kinds of fog have a translucent sheet at each linedef, in order to give some depth effect to the fog.

When the player is in the fog, a fog sheet is drawn right in front of the player's eyes.

Wow, I never saw that in Legacy before. Did you add this feature recently? I know of the single sheets you can apply to a 2s line, but multiple sheets? Interesting! How's the performance, looking through multiple sheets in the software renderer?

Share this post


Link to post

The fog sheets were in DoomLegacy from version 1.42. I improved them a couple versions ago. Even though I mentioned it in the forum at the time, it was like
nobody noticed.

The documentation for the fog states that there may be improvements in the implementation in the future. The current implementation is fast to draw, as it only involves a few translucent fog sheets being drawn.
The special part in the code is generating moving fog sheets using some color and pattern from a texture (it only samples a few pixels of the first line of the texture).

It is better than no fog, and can be controlled by the level mapper.
In some usages it looks fairly good. It is not that hard to create a strange usage that does not look so good. Sharp edges on the fog look strange, so the fog edges should be minimized.

2nd generation fog could detect an open edge and soften it. How, I don't know yet.

3rd generation fog can sample the depth of the sector and blend the edges.
That may be more CPU intensive, may require ray-tracing, and some drawing support that is not yet available in software-draw mode (and I am not sure of HW mode either).

The is the test wad used for fog testing in DoomLegacy. Just for example.

The link or URL you must send to the recipient(s) of your file(s) is:
http://www.fileconvoy.com/dfl.php?id=g6e1ba093639a983699973614316139b55d211c2d6

The file(s) that can be retrieved with the above link is (are):
fogtst.zip (33.016 KB)

The file(s) will be available on the server for the next 10 days.

Share this post


Link to post

Bumping just because I think it's worth reminding everyone how cool this would be, overambitious as it may be. (hopefully this isn't an issue that I did this, I don't plan to bump any more old threads of mine for quite some time. that and i also wanted to focus on the subject of gzdoom not supporting a lot of things just because it'd take significantly more steps in the rendering process)

 

On 10/14/2015 at 8:50 AM, Graf Zahl said:

With a hardware renderer I do not think it's doable with Doom's rendering output without using an offscreen framebuffer for the sky to blend against and a special shader.

Would nevertheless be amazing if this (admittedly nontrivial and overambitious) feature could be done that way.

 

Take a look at RNGPSY's third image here. Wouldn't that scene look just that much more breathtaking to turn the plain fog into mist? What if the mist was animated, and blended between frames like Doomsday does with its animated textures?

 

-----

 

In general I'd like to see GZDoom do more fancy stuff, even if it means not supporting it on older hardware/OGL specs. Even just sprites drawing inside of the floor (a vital feature of Doom's software renderer, that even other ports do in GL now) is something I'm surprised still has yet to be done, clear into 2017. We got bloom and AO before supporting the full feature set of a 23 year old renderer...

 

I know a large part of the userbase is on crusty old garbage. I say this: time marches on, it's their fault if they want to keep using Windows XP with their Voodoo whatever nonsense. Not sufficient reason to hold back much needed progress, IMO. Don't leave them entirely in the dust, but please stop pandering so heavily to them at the cost of everything else.

 

Worth noting, I'm coming at this from the perspective of a relatively clueless layman. I know these things are really complex, please don't think I'm just demanding anything. It's much more about the philosophy than the technicalities or time/effort to implement these things.

Edited by Blastfrog

Share this post


Link to post
On 2015-10-14 at 1:06 PM, Linguica said:

The "proper" way to do it would be to create a tranmap lump that had 32 levels of progressive blending between all the colors (or, really, 16, and then have logic to reverse the order of the lookup for the other half). Then in the core drawing routines add code so that instead of looking up a final color for each pixel using the colormap lump, take the texture color at that pixel and the sky color at that pixel (which you would need to add in the code for, obviously) and then use the colormap level to construct your pointer into the tranmap lump, like &finalcolor = &tranmap + ((256*color1) + color2)+(65536 * colormap_level) or something.

Of course, the tranmap lump would be a megabyte by itself, which I guess is no big deal but seems inelegant.

You could basically do this right now anyway with linguortal technology

Why do that, if instead you could just use a RGB256k table?

 

Retrieve the palette information for each set of pixels, blend them together, pull the final result as an index from the table. ZDoom already does this for transparent objects in palette mode.

 

EDIT: Whoa, did not see the post date on this, did not even realize it was a bump....

Share this post


Link to post

Heh. I'm far more interested in seeing this as a GL renderer feature than as a software renderer feature by this point. Though, if it can feasibly be done in the latter without too much trouble, why not, I guess.

Share this post


Link to post

I think it'll be a lot easier to do this in any software renderer than a GL renderer.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×