Week 11/2014: Bloom
Last week I added a bloom filter and started fixing things, while DaniJ was finishing up with the revised savegame code.
One more bigger thing for 1.14: I decided to add bloom as a new frame post-processing operation. This was a natural next step after having used background blurring with the Tutorial: bloom is essentially a selective blur that is drawn back on top of the frame using additive blending.
Here is an example of bloom with some very exaggerated settings:
The defaults are far more conservative, aiming to add a subtle glow to bright areas of the frame:
There are pros and cons to applying bloom without having reliable information about the true brightness of pixels in the frame. It can be applied without any further preprocessing while giving a nice bit of extra softness to the view, however some parts (like the player's fist in Doom) are so light that they invariably cause a bloom to occur, making them look a bit luminous. Still, overall the effect is nice enough to warrant having it on as default: bright skies in particular look very good against dark walls and rooftops. Naturally, it can be disabled with a cvar ("rend-bloom") or via the Renderer Appearance sidebar.
As candidate phase draws near, I've started fixing various annoyances and bugs. Last week we made the following noteworthy improvements:
One more bigger thing for 1.14: I decided to add bloom as a new frame post-processing operation. This was a natural next step after having used background blurring with the Tutorial: bloom is essentially a selective blur that is drawn back on top of the frame using additive blending.
Here is an example of bloom with some very exaggerated settings:
The defaults are far more conservative, aiming to add a subtle glow to bright areas of the frame:
There are pros and cons to applying bloom without having reliable information about the true brightness of pixels in the frame. It can be applied without any further preprocessing while giving a nice bit of extra softness to the view, however some parts (like the player's fist in Doom) are so light that they invariably cause a bloom to occur, making them look a bit luminous. Still, overall the effect is nice enough to warrant having it on as default: bright skies in particular look very good against dark walls and rooftops. Naturally, it can be disabled with a cvar ("rend-bloom") or via the Renderer Appearance sidebar.
As candidate phase draws near, I've started fixing various annoyances and bugs. Last week we made the following noteworthy improvements:
- There were a couple of invalid cvars / cvar value ranges in the game plugins. This was causing warnings at startup.
- Bug #1712 (enabling/disabling vsync on Windows) was resolved.
- UI improvement: popups don't open before their content is ready, which means there is no more ugly layout changes occurring on the fly when a dialog or something else pops up.
- Widgets can now share common UI images in a more elegant way, resulting in better performance when opening certain dialogs and folded areas.
- Profiling revealed a bunch of small inefficiencies related to the UI framework; these were addressed.
Comments
One thing I notice though, is that the bloom appears to notably taper off around the edges of the screen; is this due to the darkening of the camera vignette effect and that the bloom is being applied after it? Is it not possible to apply the vignette effect after the bloom? I obviously don't know the technical details, but I assume both the bloom and vignette areeach done in separate passes that can be switched around?
It's great to finally have the ability to disable Vsync again
This 'bloom sphere' moves with me as I move my view in any direction, revealing and blurring sky detail it covers or uncovers. I thought the sphere shape and the bloom not going all the way to the edges, was due to the vignette effect. Thus why I asked if the vignette pass occurred before or after the bloom pass.
Obviously, whether the strong bloom is visually appealing is a matter of personal preference (and users can adjust the intensity), but I thought it looked strange not going all the way to the edge of the screen.
That said, with the latest unstable build, I'm having sporadic (i.e not every time) occasions where unloading a game and loading another causes either the title Infine or game world of the new game to be rendered as completely black (well on one occasion there was also an outline of Doom's pistol in bloom stuck at the bottom of the screen); the menu and hud are unaffected and the game is running in the background. Whichever one is rendered as black remains the same each time I unload and load, until I quit Doomsday and restart it.
It doesn't matter whether the user uses the switch game option or returns to ring zero between the games.
Also, I'll elaborate a little on the above and say that once you get the black screen once, it appears to affect all games no matter their vsync settings, until you quit Doomsday entirely and restart it.
Love the bloom effect.
Also, in the new version I could not get into the console except through the menu. I finally realized that the key binding was set to tilde whereas my keyboard requires apostorphe. After going through the tutorial, I was able to get the binding set correctly. For some reason, doing that fixed the problem in my Frontend folder and I am once again able to play 1.13.1. I don't want to mess this up again so please tell me how I can set up my latest build to use it's own Doomsday Frontend folder. I really think that having the installation automatically make the folder in Documents folder is a mistake as it makes having different versions very difficult for the average person.
Also I do not see how to make adjustments to the bloom. Does it require input through the console? If so I think this makes things harder for average people that prefer sliders and tick boxes and do not like having to track down console commands and variables.
When running multiple versions of Doomsday on the same system it is sort of assumed that the user knows a thing or two about Doomsday and that in such a case it is necessary to tell each version to use a separate userdata directory (i.e., -userdir on the command line).
If you are using Snowberry, it will automatically put your configs and such in the documents folder. I admit that I haven't personally tried it, but I assume -usedir on the command line it passes Dday, should overrule this.
In Snowberry, one can add to the command line with the 'custom options' field, under developer under the settings tab.
I going to come out and say I have, ineptly, raised this with Deng Team on several occasions in the past. Deng Team hope the renderer profiles and upcoming tutorial system, which are admittedly impressive looking (i.e they are great demonstration's of the power of the new UI) will help deal with this, though I personally have reservations that it's more of a 'crutch', rather than a solution to an issue Dday has always had.
I fear 'crutch' is probably completely the wrong word (i.e overly negative), but I can't personally think of a term to describe what I am trying to say (i.e put the issue into words, which is also why I declared my above mentioned attempts to raise it as inept).
And now I am nervous.
Doomsday itself also includes numerous features whose sole purpose is to assist the user and make the whole experience more enjoyable. For example, console commands and variables can be listed (listcmds, listvars), and their help documentation located. You can search for "anything" using the apropos command, which aggregates all the information concerning "anything" from all sources.
It is often the case that the user simply does not know where to look. This is why the new tutorial is an important addition. For example, not knowing about the Renderer Appearance editor will severely hinder ones' ability to customize things. However, it is immediately accessible from the task bar. So once the user knows about the task bar (it is introduced by the tutorial), this should help to mitigate many of the common usability complaints we hear about.
Certainly, Doomsday is more complicated than comparable applications which appear to do a similar thing. However much of this complication is a direct result of better underlying technology. For example, the recent introduction of a Ring Zero and the client/server model are fundamental paradigm shifts that require a new understanding. There is only so much that we can do to educate the user a priori. From time to time it will be necessary for the user to search for information themselves, e.g., when a new term, say, a command line option, is encountered. (Although we do try to always link to the relevant documentation each time here in forum posts).
Naturally we try to hide such complexity from the user wherever possible. However, if you want to do more advanced things with Doomsday then it should be expected that some greater level of knowledge might/will be required.
Hiding this complexity is an ever-evolving process. In recent years I think things have improved considerably, from a usability perspective. However until we are able to drop snowberry there will continue to be some friction whenever a user who has grown comfortable in that environment is asked to resort to the command line. You'll see more work toward that goal in the upcoming 1.14 version.
Naturally having worked on the project for 15 years it is quite a challenge to maintain perspective on which concepts and UI elements are difficult to grasp for a casual user. With your feedback, though, I'm confident we are able to reach a UI that is both easy to use and remains powerful for advanced users and for development needs.
One major missing element that I've been planning is to make the Doomsday UI more self-documenting. Ideally, every feature and element would provide a way to call up a description of some sort so that resorting to readmes or the wiki would be unnecessary. (Of course, behind the scenes the information could be sourced from the wiki.)