[HN Gopher] Show HN: StratusGFX, my open-source real-time 3D ren...
       ___________________________________________________________________
        
       Show HN: StratusGFX, my open-source real-time 3D rendering engine
        
       It's been closed source for a long time while I worked on it on and
       off as a hobby research project, but yesterday the repo was made
       public for the first time under the MPL 2.0 license.  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.
        
       Author : ktstephano
       Score  : 387 points
       Date   : 2023-03-30 09:55 UTC (13 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | EntrePrescott wrote:
       | The demo images look impressively realistic, congratulations. It
       | would be interesting to see some fps figures, including both
       | sides: maximal realism on "gamer PC" hardware... but also reduced
       | detail compromise on average hardware, which is relatively low
       | end.
       | 
       | 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.
        
         | ktstephano wrote:
         | Yeah I think as far as the future goes, removing the dependency
         | on OpenGL 4.6 and adopting Vulkan is the best way to go and
         | needs to be near the top of the priority list (maybe even very
         | top). It would allow MacOS, Linux and Windows to all have a
         | similar experience.
         | 
         | 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.
        
       | roboben wrote:
       | HN first post and no comment? I guess people marveling speechless
       | at the screenshots. Good job!
       | 
       | Would love to hear the backstory why you built that engine!
        
         | ognarb wrote:
         | It's definitely an impressive project. Building a real time 3d
         | rendering engine is not trivial
        
         | ktstephano wrote:
         | Hi, thanks! I've been interested in the low level tech behind
         | engines for a while and liked experimenting with things I
         | watched or read about. For some reason a couple years ago my
         | focus kind of narrowed in on realtime 3D graphics as an area I
         | really liked but didn't know much about. It was amazing to see
         | what people were accomplishing in games year after year (still
         | amazing to me). Eventually this interest became strong enough
         | that I decided to try and see if I could learn how to emulate
         | some of the modern techniques that the games were using. This
         | morphed into the StratusGFX project over time.
         | 
         | It's been fun but slow and also very difficult. Global
         | illumination was especially hard and had a few false starts.
        
       | mry2048 wrote:
       | Well done creating this! Thank you so much too for opening the
       | source after so much solo effort, I've read the high-level
       | architecture document and the things you've built sound very
       | interesting and make me excited to read the code.
        
       | noduerme wrote:
       | This is the kind of work I really love to see here. Whether or
       | not it finds footing it's clearly an amazing learning experience,
       | and it's extremely impressive in its own right. Kudos on a great
       | project.
        
       | bigcloud1299 wrote:
       | Fantastic work. Looks amazing.
        
         | ktstephano wrote:
         | Thanks!
        
       | nine_k wrote:
       | Looks impressive! Especially for real-time.
       | 
       | 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.
        
         | ktstephano wrote:
         | Thanks! In most of the demo scenes it can get 60+ fps at 900p
         | and 1080p on an Nvidia GTX 1060. That's currently the only
         | hardware I can test it on. On more difficult scenes from the
         | demos I can generally get 30-45 fps.
         | 
         | 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.
        
           | sosodev wrote:
           | Do you think it would be possible to reduce the version
           | requirements to OpenGL 4.3 / OpenGL ES 3.0? Then it might
           | possible to port this engine to WebGL2 and WASM and support
           | all platforms via the browser. Maybe that's a silly idea but
           | I think it would be really cool and perhaps easier than
           | porting to Vulkan :)
        
       | esperent wrote:
       | I couldn't find the repo on your page, probably I missed it
       | somewhere while distracted by the lovely screenshots :)
       | 
       | 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.
        
         | ktstephano wrote:
         | I don't really know what to feel about the current wave of
         | AI/machine learning. It's been moving very fast and I don't
         | think we've seen the end of the story as far as copyright
         | concerns go.
         | 
         | 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.
        
           | samstave wrote:
           | Can you make an AI 'robots.txt' style disclaimer that this
           | may not (currently) be included in ANY AI implemented
           | stack/sideloading/whatever into a closed codebase?
           | 
           | (or word the above in the appropriate manner to achieve
           | result (AI LOCKOUT))
        
         | remram wrote:
         | The commercial bots scan your code anyway, the open license
         | only allows well-behaved humans to use it too.
        
       | dheavy wrote:
       | This is really great work! Keeping a tab on that,
       | congratulations. I marvelled at this.
        
         | ktstephano wrote:
         | Glad you like it!
        
       | capableweb wrote:
       | This looks awesome, quality is amazing for being so early.
       | 
       | 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 :)
        
         | alphanullmeric wrote:
         | Why does it seem like bevy has produced far less spectacular
         | results then much newer c++ engines with a fraction of the dev
         | team? Cherno's engine also comes to mind.
        
           | capableweb wrote:
           | Bevy spend time on more things than just graphics, it's just
           | one part of the framework and engine. The ECS system is vast
           | too, probably a lot of time went into it
        
           | widdershins wrote:
           | I think bevy is a much more ambitious 'total' framework for
           | making games. Plus, I think by its nature Rust forces you to
           | deal with the really hard questions up front, and get them
           | right first time. In C++ you can punt some of these questions
           | and build a less-than-perfect architecture more quickly.
           | Please don't think I'm disparaging C++, I develop in it for
           | my day job. But I do think there are different trade-offs at
           | different stages of a project's lifetime.
        
       | pyuser583 wrote:
       | Very cool!
        
       | danparsonson wrote:
       | Kudos! Really impressive work :-) It's long been a dream of mine
       | to build an engine like this - much respect to you for actually
       | doing it!
        
       | stevefan1999 wrote:
       | Would someone like to port it to Vulkan so we can try this out on
       | mobile?
        
       | andrewstuart wrote:
       | Readme needs to state who it is for, where it is best used, what
       | platforms it targets, who the team is working on it and the short
       | medium and longer term goals, and importantly, why you made it
       | and why a developer should use it.
       | 
       | Some open source projects like this can become huge. You never
       | know what might happen.
        
         | ktstephano wrote:
         | That's a good idea. Later today I'll draft up a new readme with
         | this information. I think it would also be good to reiterate it
         | in the posts I have about the engine so I'll add it there too.
        
           | samstave wrote:
           | May as well provide a link back to this thread in the readme
           | as well for additional context ppl can get from the HN crowd.
        
         | ibobev wrote:
         | When the project includes some 3D renderer the readme needs
         | also to include some screenshots.
        
           | justinclift wrote:
           | Definitely. Even if they're pretty small, with the user
           | needing to click on them / open in new tab to view them in
           | full glory.
        
           | ktstephano wrote:
           | That's something I'm trying to figure out. I had an earlier
           | version of the readme that had one, but I ran into an old
           | issue where GitHub complains that the repo is over its
           | storage quota. Even after downscaling the image to less than
           | 1mb it still complained so I think I have an issue leftover
           | from an older version of the codebase (I used to store demo
           | assets in the repo).
        
             | orra wrote:
             | Curious. This script[1] lists the blobs in your repo, which
             | includes deleted files. It seems the deleted resources
             | directory takes up 364MB. That isn't tiny, but it isn't
             | supermassive either.
             | 
             | 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
        
               | Cthulhu_ wrote:
               | When I removed an old commited and then removed
               | node_modules folder, I had to do a git filter-branch and
               | a force push; it's doable for your own projects if you
               | don't object to changing the history a bit.
        
             | password4321 wrote:
             | https://rtyley.github.io/bfg-repo-cleaner/ (Java) seems to
             | be the favored tool; there's also
             | https://github.com/xoofx/git-rocket-filter (.NET) and the
             | built-in commands:
             | https://stackoverflow.com/questions/2100907/how-to-remove-
             | de...
             | 
             | 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!
        
       | jarrell_mark wrote:
       | Nice choice of license. MPL. Much clearer and straightforward
       | than LGPL. Existing files and changes to them must stay MPL
       | licensed. New files can be any other license.
        
         | actionfromafar wrote:
         | LGPL is pretty clear, it's just not very convenient. It's only
         | unclear when your start going through mental hoops to make it
         | seem more laisser-faire than it is.
         | 
         | For instance, it's just about impossible to distribute an iOS
         | application in a kosher way.
        
       | werdnapk wrote:
       | I'd recommend using lower resolution inline images on your
       | pages... they're very slow to download.
        
         | Cthulhu_ wrote:
         | Is it getting hugged to death? I can imagine Github has
         | bandwidth limits for pages.
        
         | nine_k wrote:
         | The images are fine, they just need to be hosted somewhere
         | faster, like maybe Cloudflare, or even just S3.
        
           | ktstephano wrote:
           | I'll look into both of those. I've been trying to figure out
           | a way to move away from using GitHub as storage for images
           | and 3D assets and one of those might be the answer.
        
             | nine_k wrote:
             | Sorry, my suggestions are useless; the problem is in the
             | PNG format (and indeed the raw byte size), not in the lack
             | of CDN (see sibling thread).
        
           | thangngoc89 wrote:
           | It's on Github Pages so CDNed by fastly already
        
             | nine_k wrote:
             | Oh snap, indeed!
             | 
             | 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.
        
             | naet wrote:
             | I've sped up Github pages hosted sites significantly by
             | adding Cloudflare's CDN. Github has something but it isn't
             | as good out of the box.
        
       | amrb wrote:
       | Great work happy to see project made for fun here!
        
         | ktstephano wrote:
         | Thanks!
        
       | grep_it wrote:
       | Thanks for sharing your work, this kind of stuff is awesome! What
       | resources did you use and find to be the most helpful when
       | learning about this?
        
       | 0xf00ff00f wrote:
       | Looks really well done, good job!
        
       | throw_m239339 wrote:
       | Looks great, maybe you could find a way to integrate it with
       | Blender and make a Renderer as a plugin. Does it do SSGI for
       | diffuse rays? Anyway I know it's a lot of work so kudos.
        
         | ktstephano wrote:
         | Currently all GI is handled using virtual point lights but SSGI
         | is something I would like to add as a complementary method. I
         | want to say that Godot does something like that where they have
         | a heavyweight solution and couple it with SSGI to enhance it.
        
       | fudged71 wrote:
       | You might want these images hosted on a CDN so the examples load
       | a lot faster:
       | https://ktstephano.github.io/rendering/stratusgfx/feature_re...
        
       | japhib wrote:
       | This is great! The images in the feature reel look amazing!
        
       | ar9av wrote:
       | Some software is not worth paying for to use. But other services
       | might.
       | 
       | 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.
        
       | zokier wrote:
       | In the Sponza scenes there is fairly obvious dithering going on
       | which makes the visuals look very unstable especially in motion,
       | idk whats up with that? Its most clearly visible in this
       | screenshot:
       | https://ktstephano.github.io/assets/portfolio/Sponza2022_3.p...
       | 
       | 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)
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2023-03-30 23:00 UTC)