Week 11/2014: Bloom

edited 2014 Mar 21 in Developers
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:
bloom_super.jpg

The defaults are far more conservative, aiming to add a subtle glow to bright areas of the frame:
bloom_normal.jpg

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

  • The bloom looks great, though as yourself mentions that it's currently only post frame has some noticeable limitations that can sometimes have a negative effect on the visuals (i.e it can be overly strong when there is a big difference between the darkest and lightest things on screen).

    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 :)
  • Vermil wrote:
    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?
    You're correct, bloom is currently done after vignette and this effectively makes the vignette effect much stronger when the contents of the frame are bright. We could swap them around, or simply reduce the vignette darkness.
  • Some skies, such as Ultimate Doom's EP4 sky produce a huge sphere shaped bloom (very apparent in the start area of E4M3 for instance) in the middle of the players view that covers something like 80% of the sky and blurs out a huge amount of the skies detail.

    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.
  • Further testing reveals the black screen issue seems to occur every time one switches between games that have different vsync settings (i.e game A has vsync on, but game B doesn't, or vice versa).

    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.
  • I think it would help considerably if you recorded a short video of the problem you are seeing. This is very likely to be either platform or video system specific. On my Windows dev system I'm seeing nothing which mirrors your description.
  • Further experimentation reveals that when I get a black screen, going into the taskbar menu and manually toggling the Vsync setting to the opposite of whatever it was set to (or using the reset to default option), fixes the black screen and restores the game view.
  • Seems to be a similar effect to when you set sky radius to zero. Images would help I guess.

    Love the bloom effect. :)
  • I have been using version 1.13.1 and have been perfectly happy with it. I wanted to see this new bloom though, so I installed the latest build. I didn't want to loose my 1.13.1 so rather than upgrade I just installed the new version to another drive. I did not think about the possibility of the new version overwriting things in my Doomsday Frontend folder found in my documents folder. As you have said, the bloom effect is set very modestly by default and I was not sure that I was seeing the difference so after playing a couple of levels I tried to play my version 1.13.1 to compare but it would not start, crashing with a segment violation.
    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.
  • The bloom options are found under camera lens on the renderer appearance menu.
  • PostFatal wrote:
    I do not see how to make adjustments to the bloom. Does it require input through the console?
    You can do it from the console certainly. However, as depicted in the original post, the settings for Bloom (like most others) can be adjusted from the Renderer Appearance editor. This can be accessed via the gear button in the Renderer Settings menu of the task bar, or opened directly from the console using the rendedit command.

    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).
  • DaniJ wrote:
    PostFatal wrote:
    I do not see how to make adjustments to the bloom. Does it require input through the console?
    You can do it from the console certainly. However, as depicted in the original post, the settings for Bloom (like most others) can be adjusted from the Renderer Appearance editor. This can be accessed via the gear button in the Renderer Settings menu of the task bar, or opened directly from the console using the rendedit command.

    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).
    exactly, -userdir what? not all of us know these things. You and others use this everyday and understand the ins and the outs, some of us are not so blessed with this knowledge. We fuddle around until something looks good. There must be a way to make all of this simpler for the average Joe and not direct it only to the initiated. It seems that more and more you are only speaking to an elite. No wonder people keep making reference to zdoom or gzdoom or boom or other such renderings. I've tried hard to keep up but it is getting beyond me.
  • By default Doomsday stores your config's in the place you launch it from. This can be altered with the '-userdir <folderpath>' command line option.

    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.
    PostFatal wrote:
    DaniJ wrote:
    PostFatal wrote:
    I do not see how to make adjustments to the bloom. Does it require input through the console?
    You can do it from the console certainly. However, as depicted in the original post, the settings for Bloom (like most others) can be adjusted from the Renderer Appearance editor. This can be accessed via the gear button in the Renderer Settings menu of the task bar, or opened directly from the console using the rendedit command.

    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).
    exactly, -userdir what? not all of us know these things. You and others use this everyday and understand the ins and the outs, some of us are not so blessed with this knowledge. We fuddle around until something looks good. There must be a way to make all of this simpler for the average Joe and not direct it only to the initiated. It seems that more and more you are only speaking to an elite. No wonder people keep making reference to zdoom or gzdoom or boom or other such renderings. I've tried hard to keep up but it is getting beyond me.
    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.
  • I too am nervous, I don't wish to offend anyone. I love Doomsday but all of this tech talk is way over my head. If there is a feature that can be adjusted then I want it to be in a menu with a slider that shows it's upper and lower limits. In fact, more than a slider, I would like to have up and down buttons. Too many times, trying to move a slider with my mouse has been either over or under what I am shooting for. I understand keeping things trim but the average user is not going to bother trying to learn console commands and variables, it will only frustrate them ( and me ).
  • While I can appreciate that some things are not immediately obvious and so possibly somewhat frustrating, we do however have a wiki, which contains the Readme and a user guide that covers things like -userdir. In addition to the wiki, the forum has its own search facilities and theres even the Codex (if you want to research detailed, programmer level info about specific things).

    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.
  • PostFatal wrote:
    In fact, more than a slider, I would like to have up and down buttons. Too many times, trying to move a slider with my mouse has been either over or under what I am shooting for.
    If you need precise control, simply right click the slider and type in the value you want in the edit field that appears :)
  • wow, I had to use edit and manually delete my post. No delete button? Strange.
  • The bloom effect is so cool real time shadows would be epic for the lighting O:-)
  • I have noticed that the frequency in which new builds are posted in the repository or alert list has been less lately.
  • Thats odd. There have been three new builds in the last two weeks and they're all listed on the homepage.
  • But it used to be a build every 2 or 3 days, sometimes one a day :P
  • The automated builds usually follow a biweekly schedule. However we may decide to run additional builds whenever we feel there is a need to do so, e.g., if we need to release a patch or we're rapidly iterating some significant change/feature. During a candidate phase the schedule is mostly abandoned and we keep putting out candidates until we've got a suitable version to call stable.
  • PostFatal wrote:
    There must be a way to make all of this simpler for the average Joe and not direct it only to the initiated. It seems that more and more you are only speaking to an elite.
    One of my top priority goals of recent times has been, and continues to be, making Doomsday more approachable and easy to use. As we can see, the new UI framework that has been developed over the past year is now allowing us to make tangible steps toward this direction. Doomsday is quite complex, though, and development time is limited, so progress isn't as fast as it would ideally be.

    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.)
  • Well, it is good that progress continues as it has been.
Sign In or Register to comment.