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.
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.
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.
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.
The Media Molecule team did a pretty amazing job integrating ray marching into a game pipeline and presented it at Siggraph
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).
Is it just to fuck over Unity?
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.
They basically exploited their Fortnite money-making machine to try to become a monopoly on PC.
How is that not anti-competitive?
For reference, Steam has never forced exclusivity on partners to distribute their games.
As for cheaper, Epic didn't become they couldn't charge the same. As simple as that.
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.
Then Intel would enjoy a monopoly and instead of being stuck at Skylake for 4 years, we may have been stuck at Core 2 for 10 years.
Or maybe ARM, MIPS, Power or Itanium (!) would have had better opportunities to catch up with x86 and would be the dominant CPU.
Who knows, but AMD dying would have not benefited anyone who was stuck on x86.
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.
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!
Like Walmart or Amazon, the problem is for devs, not customers.
That is why they have been forcing exclusivity. That is the point: they are anticompetitive.
The enemy (Godot) of my enemy (Unity) is my friend.
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.
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.
Therefore, Epic's exclusivity deals rub some people the wrong way.
Not 100% true; there is ray-traced GI.
If you have the opportunity, do play Superhot VR.
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
Look at the quake RTX demo, there's something different about it compared to even a modern game with the approximated lighting.
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.
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.
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.
It's not impossible, but apparently very hard.
Let's say that you're working on a 3d model viewer or some AR app.
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.
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
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.
Electron/Web might eat lots of ram but I think the renderer is more optimised for UI and will use less CPU/Battery.
Also Godot has an internal architecture made for games which might be a bit overkill/less elegant for UI-only apps :
I'm not sure if the separation of logic and rendering in separate threads like that is the way you would build a high perf UI library
That article mentions one example, the Trello clone (frontend?), but there are others like in this Reddit article: https://www.reddit.com/r/godot/comments/a809ij/godot_for_app...
* The Godot editor itself: https://docs.godotengine.org/en/stable/getting_started/step_...
* GUI Toolkit: https://github.com/Quark-Toolkit/Quark
* Pixel art editor: https://www.orama-interactive.com/pixelorama
* Particle effects editor: https://benhickling.itch.io/blastfx
* RPG builder: https://www.rpginabox.com/overview/
* Fantasy map editor: https://www.wonderdraft.net/
* Brainfuck IDE: https://github.com/wmww/BrainfuckIDE
* 3D presentation editor: https://github.com/janparkio/3d-presentation-godotengine
I've looked in to this myself and noted the following:
* It's easy to compile out features you don't want (3D, physics, etc.): https://docs.godotengine.org/en/stable/development/compiling...
* 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
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.
It's actually quite difficult to hack to make it not need 60+ fps updating; I've tried and was not really successful, wrote about some of the issues on reddit: https://www.reddit.com/r/cpp/comments/hcpoc0/how_to_add_a_gu...
The following functionality is currently unavailable on the HTML5 platform:
- Clipboard synchronization between engine and operating system
- Networking other than HTTPClient and WebSocketClient
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.
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.
Seems like it's not a problem anymore, can't wait to try again.
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#.
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.
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.
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.
Sorry, I’ll get my coat.
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.
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.
Unity is currently the dominating engine among mobile games and 2D games.
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.
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.
But that's my best guess..
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.
The grant is more about avoiding monopoly claims, getting good PR and attacking Unity.
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.
Definitely more for hobbyist projects, it shares lots of the features that got me into programming in general.
- 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.
Unfortunately for me anyway, I'm using the Steam version which doesn't support C#.
To add another option to the others, https://www.monogame.net/showcase/ is fairly popular.
It's probably worth running through a tutorial in each and seeing what clicks for you if you have no experience.