Show HN: StratusGFX, my open-source real-time 3D rendering engine (github.com)
A feature reel showing its capabilities can be found here: https://ktstephano.github.io/rendering/stratusgfx/feature_re...
A technical breakdown of a single frame can be found here: https://ktstephano.github.io/rendering/stratusgfx/frame_anal...
It's still in a very beta state (bugs and instability expected), but I felt like it was a good time to make it public since a lot of its core features are mostly presentable. I plan to continue working on it in my spare time to try and improve the usability of the code.
Two main use cases I could see for it:
1) People using it for educational purposes.
2) People integrating it into other more general purpose engines that they're working on since Stratus is primarily a rendering engine. Any extensions to the rendering code that are made public would then further help others.
So I think it will remain very niche but I'm hoping it will still be helpful for people in the future.
85 comments
[ 3.0 ms ] story [ 163 ms ] threadWould love to hear the backstory why you built that engine!
It's been fun but slow and also very difficult. Global illumination was especially hard and had a few false starts.
Regarding integrating it in other engines, would love to see an attempt to integrate it with something like Blender and/or Bevy, seems like it would fit right in with both of those, and Eevee needs some competition in real-time rendering :)
They've also been working on patching up the core infrastructure of Bevy's renderer (fixing the shader import model, reworking the CPU side to enable batching and preparing for bindless, which are both huge optimizations). WGPU (the low level graphics library that wraps the individual APIs) also has issues with excessive locking of resources, so multithreading draw calls wasn't any faster than single threaded (A core part of Vulkan and DX12 performance is multithreading draw calls), but that should hopefully be fixed in the next few months.
In terms of the more "pretty graphics" side, cascaded shadow maps were implemented for distance shadow rendering, there's 95% ready PRs for SSAO (based on GTAO) and PCF (soft shadows), and TAA just got merged.
Finally, there's the desire to support all platforms, meaning there's a 10ton weight shackled to the renderer called WebGL 2, which doesn't even support compute shaders (which are the cornerstone of pretty much every new graphics feature from the past decade).
When it comes to picking a smaller open source game engine, it becomes essential to evaluate the hero developers involved: how committed are they to the project? is their effort sustainable ?
I think Bevy will work out long-term, because they have structured as a sustainable foundation with solid project management, however the lack of a hero dev that who can contribute to all the sub-crates [1] within the bevy ecosystem also means you have odd quirks in Bevy that will remain longstanding on the issue tracker, like for example setting the texture wrapping mode.
For that reason, Fyrox is worth serious consideration if you're constraining to the rust ecosystem of game engines/frameworks. Just one developer, but he's got the old-school experience and dedication, and the framework looks/feels much more familiar to a C++ game developer. It's not the sophisticated beast that Bevy is, but that's a good thing to the kind of person who would even consider these game engines/frameworks in the first place.
What really saddens me is that these hero game devs are still choosing C++ instead of rust. There are so many great flash-in-the-pan game engine/frameworks in C++, but they will never take off for a number of reasons.
When you look at how game devs approach development in C++, you come to realise that Rust is the language we wanted all along.
[1] https://github.com/bevyengine/bevy/tree/main/crates
Some open source projects like this can become huge. You never know what might happen.
You'll have to unprotect the branch to force push to GitHub, and anyone who has already cloned the repo may not appreciate basically having to start over, so better to get it over with ASAP!
I wonder if GitHub support would be helpful. I don't know if asking them to do a 're-pack' would be beneficial.
P.S. thanks for open sourcing this!
[1] https://stackoverflow.com/a/42544963
An image of this size should not be so heavyweight, but the images are PNG, not JPG or webP. This is why they are so slow.
I would consider adding JPG previews with links to PNG images for those who want to see every pixel as rendered.
What kind of hardware does it expect, and what's the FPS? (I know that performance may be far from what the architecture allows at this early stage.) What kind of API is it using: DX12? Metal? OpenGL? I did not seem to be able to find it mentioned.
Its backend only supports OpenGL right now. I think for a long term goal migrating to Vulkan would be a great option since it would unlock MacOS while still allowing Windows and Linux to run it.
I don't know much about WebGL2 - do you happen to know if dropping the requirement to GL 4.3 would be enough to make it compatible with WebGL2?
The OpenGL versions and variants have always been confusing for me.
WebGL 2 is close to desktop OpenGL 3.3. So probably far too outdated for this project.
https://developer.chrome.com/docs/web-platform/webgpu/
https://github.com/KTStephano/StratusGFX
BTW I saw you've released it under a fully open license (MPL 2.0). Have you considered that allows any company with a closed source commercial AI bot to scan and include your work in their training data? How do you feel about it? I've been holding back on open sourcing anything recently because I'm undecided on this.
For this project I felt like weak copyleft MPL 2.0 was a nice balance sitting in between strong copyleft GPLv3 and no restriction MIT.
(or word the above in the appropriate manner to achieve result (AI LOCKOUT))
Look at nextcloud: they wouldn’t have been anywhere near as big if they weren’t open source. Very few people would pay for the product but instead users now provide pull requests and improve the product. Meanwhile they make money now through enterprise support and specific plugins they provide for business.
That being said, I suspect that the following quote would be a major hindrance for a lot of developers looking for a rendering engine:
> "This code base will not work on MacOS. Linux and Windows should both be fine so long as the graphics driver supports OpenGL 4.6 (…)"
These days, most projects/developers looking for a 3D rendering engine - including those who, like me, don't have any sympathy left for Apple and their business practices - will need a wide cross-platform compatibility including MacOS and mobile (both android and iOS). So the point "Porting the renderer to Vulkan" that you list under "Future of StratusGFX" does indeed seem like a priority.
In that same vein, I'd point out that given the very large proportion of end users that have relatively weak hardware, especially on the GPU side, and even more so with the ongoing tendencial shift from desktop to mobile, it is crucially important to keep in mind that while maximal realism capabilities are indeed an important goal, the engine also needs to have good fallback compromise capabilities for less powerful hardware, i.e. cutting back on the most computationally expensive parts and details while still delivering a decent enough result at a good enough speed.
Then for the performance on weaker hardware... yeah this is something I've mostly neglected for now. All my testing has been on a desktop Nvidia GTX 1060 where performance is currently pretty good there.
One option would be for me to add fallbacks that remove reliance on certain realtime features (such as realtime GI) and allow for baked solutions. My initial goal was to avoid all baked solutions and only target realtime everything, but now I feel I need to cycle back and add in other options on top of what's there.
For instance, it's just about impossible to distribute an iOS application in a kosher way.
Also the lack of AA adds to the visual instability.
But still, nice work! I'd love to see what this could do with better assets/art (and maybe some extra shaders)
Right now it's using fast-approximate anti aliasing for its AA method but overall even though it's better than nothing it's definitely not good enough especially in motion. I'm going to keep FXAA as a togglable option but I want to add in TAA/TSSAA which look like they handle AA in motion much better.
https://www.youtube.com/watch?v=s5aIsgzwNPE
I've been out of gaming and this kind of scene for far too long, but I was amazed by the lights reflecting off the scooter wheel arch. (I don't know if that's new or not, but it's new to me).
Either way, amazing work, best of luck!
Edit to add question: Is the video linked above rendered / captured in real-time?
And yes! The video was captured in real time on an Nvidia GTX 1060.
Looking forward to seeing improved versions.
I'm tipping you've got a pretty bright future!