View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003664||The Dark Mod||Feature proposal||public||27.01.2014 16:17||11.06.2015 20:06|
|Priority||normal||Severity||normal||Reproducibility||have not tried|
|Target Version||TDM 2.03||Fixed in Version||TDM 2.03|
|Summary||0003664: Change caulk so that it ignores fog.|
|Description||Right now, adding a large foglight with a high fade distance creates a beautiful atmospheric perspective...objects lose their detail as they fade into the distance.|
It looks fantastic and is very easy to do. The only problem is that the fog obscures caulk (which is much more versatile than portalsky), so instead of showing the portalsky, it just looks grey.
Fog does not affect regular portalsky brushes. If something could be done to keep caulk from being affected by fog (the nofog material keyword has never worked, apparently), mappers would be able to use fog to create beautifully murky maps.
|Tags||No tags attached.|
An alternate way of approaching this is to change portalsky so it does what caulk does:
"Or vice-versa, could/should PortalSky gain the secret ability Caulk has to reveal func_statics from other leafs?"
I'll take a look at this in 2.04. I've fixed a similar problem for soft particles.
Caulk sky doesn't create any visible model during dmapping. It provides a solid surface in the world collision model, and it's used for visleaf creation, but it doesn't write any visible surfaces to the proc file and in game nothing gets written into the depth buffer. The depth buffer stays solid white, which translates to "greater than infinite" distance when the engine later comes to calculate the distance to a surface. Depth buffer reads need to be capped at about 0.99949 (=300k Doom units distance). TDM engine uses 0.9995 to mean infinite distance away.
For caulk and fog, capping the distance at 300k units will still result in solid fog. I'll look for a way to say something like "if the distance is greater than 30k units, draw no fog". It's probably better to change the behaviour of fog so it has a max distance after which nothing is drawn.
|There has to be more than the depth at work though. What is it that keeps portalsky from being affected by fog?|
|noFog doesn't work but what about adding the "noPortalFog" keyword to a fogLight volume. Is that also broken?|
@nbohr1more: "noPortalFog" does something different. It stops a fog from closing visportals. Normally, a visportal that's made invisible by fog will get shut just like one with a closed door in it. A thick fog bound to the player is one way to have a massive exterior by the way. Fogs can do more then just close visportals. Stuff outside a fog's opaque distance doesn't get drawn at all, almost as efficient as it being in a closed visleaf.
@Springheel: You're right, it's nothing to do with the depth buffer. I've checked it out properly now.
Fog lights do two things: they draw fog on any surface that they touch, then they paint more fog on the invisible surfaces of their own light volume (bounding box). The engine literally creates extra triangles surrounding the light volume and paints fog on them exactly as if there were patches there. The triangles face inwards to the fog volume so you only see them when you're looking through the fog outwards.
I guess there are a few motives for that... one might be the use case above, so a thick fog can be bound to the player and can shorten the view distance. If fogs drew only on surfaces, that wouldn't work, as you'd see no fog in a big open space with no visible models close by. Another reason is that you can control the amount of fog seen when you look upwards by raising or lowering the top of the foglight, which will work as long as the fog volume doesn't cross the portalSky.
The reason that skyportal doesn't get fogged is twofold: (1) the portalSky material has no light-interacting stages, so the fog light doesn't draw on it, and (2) it's an opaque surface, so it hides the edge of the fog volume.
Caulk doesn't get fogged. It's just not opaque and so doesn't hide the edge of the fog light volume any more than it hides the rest of a big func static. The bigger the light volume is in relation to the fog distance, the more opaque it'll look at the edge.
The fact that caulk appears to have sky drawn on it confused me for a while so I'll try to explain without the aid of a dragram. NB this is an aside: we don't need to know it to fix this issue, but I found it fascinating so want to share :) Caulk doesn't get sky or anything else drawn on it. When you see skybox through caulk, you're not looking at the caulk surface, you're looking straight through to a painted backdrop. When the skybox is active, the first thing the engine draws in a frame is the skybox, and it draws it over the whole screen before taking a snapshot. That snapshot is used to texture skyportal surfaces: the bit of skybox that can be seen through a skyportal surface gets drawn on that bit of screen a second time. But caulk sky is different. It draws nothing on screen, so what you are seeing is the original skybox draw, the one that covered the whole screen before any visible models started to be drawn. The sky is still visible because the engine doesn't clear the screen (technically, the color buffer) between drawing the skybox and drawing the main scene, and when there's only caulk in the way, there's nothing gets drawn over the original skybox draw.
Back to the fix: I've tried disabling the fogging of the foglight's bounding volume, and caulk sky stops getting fogged ok. Objects in view still get fogged. It might look a bit odd if you can see clear sky between two fogged buildings, but I guess it's up to the mapper to avoid that. I can add a "noFogBoundary" spawnarg for lights that toggles it off -- just one draw call needs toggling off if the spawnarg is set.
|That sounds great. It would allow the use that I want, which is for atmospheric perspective rather than literal fog, while mappers that want a thick actual fog could still have it.|
There's no wiki page for fog, but I've added documentation to the entity def so it'll show up in DR under the inherited spawnargs for a light:
"editor_bool noFogBoundary" "If set to true, stops a fog light drawing fog on its bounding box. Only surfaces will be fogged. Use case: stops fogs drawing over caulk skies."
Committed at rv6142(code), rv14068 (entity def and binaries)
If I have "noFogBoundary" "0", then fog paints on caulk, but not on portal_sky.
If I have "noFogBoundary" "1", then fog doesn't paint on either.
How can I have fog paint on both?
Have your fog volume be enclosed *within* the portal sky walls if possible.
Alternatively, you need to make the portal sky light-interacting in some way. Giving it a fake flat bumpmap would probably work. But then you'd need to keep other lights away from the portal sky walls.
Fog doesn't actually paint on either, ever. It paints on any light-reflecting surfaces that it hits plus it paints on the invisible walls of its own volume. Portal sky (which is solid) hides the edges of the fog volume, and it isn't lit, so you see no fog. Caulk lets you see through to the edge of the fog volume, just like it lets you see a big func_static that extends beyond the caulk wall.
Using a fake flat bumpmap doesn't work. It does allow the fog to paint on the surface, but it paints it differently than any neighboring caulk surfaces, so you can see the intersections.
Rather than move all my portal_sky surfaces outside the fog box, I'll change them all to caulk and use the "small portal_sky cube" method. That gives me the look I'm after.
I should have thought of that. The amount of fog is proportionate to the distance, so portal sky walls inside the fog box will have less fog than the caulk areas, where the fog gets painted at the extremes of the fog volume.
Do you think it's worth making a "skybox activator" entity def, or is it easy enough to activate the skybox hiding a bit of portal sky somewhere in a visleaf?
|I think we're ok sticking to the hidden portal_sky cube method.|
|27.01.2014 16:17||Springheel||New Issue|
|27.01.2014 16:18||Springheel||Relationship added||related to 0003662|
|27.01.2014 17:03||Springheel||Note Added: 0006368|
|14.11.2014 19:25||SteveL||Assigned To||=> SteveL|
|14.11.2014 19:25||SteveL||Status||new => assigned|
|14.11.2014 19:41||SteveL||Note Added: 0007124|
|15.11.2014 01:02||Springheel||Note Added: 0007125|
|15.11.2014 02:18||nbohr1more||Note Added: 0007126|
|15.11.2014 12:13||SteveL||Note Added: 0007127|
|15.11.2014 12:15||SteveL||Note Edited: 0007127||View Revisions|
|15.11.2014 12:16||SteveL||Note Edited: 0007127||View Revisions|
|15.11.2014 13:37||Springheel||Note Added: 0007128|
|15.11.2014 18:19||SteveL||Note Added: 0007132|
|15.11.2014 18:27||SteveL||Note Added: 0007133|
|15.11.2014 18:27||SteveL||Status||assigned => resolved|
|15.11.2014 18:27||SteveL||Resolution||open => fixed|
|15.11.2014 18:28||SteveL||Fixed in Version||=> TDM 2.03|
|15.11.2014 18:28||SteveL||Target Version||=> TDM 2.03|
|10.06.2015 13:00||grayman||Note Added: 0007562|
|10.06.2015 16:07||SteveL||Note Added: 0007563|
|10.06.2015 22:04||grayman||Note Added: 0007564|
|11.06.2015 18:28||SteveL||Note Added: 0007566|
|11.06.2015 18:32||SteveL||Note Edited: 0007566||View Revisions|
|11.06.2015 20:06||grayman||Note Added: 0007567|