I've just been optimizing the fog code a little. Previously it had gone through the full fog calculation even when fog was disabled (just with values of 0), which I was never totally happy about, but it was something I had done just to get the damn thing working, always promising myself "I'll do it right next time!"
Well "next time" came, and thanks to the magic of #ifdef in HLSL I now have two copies of my shaders, one version with the fog calculations and one without. I just select which one to run at the start of each frame and have everything nice and fast. A previous incarnation recompiled the shader when fog needed to be enabled or disabled, which stalled a little, but having two copies is minimal overhead and means that all I need to do is set a pointer and it automatically kicks in. No runtime branching either, which - since I'm still targetting Shader Model 2 - would have been quite evil.
So this raises a few questions about how fog should behave. For 1.8.666b I just copied what Fitz did and reset the fog at the start of each map, but should it persist across maps? Should I set a different default fog colour for each worldtype and let the map (or the player) override it if desired? What about underwater fog? Should that be the same colour as the world or should it be it's own colour? Should I disable the view blend if we're underwater and fog is on? I kept the old hacky GLQuake Fugly Fog cvars in the engine but right now they do nothing - should they also take effect? Should they override the "Fog" command or not? Anything else?
For all of these I have my own ideas about what should be done, but I'd definitely be interested in hearing other people's opinions too.
Tuesday, October 19, 2010
Questions about Fog
Posted by
mhquake
at
2:08 AM
Subscribe to:
Post Comments (Atom)
5 comments:
I think fog should be a result of what the map dictates. Fog itself is not a make or break function, as you well know. Personally, if Quake was to be released tomorrow for the first time, I wouldn't want to have any control over fog; entering a level with fog would be a result of the genius that is the level designer, and that would be something that is totally 1996.
Just my opinion. 1996 was a long time ago, but I definitely like how you take upon the original intent of Quake through all of this.
For 1.8.666b I just copied what Fitz did and reset the fog at the start of each map, but should it persist across maps?
--- No! Some engines do/did this and people were upset. Always reset.
Should I set a different default fog colour for each worldtype and let the map (or the player) override it if desired?
--- Not for me, the map should decide, the player be able to override. The engine should not change the map's atmosphere by default (and fog does that).
What about underwater fog? Should that be the same colour as the world or should it be it's own colour? Should I disable the view blend if we're underwater and fog is on?
--- Not sure if and how. Maybe in the colour of the liquid surface texture? Or is that what the viewblend (the tinting?) already does?
I kept the old hacky GLQuake Fugly Fog cvars in the engine but right now they do nothing - should they also take effect? Should they override the "Fog" command or not?
--- Never heard of those, I'd say make "fog" the master.
I would suggest a default_fog/ fog_default setting, which would be used unless there is a fog key in the map..
That way, fog persist across maps (using the default settings, which could just be 0 to disable) but if a map specifies specific fog settings, they would be used instead.
The reasoning behind this, is that resetting fog on every mapchange gets annoying real quick (not so much for single player mode, but all the more so in multyplayer mode, where maps ususally do not have any fog settings tied to them, and maps change a lot)
As for underwater fog, i'd say, just go with whatever you feel looks best ;)
> Not for me, the map should decide, the player be able to override. The engine should not change the map's atmosphere by default (and fog does that).
What I'm suggesting is that the order of precedent should be map, then player, then fallback on the default, which is only used if the player issues a fog command without a colour specified, and the default is only a colour, not density. In fact there is already such a default in Fitz, which is grey (0.3 0.3 0.3) for all worldtypes, and which has the exact same behaviour as what I'm suggesting. All that I'm asking is: should I tweak this 0.3 0.3 0.3 a little depending on the worldtype?
If QC sends an svc_fog message then it overrides any and all, of course.
> Maybe in the colour of the liquid surface texture? Or is that what the viewblend (the tinting?) already does?
The blend in DirectQ already does this correctly. The scenario I'm thinking of is where a map has green or blue fog, for example, but the player falls into a lava pit. There's a huge immediate visual discontinuity and loss of map atmosphere for you. In an ideal world the map or the QC should dictate this, but how many maps or progs do you know of that do?
Regarding persisting across maps, I can see valid opinions on both sides. Some players want it, others don't, and each side finds it annoying if the other side's wishes are met. And what about multiplayer where if you respawn your fog settings get wiped? That's important too. Sigh. I'm not particularly religious either way on this one.
I'm reluctant to provide cvars for this kind of thing. I've done so in the past, and people have complained to me that [X] doesn't work, only for me to have to point out to them that there actually is a setting for it. Providing cvars doesn't work, 95% of people never even touch them, so you have got to have a sensible default instead. The problem there is that the default I choose is always not going to be what some people want, and they're very often the people who never use cvars nor look at menu options.
This highlights to me one of the reasons why I was reluctant to do fog in the first place. I hadn't articulated it to myself at the time, but it's obvious in retrospect. When GLQuake first got fog it was a case of "whee, look at the pretty fog", then a half-arsed attempt to standardise behaviour, and then nothing.
So if a map doesn't specify a fog key, what is the mapper's intention? That the map should have no fog? That the player can choose? Or that it's an old map that predates fog? Or is the mapper thinking "fog? what's that?"
There is no right answer all of the time, so doing fog is in a very big way like opening Pandora's Box. And sometimes you're better off just leaving that box shut. But done is done now.
At the end of the day I'm all for the concept of giving the mapper control over how their map should look, but I also think that the player should have ultimate control. So I see the mappers wishes as being like a "serving suggestion" on food, for example, but the player might not like pickles or might be allergic to chicken. So if what a mapper wants causes the player's machine to run slow or to crash because the player has a crap 3D card, the player should be allowed to override. After all, the player is the person who went to the bother of downloading and running the map, so they deserve to be treated with some kind of respect.
Post a Comment