During the spring I’ve been exploring the possibilities and potential directions that a completely redesigned renderer could take. Continuing from part one, this post contains more of the results and related thoughts about where things could and should be heading.
Tag: render
Further rendering explorations – Part 1
When it comes to graphics, things sure have changed since the beginning of the project. Back in the day — almost 20 (!) years ago — GPUs were relatively slow, you had a few MBs of VRAM, and screen resolutions were in the 1K range. Nowadays most of these metrics have grown by an order of magnitude or two and the optimal way of using the GPU has changed. While CPUs have gotten significantly faster over the years, GPU performance has dramatically increased in vast leaps and bounds. Today, a renderer needs to be designed around feeding the GPU and allowing it do its thing as independently as possible.
With so much computation power available, rendering techniques and algorithms are allowed to be much more complex. However, Doomsday’s needs are pretty specific — what is the correct approach to take here? During the spring I’ve been exploring the possibilities and potential directions that a completely redesigned renderer could take. In this post, I’ll share some of the results and related thoughts about where things could and should be heading.
Status update
The spring months have been a little crazy with various Real Life time sinks preventing me from delving too deep into fun coding. Consequently, there has been little to no progress with the tasks on the roadmap, such as the multiplayer improvements for version 2.1. Given that several months have passed, it will be challenging to find motivation to restart this work. I am tempted to make some changes to the roadmap to get things rolling along again.
I have managed to steal away some time to explore an exciting new direction for the renderer, though. The basic gist of this effort is to completely revise how the game world is drawn, bringing it up to par with the recently redone 3D model renderer.
Odds and ends
I’ve been getting back into the swing of things with a set of smaller changes and improvements. I haven’t yet started work on the major focus of the 2.1 release, which is planned to be Multiplayer improvements.
2.0.2 will be out on Saturday, July 1st, with a couple of bugfixes that I hope will be useful. As usual, I will post the details after the build is available.
The recent changes include:
- Stability improvements. Several methods that went against the C++ standard were revised. Reliance on undefined behavior was leading to compiler optimization issues particularly with the latest GCC 7. Also, error reporting is now more robust. For instance, previously when something went wrong during busy mode (like engine startup), it could easily lead to a crash because the client app wasn’t reacting to the situation appropriately. When the error message was being shown, the application was still trying to do something in the background.
- More powerful model scripting. Starting animations and timeline scripts via Doomsday Script.
- The model renderer shaders support more macros for easier customizability. Generally speaking, using macros is more future-proof than writing completely customized shaders.
- Resource identification fixes. There was a duplicate IWAD spec for Heretic 1.3 vs. SOSR. Now only the latter remains; if you have problems with your Heretic IWADs, Clear Cache and restart Doomsday. Also, autogenerated package IDs had a problem with special characters in file names. Doomsday will choose package IDs based on the file name of the data file, however it allowed spaces and quotes be included in the IDs. This lead to problems because whitespace characters are used as separators in lists of IDs, and quotes may not be accurately escaped in Info strings. Again, Clear Cache is recommended.
- Assimp build option. There’s a new CMake build option (
DENG_ASSIMP_EMBEDDED
) for disabling the use of Doomsday’s customized version of Assimp. This allows one to configure Doomsday to use the Assimp installed as a system library, which is more common on Linux for instance. - More UI tweaks. Plenty of small things:
- Minor dialog layout improvements to avoid awkward dimensions.
- Changed the UI font on Windows.
- Added popup outlines for visual clarity.
- Fixed Home tab scrolling with the mouse wheel so that it doesn’t always jump to the previously selected item when switching between tabs.
- Game icons are refreshed when package availability changes. No more missing and incorrect icons shown for game profiles.
- Fixed missing window fullscreen state notification (was affecting the appearance of the “Quit” button on Mac).
- Monitor refresh rate. Yesterday I started working on monitor refresh rate configuration options. I realized these have been completely missing from the settings for some time now. Doomsday does query the supported display modes, which includes information about refresh rates, so now you have the option of choosing which refresh rate Doomsday will prefer when switching modes on Windows/Linux (display mode changes are not done at all on macOS). However, I recommend you consider adjusting the game pixel density instead of the screen resolution to keep the UI sharp and crispy.
Reflections
This week’s festive screenshot shows a bunch of test models that I’ve been using for developing environment mapping for 3D model reflections. While the current map renderer is not efficient enough for rendering cube maps on the fly, 3D models will be able to benefit from manually prepared cube maps.
This has been an interesting implementation challenge. It turned out the code I had previously written for transforming objects was not quite compatible with how cube maps needed to be rendered. I thought I was being clever by setting up player weapon models directly in view space, since they are affixed to the camera. For a while I was getting confused by all the different transformations needed for moving between tangent, model, world, and view space coordinates (cube maps are defined in world space). Models already in view space needed to be handled differently than objects in world space.
Eventually I decided to scrap that approach and wrote some new code that positions all models in world space, so their lighting and reflections can be done in the same way. This was much easier to get working correctly. K.I.S.S. wins again!
I’ve also been making some bug fixes for the upcoming 1.15.7 patch. Noteworthy fixes include support for Freedoom’s FreeDM multiplayer IWAD as a recognized game, and correct handling of command line options in the Shell app. The same fixes are already available in the 2.0 unstable builds.
Fog, shaders and 3D model scripting
Work on the new 3D model rendering is progressing at a good pace. It is turning out to also involve a lot of work on Doomsday Script improvements. Notably, this is now entering the territory of XG 2.0, where Doomsday Script bindings are added for accessing game world objects. Continue reading Fog, shaders and 3D model scripting
Progress with 3D model rendering for Doomsday 2
As previously planned, now that the stable 1.15 release has been dealt with, I’ve been continuing work on the new 3D model renderer. Here’s an update on what I’ve been doing.