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!
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.
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"
While they are related, and the terms are somewhat overloaded and depend on context, I wouldn't call SDF ray marching (aka SDF sphere tracing) a subset of ray tracing, at least not according to today's common usage of those terms. Unless you are using 'ray tracing' to mean the family of techniques that do anything with a ray (which is not the most common interpretation, IMO), then there are things each technique can do that the other cannot. Ray tracing most commonly refers to solving ray-surface intersections directly, and/or checking visibility strictly between two points in space, one or both of which may be infinitely far away. SDF ray marching to a surface is iterative and doesn't normally solve ray-surface equations directly, nor does it generally give you a surface normal. Ray tracing, in contrast doesn't allow for neat tricks like single-sample soft shadows, because it doesn't give you any other information about the scene except what's along the ray.
While I wouldn't insist on it, I think you could even argue that it's the other way around, ray tracing could be seen as a subset of ray marching, because it's possible to build a ray tracing query out of ray marching, but not possible to build a ray marching query using ray tracing, for example, the kind of basic ray marching you find on ShaderToy can tell you by how much you almost hit a surface, but vanilla ray tracing can't.
Oh, that's a super good, but very difficult question to answer in general.
SDF ray marching is quite commonly used in the demo scene and on ShaderToy without an acceleration structure (or "BVH" - Bounding Volume Hierarchy), while ray tracing usually has one. It's common for SDF ray marching scenes to have a very limited number of procedural hand-coded primitives, while ray tracing usually has a lot of simple primitives like triangles and spheres that come out of some modeling tool.
The Godot engine, however, has a BVH, so their SDF complexity will depend on that.
In it's inner loop, SDF ray marching does a point query against the BVH, while ray tracing does a line query. Both will end up traversing along the line (ray) through the BVH.
I'd guess that, attempting to compare apples to apples, ray marching has a slightly higher complexity in practice than ray tracing since it takes multiple iterations to reach a surface, where ray tracing (usually) gets there in one step. But there are multiple factors that can offset this complexity difference, because there are some amazing tricks you can play with ray marching to reduce the number of rays, and because ray marching often better utilizes a GPU.
> SDF ray marching does a point query against the BVH
Aah, alright. I've written a ray tracer that uses an (L)BVH before, so I'm familiar with how it works for ray tracing. What I couldn't figure out was how you'd use an acceleration structure for ray marching. Now that you spelled it out though, I suddenly think I get exactly how it would work.
> ... ray marching has a slightly higher complexity in practice than ray tracing since it takes multiple iterations ...
Great reply, thanks! It made a lot of sense.
> ... there are some amazing tricks you can play with ray marching to reduce the number of rays, and because ray marching often better utilizes a GPU.
Interesting. Now I'm gettin quite interested in exploring ray marching more.
I still need to learn more about how Godot is using ray marching, but FWIW there is a lot to learn on ShaderToy and IQ's articles about the basic techniques.
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).
It can't be that easy. Given Godot's completely different architecture, I presume that porting this feature over would require an almost complete rewrite.
Basically yes. Godot’s main userbase (hobbyists/small indie developers) aligns more with Unity than Unreal. Although Unreal has also appealed to some indie devs recently, it is still a heavy, bulky, monstrous beast of an engine that appeals more to AAA gamedevs and high-profile indiedevs.
I've been following the discussion in Twitter with Tim Sweeney and Godot, about the MegaGrant that Epic gave Godot. Have seen Tim many times commenting about the good progress they have made, before even granting the money.
I've got the picture that Tim actually likes the software, not just because they want to squash their competition. But of course they might have motivation to take users away from Unity, who knows.
In my books, Godot is a really nice engine that will get closer to AAA -engines when the 4.0 release comes out, their open source policy is really nice and you have access to all the source code, which can help a lot while developing your apps, so It's all positive and everyone who wants to develop games or 3D apps will gain from this if they choose to put their time into Godot, not just Unreal.
This sounds good for developers all around, and a minor inconvenience for gamers who are free to buy from as many stores as they like on PC. Yet could benefit gamers long term as it motivates Steam to be more competitive.
Anti competitive would be buying up competing battle royale franchises to reduce consumer choice.
Except Intel was the behemoth in the case. Here Steam is the one with marketshare, mindshare, and no serious competition before Epic. These exclusives are also usually time limited. This isn't Facebook buying whole studios and locking up content indefinitely.
> How is obscene amounts of money forcing anything?
Indie game studios have a very hard time surviving.
Giving them instantaneous access to a huge pile of money that allows them to declare success even before releasing a project is something most people cannot reject.
> Anti competitive would be buying up competing battle royale franchises to reduce consumer choice.
That is what they are doing but with game stores. They are effectively buying everything to dry the rest of the stores, reducing other stores choice of customers.
> This sounds good for developers all around
Not really. Devs get money, but they lose the product. Indie devs are not independent anymore. Etc.
If Epic had success building the monopoly, everyone would have suffered, not just devs.
What monopoly? There is a monopoly today; it's called Steam. It has an immense userbase and plenty of user loyalty; it's not going anywhere. If Epic succeeds, there will be two major stores rather than one.
Are you a pc gamer? Because if you are, I don't understand how you can't see Steam as a massive monopoly.
Perhaps you don't because they have done almost all GOOD with their monopoly power. Offline mode, library sharing, massive sales, etc.. but they are quite a monopoly.
If 99% of my library is on Steam, why should I bother buying somewhere else? It's just an inconvenience to me. Ok I can buy off GOG and have no DRM.... how does that really help me? I can already play it on steam with no problems, my friends can play the shared game on steam, I don't have to worry about multiple platforms etc..
Anyway- steam is a massive monopoly and we are lucky they use their powers for good!
Network effects make Steam a practical monopoly. And it's probably no coincidence it has lower rates for AAA studios since Epic has gained a foothold in the market.
Steam has plenty of money and users. It also had little serious competition before Epic. While I'm a fan of well regulated markets, I don't think punishing Epic would benefit anyone except Steam shareholders.
Except gamers do not care about Steam being a monopoly (they are just a distributor and does not set prices), but would really be hurt if Epic and exclusivity of titles starts to take hold.
The enemy (Godot) of my enemy (Unity) is my friend.
Is essentially what this thread is talking about.
At this point (ie. Epic sitting on truck loads of cash), lost revenue for Epic Games competitors is almost as good as revenue for Epic Games. That is what people are talking about when they say anti-competitive. It's another form of a price squeeze.
So Unity is suffering because a rich competitor is funding more competition? Having used Unity and Godot I don't think the former needs to sweat this modest sharing of the wealth with the latter.
If anything well regulated markets might tax oversized competitors to fund upstarts to maintain a balanced, competitive landscape. There's room for more than just two game-making tools.
The friction of having another store has a cost. I still got my copy of Borderlands 3 on Steam sale, I didn't even know it was initially an Epic exclusive. I think I'm not alone.
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.
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.
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.
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.
It is to Superhot as Superhot is to a regular shooter. Absolutely fantastic and one of the best fitting VR "ports" (it is more of a sequel, but I mean the game mechanics got even better in VR than with a kb+m/gamepad)
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
Illumination Tutorial for Software 3D Rendering (2/2+) [c++20] (https://www.youtube.com/watch?v=eXU-6_jmw7Q) was just released by Bisqwit and it goes over a rather naive implementation of real-time global illumination. The demo uses very basic geometry with a Minecraft look and shows the progress of paths being traced on the CPU. Compared to the Godot demo, the naive implementation is unworkably slow. Nevertheless, Bisqwit's video explains the concepts and basic code implementation admirably.
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?'
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.
If you use the Godot editor you'll see it's already sophisticated enough for general purpose UI applications. Of course you can keep expanding the requirements until no software in the world meets them but if you know what you're building then it might be the right choice. The main benefit that you won't get with almost anything else is true control over how every pixel gets actually rendered to the screen. It's able to make cross platform applications which since you're in full control over how they're actually rendered gives you tons of control. Resource utilization is fairly low and again you have full control of the stack so it's as good as you're willing to make it. C# is supported nowadays which gives you access to a mature ecosystem of libraries.
Is it the right solution for all UIs? Clearly not but IMO the UI landscape is a mess at the moment for anyone who wants to be able to build cross platform applications. There aren't really any adequate solutions as far as I can tell.
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.
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++.
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.
Would it be possible to write an app in, let's say, Swift + SwiftUI for an Apple device, using the native primitives to render the UI, and use Godot just for rendering the 3d part?
Let's say that you're working on a 3d model viewer or some AR app.
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.
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.
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
Just to clarify for those following along. Godot IDE is using the same UI components that you can use in your games. Godot 4 will support multiple windows. They're working on RTL I believe and it actually has a very robust code editor with debugger in the editor. Most of the points being raised here don't seem to be based on actual experience with the framework.
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
>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.
You can just make sure to set the low processor mode and you're good. The latest 3.2.2 introduced some fixes which help as well. It will only draw whenever a component actually requests an update.
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.
To be fair this is what Electron does too via the browsers. It's just doing it via the worse possible way by leveraging technology that's awful for building UIs. I'm a fan of flutter they're definitely onto something. I hope they can bring it to the desktop in a way that works well too.
* While Godot has a small file size, it's Hello World memory usage is ~300MB, which I think is even more than a Hello World in Electron (perhaps fixable by removing features)
* There is a setting to stop UI updates when the window loses focus which means it doesn't chomp CPU/GPU while not in use
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.
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.
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.
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.
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#.
C++ is very easy to use with Godot and integrate with the GDScript support. GDScript is also very good as a script language.
Been writing my own application mostly using C++ for the core logic and main application logic using GDScript. The interfacing between C++ and GDScript is suprisingly easy once you set it up.
But yeah stuff like Rust support is depending on the maintainers of that code to update to support latest versions of Godot.
I mean that language support comes in the form of random third party projects like perbone/luascript[0], so stability and completeness are entirely up to the whims and capabilities of the owner.
It's open source, of course, so that's to be expected, but it also means support for any language other than C# and GDScript is kind of a crapshoot.
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?
Not the OP, but I did jump into Godot full time for about three months last September. There were several significant land-minds that blew up in my face and it has made me lose some confidence in the core Godot team.
Without going into specifics, I think the problem is that the core team don't actually make games, they just work on an engine, so they don't appreciate the problems that I faced. (The same problem that Unity has, but at least they have the time to listen to devs)
I really want to love Godot. But I worry that the risks are too great to jump from Unity.
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.
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.
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.
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.
Nah, people will not stop using Unreal because it doesn’t support Vulkan. (Sadly) DirectX 11/12 and Windows is still the standard platform in high-profile gamedev...
DX lock-in will die out. Better sooner rather than later, but even if later, it still will. MS won't be able to poison the industry with lock-in forever. So those who invest in Vulkan today will be ahead of those who don't.
Godot did the right thing to completely ignore DX and focus on Vulkan.
> ...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.
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.
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.
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.
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.
Engine market share doesn't matter much if you're just going by games released.
Steam (the video game marketplace) gets hundreds of releases each day (seriously), and the vast majority of them are bad, and make no money.
I think if you're looking at serious money-making studios that put out good games (whether they are indie or AAA), I bet the engine distribution would look different than your numbers.
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.
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)
Makes me realize that photo-realism is not the most important thing. Illumination(and by consequence shadows) is. Bad looking 3D games look bad because of two reasons: Aliasing (which is the worst thing in 3D imo, but easily solved) and most importantly, because of bad illumination code. If the lightning code is realistic, you don't even need textures.
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?
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.
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.
Only use Pygame if you only know Python, refuse to learn another language, you're not planning on working on your project after a week, and you don't ever plan on having other people actually play your game.
Javascript engines are going to be inferior to any proper engine and offer less portability.
Depends if you want to sell it or not, plus your target platforms. IIRC Godot is not great at exporting to Switch or other consoles but maybe that has changed.
There have been several games made with Godot released on Switch recently. The main blocker is Nintendo's NDA's. There's a recent twitter thread[0] from developers of one of those games.
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.
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.
I like the old plugin model for its one click development cycle. The new plugin system forces to build the library which make the compile execute run cycle much longer
