[HN Gopher] Godot 4.0 gets SDF based real-time global illumination
___________________________________________________________________
Godot 4.0 gets SDF based real-time global illumination
Author : stephdin
Score : 315 points
Date : 2020-06-28 14:29 UTC (8 hours ago)
(HTM) web link (godotengine.org)
(TXT) w3m dump (godotengine.org)
| leetrout wrote:
| > Tim Sweeney and Epic Games for their confidence in helping us
| finance our research via Epic Megagrant.
|
| That's interesting. Since this is all open source I guess Epic
| could potentially benefit from this... It's nice to see they
| funded another engine.
| mhh__ wrote:
| From a business perspective, Unreal doesn't really do 2D as per
| se (Whereas Godot is very simple to use) so improving Godot
| keeps people away from other tools like Unity which do have
| features that compete with Unreal.
| ngold wrote:
| As a unity developer I'm drooling at godot. I can't wait to
| jump ship to open source. Don't get me wrong unity is great,
| but godot is super compelling.
| capableweb wrote:
| I'm someone who isn't at all knowledgeable about game
| development nor its industry, so forgive my ignorance, but
| what are you waiting for specifically?
| darkteflon wrote:
| Yes, why are you waiting for Godot?
|
| Sorry, I'll get my coat.
| colejohnson66 wrote:
| One thing many of the big players do that Godot doesn't
| is require telling the user they used that engine. If you
| use Unity, you need to show the Unity splash screen
| unless you pay the big bucks; Godot requires none of
| that.
| capableweb wrote:
| So why would someone wait for that feature before
| changing to Godot if that's already a feature?
| adanto6840 wrote:
| For Unity, the "big bucks" is $35/seat/month -- that gets
| you the ability to make a build without a splash screen &
| without showing any Unity logos, etc.
|
| For small shops (ie low or no revenue), you only need to
| pay that when you're ready to actually ship/make a build.
|
| Note that the costs are higher if you're revenue is huge,
| it goes up to like >$100/seat/month or similar IIRC, I
| think that kicks in if you're in the 7-figures of annual
| revenue.
|
| It's not free, and it _can_ get expensive -- but you have
| to do the math on what you get, how much each will cost
| you monetarily & in time / opportunity cost, etc. IMO
| Unreal looks pretty compelling, and if they had C#
| support we'd jump to it in a heartbeat; I really don't
| want to write C++ on a day-to-day basis. If Godot keeps
| it up, then it may be the answer, in another 18 months or
| so -- but probably not wholly a commercially viable
| option _quite_ yet, especially for mid-to-small shops.
| RMPR wrote:
| There's one thing that make me reluctant to use Godot
| though and it's GDScript.
|
| Edit: Seems like it's not a problem anymore, can't wait to
| try again.
| shmerl wrote:
| Doesn't Godot allow binding with multiple languages? You
| can even use Rust for that instead of GDScript.
| krapp wrote:
| The problem is few of those bindings are mature, nor can
| they be expected to remain up to date. I don't know of
| any games in Godot using anything but GDScript or C#.
|
| This will probably change in the future (I hope it does,
| and I really wish Godot just used WASM internally so any
| language that already compiled to it would work) but as
| of now it seems there's no point to using anything but
| GDScript or C#.
| shmerl wrote:
| You mean bindings aren't stable and require reworking all
| the time?
| CraftThatBlock wrote:
| There's C# and C++ support, with third-party bindings to
| other languages (Rust, Python, etc)
| glaberficken wrote:
| GDScript is very "python like", never feels like a
| hurdle.
| mrfusion wrote:
| Tell me more.
| jbellis wrote:
| You're not wrong, gdscript is pretty awful. It's only
| python-like for someone who's never used python. No list
| comprehensions, no tuples (which means no destructuring in
| assignment or function parameters), no first class
| functions, etc. It's like Python 1.x circa 1999, only
| worse.
| shmerl wrote:
| Godot will get to the point of competing with Unreal, no
| doubt about it. Especially since Epic do a poor job at making
| Vulkan renderer in Unreal work well, and Godot invested in
| Vulkan all the way.
| nazgulsenpai wrote:
| I may be naive but I think the coder in Sweeny likes to see
| what Godot is doing, and the skeptic in me thinks that Sweeny
| knows Godot would only ever really eat at Unity's marketshare.
| sbarre wrote:
| I don't think there's anything naive about this take..
|
| Why wouldn't a company like Epic, who is the dominant market
| player by far, put some funding into smaller open source
| research projects like this? Godot is no threat to them, and
| quite the contrary brings positive contributions to the whole
| industry.
|
| Not only is it good PR, but as they say a rising tide lifts
| all boats.
| pjmlp wrote:
| Because Unreal doesn't scale down like Unity does, by
| improving Godot, they reduce Unity's attractiveness to the
| small coding communities.
| PavleMiha wrote:
| Not sure what market you mean, Unity has a larger
| marketshare. Can't find a good source for numbers but a lot
| of places are quoting that Unity has 48% of the total
| market and Unreal has 13%. Also not sure how this is being
| measured, but in my experience Unity is more popular.
| seelion wrote:
| Numbers are misleading here. I don't have any stats but I
| think Unreal games make more money.
| barbecue_sauce wrote:
| But the market here is game developers, not people who
| buy the games that developers make.
| philipov wrote:
| I think the metric Epic would be interested in would be
| the amount of royalties they would collect, so it would
| include the number of developers scaled by the financial
| success of their games. The financial success of the
| developers whose market share you capture matters a lot.
|
| Godot is more likely to be used by people whose games
| wouldn't earn enough to cross the threshold where they
| would owe money to Epic had they used UnrealEngine, so
| keeping them away from Unity makes a lot of sense.
| colejohnson66 wrote:
| Somewhat true. While it doesn't matter to the end user
| what engine is used if it looks and runs the same, it
| does if one engine can't compete in polish. And I don't
| know about you, but I _hate_ splash screens that just say
| (for example) "built with Unity". (Yes, splash screens
| hide loading, but as a user, I don't care what engine you
| used)
| SahAssar wrote:
| Measured by number of games that might be true, but
| measured by players I'd wager it's not.
| ktrl wrote:
| Godot is more likely to eat Unity's cake than Unreal Engine's
| cake.
|
| Unity is currently the dominating engine among mobile games and
| 2D games.
| pjmlp wrote:
| And if it is to believe their numbers, the large majority of
| Switch games as well.
| echelon wrote:
| Why would Epic put money into an open source competitor?
|
| I could see funding open source that is complementary or,
| perhaps better, something your competitor makes money on. But
| this?
|
| I was looking into Unreal for my next project, but Godot looks
| amazing. And they won't take a cut of my profits. It might do
| everything I need.
| chii wrote:
| epic's biggest competitor is unity. Godot competes more with
| unity than unreal engine, and therefore, it's a strategic
| attack on unity.
| imtringued wrote:
| Unless you are selling millions of copies I don't think Epic
| Games would care what engine you are using for your indie
| game.
| dr_zoidberg wrote:
| Well, in the same paragraph it goes on to say:
|
| > ...and Tim Sweeney and Epic Games for their confidence in
| helping us finance our research via Epic Megagrant. This new
| technique was developed entirely in the open and implemented
| under MIT license, so anyone can take it for using in their own
| engines and games.
|
| So there you go. Whatever Godot devs do, it's MIT and anyone
| can take. Epic gets an agile engine/team to do the research,
| and once a viable implementation exists they can analyze it and
| see it it's implementable within UE, should they want to.
|
| Of course, I write this without knowing if Unreal Engine has
| SDF Global Illumination. Maybe they already have it, but wanted
| to finance a new alternative to compare against their own.
| CyberDildonics wrote:
| In general the unreal engine has had voxel based global
| illumination for a long time and in fact was where it entered
| the mainstream. It added signed distance field stuff a few
| years ago as well.
| jfkebwjsbx wrote:
| An engine like UE which has decades and decades of work does
| not care about what a small engine like Godot does.
|
| The grant is more about avoiding monopoly claims, getting good
| PR and attacking Unity.
| [deleted]
| arifmeticus wrote:
| Is it possible to make a game that makes use of this new lighting
| system at high graphical settings and regresses to something
| simpler for low end computers?
| adanto6840 wrote:
| I get why Epic probably funds this, and I love to think how great
| Godot could be in another year or so (and how they could surpass
| Unity, etc). What I _don 't_ really understand, though: Why
| wouldn't Unity just implement this now, too?!
|
| It's open-source & MIT-licensed; if it's better than Unity's GI
| -- and it _IS_ better, because Unity does not currently have
| _ANY_ realtime-GI solution in their latest versions (they stopped
| licensing Enlighten for current /2020.x+ versions) -- so why
| wouldn't Unity just implement this, too?
|
| There's nothing that appears to be stopping them from doing so,
| other than pride perhaps; part of me really, really hope that
| they'll do exactly that, though I've yet to dive into the code to
| see how viable it may or may not be given Unity's current SRP
| situation(s).
| DizzyDoo wrote:
| Surely the current SRP situation is exactly the reason. It's a
| bit of a mess right now with many basic features missing, like
| the absence of Ambient Occlusion out-of-the-box with URP.
| anigbrowl wrote:
| Re-upping this blog post (sadly overlooked when first posted to
| HN) which asks the reasonable question 'why not just use Godot
| for general-purpose applications?'
|
| https://medium.com/swlh/what-makes-godot-engine-great-for-ad...
| codegladiator wrote:
| Yes please I have always wondered why is this not a thing
| krapp wrote:
| Because of Electron.
| blargmaster33 wrote:
| WPF already exist.
| jayd16 wrote:
| I can't read the linked article without logging in but in my
| experience its not ideal for several reasons.
|
| Game engines are designed around game loops executing code
| every frame and not around power efficient layout caching.
|
| Orthrographic hierarchies are how UIs are usually laid out
| and its a mild pain to move to a system that's depth sorted,
| with custom shaders etc. You can do more but you need to
| think about more and its harder for the UI system to know
| what parts of the screen can be redrawn. Games usually just
| draw it all every frame.
|
| Specifically for a game engines, they usually don't do things
| like OS integration for accessibility, subpixel font
| rendering, that sort of thing. In theory they could but
| usually game engines seem to roll their own system for this.
| Jasper_ wrote:
| There's a lot of functionality that a general purpose UI
| library has that Godot will likely never approach, like support
| for input methods in text editing.
|
| Productive applications require _extremely_ robust text
| editing, something that game engines don 't spend a lot of time
| with. Stuff like selection, text input for non-English
| keyboards, IME popups, that sort of thing. Even RTL text
| display is usually minimally unsupported.
|
| I also don't know of any game engine that supports multi-window
| display in any coherent way.
| divingdragon wrote:
| IME do have some uses for games, like for in-game text chat.
| I think it is reasonable to ask for at least some IME input
| capabilities in a game engine UI library. It is a must if one
| wants to make a multiplayer game targeting CJK markets.
| alfalfasprout wrote:
| Godot is open source. There's nothing stopping people from
| adding this functionality.
| Jasper_ wrote:
| I'd argue multi-window would require a substantial redesign
| of the graphics layer, so much that the maintainers would
| be uninterested in supporting it, and consider it out of
| scope.
|
| I can imagine IME support being integrated, but a giant
| pain, due to the wide variety of APIs across platforms, the
| fundamental disconnect in how text input is done in games
| vs. elsewhere, not to mention the "Linux wars": will you
| support ibus or fcitx?
|
| So it requires someone to step up and do the work, and
| don't be fooled: it's a _lot_ of work.
| ForLoveOfCats wrote:
| Godot 4.0 recently acquired multiple window support for
| the editor (which is built with Godot's UI and rendering
| system) and APIs for applying it to your own games
| robertely wrote:
| The Godot editor has a pretty good IDE. It's not VScode/Atom
| levels of functionality but it's improving steadily.
|
| Looking at the github issues they seem to have made a lot of
| progress with non-English inputs. Again, not perfect but
| improving.
|
| Godot 4 is adding multi window support. I would hesitate to
| judge it until it stabilizes but there's some hope there. It
| looks good from what we have seen so far.
|
| The rate this engine is improving is incredible, i'm finding
| a lot of reasons to be optimistic.
| benologist wrote:
| The parent poster is referring to accessibility of the
| applications produced with Godot, not the accessibility of
| the IDE. Edit: it's not .NET it's C++.
| cdash wrote:
| I don't understand, the IDE for Godot is created with
| Godot.
| cdash wrote:
| So you think that the Godot IDE which allows code editing
| will not support robust text editing? I don't know how robust
| it is currently but there is no reason why it wouldn't
| possibly support that in the future.
| speedgoose wrote:
| It's interesting. Can you easily deploy a Godot ui to the web?
| worble wrote:
| It supports web as an export target, although there are some
| limitations:
|
| """
|
| Unimplemented functionality
|
| The following functionality is currently unavailable on the
| HTML5 platform:
|
| - Threads
|
| - GDNative
|
| - C#
|
| - Clipboard synchronization between engine and operating
| system
|
| - Networking other than HTTPClient and WebSocketClient
|
| """
|
| https://docs.godotengine.org/en/stable/getting_started/workf.
| ..
| Lerc wrote:
| Much of these are not limitations of the export but of the
| platform. Web workers don't rise to the functionality of
| threads (wasm will surely grow decent thread support one
| day)
|
| GDNative by definition is for native.
|
| My game using C# exports to web fine, So that's working.
| Still a fairly huge download for a web game though, not
| really any worse than the Unity ones though.
| ttgo wrote:
| We often hear saying game engines redraw every frame so it is
| not appropriate for UIs.
|
| In Godot, you can set an option to redraw only when something
| change like in UI libs (for e.g Godot Editor use this option)
|
| However , I think one main aspect missing from UI libs is
| damage tracking (=redraw only the part of the screen that
| changed and tell the compositor to also only redraw that part).
|
| In terms of architecture, Godot is all I want. I wish I could
| build general purpose apps with it. Everything is a node & just
| simple trees. Abstraction of everything you need over all
| platforms. GDNative let you access everything from any
| language.
|
| I really wish I could build everything with Godot. I enjoy it
| so much more than web dev or android dev even for UI
| krapp wrote:
| >I wish I could build general purpose apps with it.
|
| Why can't you?
|
| I mentioned this in the previous thread about this, people
| build general purpose apps in Unity all the time. And Godot's
| own UI is a Godot application. There may be some edge cases
| where it doesn't work, but considering the current standard
| for native applications is to wrap webapps in individual
| Chrome instances, I can't see Godot being subpar.
| cercatrova wrote:
| You can. This is exactly what Flutter does, as I've commented
| on that thread you refer to on HN. It uses the Skia renderer
| that is like a 2d game engine to draw all the elements on the
| screen. They've had to reimplement everything though, like text
| fields and accessibility, so perhaps this is why it's not done
| more often.
| The_rationalist wrote:
| Any electron app is also a skia app and writing an app with
| skia only is needlessly too low level.
| dang wrote:
| I'll put https://news.ycombinator.com/item?id=23308303 in the
| pool for inviting a repost.
| mrfusion wrote:
| So if I wanted to make a simple 2d game, should I go with godot,
| pygame, or a JavaScript game engine?
| mrlala wrote:
| Asking the same question myself right now.. I was playing
| around with Gamemaker Studio yesterday and it seemed ok at
| first for something simple, but suddenly realized just how
| stupidly simple it is.. seems like it will be a pain to have
| any real control and do anything even a little bit complicated.
| Trasmatta wrote:
| Yeah, I've heard stories from a number of gamedevs who have
| said that using Gamemaker for anything other than non trivial
| projects can get really difficult and messy really fast.
| Godot is a much more robust engine, while still being pretty
| beginner friendly.
| krapp wrote:
| Godot.
|
| The sprite, tilemap and animation blending functionality alone
| are worth it, just grit your teeth and put up with gdscript
| (edit - or use C#). And it exports to the web anyway.
| tomtheelder wrote:
| You don't have to use GDScript, C# support is very strong at
| this point.
| krapp wrote:
| Fair point.
|
| Unfortunately for me anyway, I'm using the Steam version
| which doesn't support C#.
| mrlala wrote:
| Why can't you just download Godot yourself
| https://godotengine.org/download/windows and grab the
| 64-bit mono c# version?
| krapp wrote:
| I can, I just like using Steam to manage it. I'll
| probably change in the future, though.
| IggleSniggle wrote:
| If it's _really_ simple and you want a community of like-minded
| individuals, PICO-8 and similar are super fun:
| https://www.lexaloffle.com/pico-8.php
|
| Definitely more for hobbyist projects, it shares lots of the
| features that got me into programming in general.
|
| Features:
|
| - the .png image aka "cartridge" also contains all the code to
| run the game.
|
| - built-in tools for editing code, music, sound, sprites, maps
|
| - community of shared games where all the assets of the game
| are immediately editable by the players. A game hacker's
| platform.
|
| That last point can't be overstated. Hear some music you like
| in a game? You can modify the score and add it to your game.
| Playing a game but somethings not quite right? You might be
| able to do the necessary edits with your game controller. Want
| to "cheat" your way past that last boss? Edit the boss.
|
| It's the sweet spot between playing games and making.
|
| The more serious answer is that it heavily depends on your
| skills, the goals of your game, and your constraints. Knowing
| nothing about any of those, Godot seems like the clear winner.
| cdbattags wrote:
| Now someone please ELI5 how this compares to the algorithm Unreal
| Engine employs?
| Fraterkes wrote:
| This looks really cool and impressive of course, but I still feel
| the easiest way for most indies (which Godot is aimed at) to
| stand out is to get away from photo-realism.
| mhh__ wrote:
| Outside of photorealism, realistic lighting can really help
| immerse people in the world.
|
| Look at the quake RTX demo, there's something different about
| it compared to even a modern game with the approximated
| lighting.
| partyboat1586 wrote:
| Good lighting can make simple stylized shapes and colours look
| better.
| m12k wrote:
| Global illumination is orthogonal to photo realism. In fact, GI
| and lighting in general can help indies get away with
| untextured and/or low-poly models and still achieve a pleasant
| look (check out The Witness or Superhot for some examples.
| mortenjorck wrote:
| Exactly. There are many aspects to photorealism, and any
| subset of them can yield interesting, stylized effects. The
| Witness is a great example of stylized textures and geometry
| + hyper-realistic lighting; nothing else looks quite like it.
| kgwxd wrote:
| Superhot is the most innovative shooter I've played in years!
| sbarre wrote:
| Most 3D games that aren't photo-realistic still need semi-
| realistic lighting to look good..
| brundolf wrote:
| It's possible to have photo-realistic lighting without photo-
| realistic art. For example see the Link's Awakening remake:
| https://d1lss44hh2trtw.cloudfront.net/assets/editorial/2019/...
|
| Even the Final Fantasy 7 Remake arguably doesn't have a
| photorealistic style. Everything is very exaggerated and it has
| a distinctive art style despite using very physical rendering
| gh123man wrote:
| This is super interesting. The first video on the page sheds some
| light on how this actually works. It seems like they convert the
| scene into shapes that can be represented via SDF's and smooth
| min (https://www.iquilezles.org/www/articles/smin/smin.htm) them
| to blend into an approximation of the actual scene. While also
| capturing some general texture color data to apply and blend into
| the shapes. I assume the shader ray marches the scene to compute
| the lighting reflections and bounces. I am curious how the
| probes/nodes come into play and how they extract the light data
| from the shader output to apply it to the scene geometry (is it
| simply added in screen space?) I would be very interested in
| reading more detail on how this is actually implemented!
| wetmore wrote:
| Probably related to
| http://scholar.google.com/scholar_url?url=https://dl.acm.org...
| wetmore wrote:
| In video form: https://youtu.be/FkVlF5OzLcM
| oconnor663 wrote:
| > sheds some light
| hellofunk wrote:
| They explicitly say in the article that it does not involve ray
| racing, of which ray marching is a subset.
| klodolph wrote:
| It's possible that "it does not require ray tracing" means
| that it does not require extensions like RTX. Perhaps it uses
| voxel cone tracing, which you may say is technically not ray
| tracing, but if you called it ray tracing you wouldn't
| exactly be _wrong_ either.
| gh123man wrote:
| This was my interpretation. If you want to get technical,
| Ray tracing != path tracing != ray marching. However people
| often use them interchangeably.
| Rusky wrote:
| The article contrasts this approach with voxel cone
| tracing, so it's not that either.
| dcanelhas wrote:
| I would call it Sphere Tracing since that's what it's
| called in "Hart, John, C; Sphere Tracing: A Geometric
| Method for the Antialiased Ray Tracing of Implicit
| Surfaces; The Visual Computer-1995"
| Jasper_ wrote:
| It ray-marches the SDF when integrating them into the probes.
| You can see that here: https://github.com/godotengine/godot/b
| lob/481151be09108a3000...
| Jasper_ wrote:
| SDFs are computed on the GPU using a jump flood algorithm (
| https://www.comp.nus.edu.sg/~tants/jfa/i3d06.pdf ) from a
| series of voxels, storing color at each point.
|
| From this, a regular grid of probes are placed and integrated
| using the data from the SDF, using ray-marching. Material
| shading reads from the probes.
| [deleted]
___________________________________________________________________
(page generated 2020-06-28 23:00 UTC)