Godot 4.0 gets SDF based real-time global illumination | Hacker News Reader

Godot 4.0 gets SDF based real-time global illumination

godotengine.org

433 pointsstephdin144 comments

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!

> sheds some light

They explicitly say in the article that it does not involve ray racing, of which ray marching is a subset.

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.

The article contrasts this approach with voxel cone tracing, so it's not that 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"

This was my interpretation. If you want to get technical, Ray tracing != path tracing != ray marching. However people often use them interchangeably.

It ray-marches the SDF when integrating them into the probes. You can see that here: https://github.com/godotengine/godot/blob/481151be09108a3000...

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.

Do you know how this ray marching compares to normal ray tracing time complexity wise, with regards to the amount of geometry?

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.

It's worth exploring ray marching.

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.

https://www.iquilezles.org/www/index.htm

https://www.shadertoy.com/view/Xds3zN

The Media Molecule team did a pretty amazing job integrating ray marching into a game pipeline and presented it at Siggraph

http://advances.realtimerendering.com/s2015/AlexEvans_SIGGRA...

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.

In video form: https://youtu.be/FkVlF5OzLcM

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).

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.

> I get why Epic probably funds this

Is it just to fuck over Unity?

You're getting downvoted, but Epic is extremely anti-competitive. This is likely the reason.

Epic's store offers a cheaper alternative to a near monopoly on digital game distribution on PC. How are they anti-competitive?

  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.

People like being able to buy their games in a single online store. They don't like having 5 different stores just to play their collection of games.

Therefore, Epic's exclusivity deals rub some people the wrong way.

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.

Epic paid obscene amounts of money to studios to force them come to their store and force exclusivity on them.

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.

How is obscene amounts of money forcing anything?

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.

> 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.

Steam isn't a monopoly though. They don't force exclusivity on their games and many Steam games can be purchased elsewhere (like on GOG).

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.

Yeah, but that is a monopoly for the publishers dealing with Steam, not for gamers which don't care as long as it is not broken.

Like Walmart or Amazon, the problem is for devs, not customers.

>Steam isn't a monopoly though

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!

The statement is from the perspective of the studios, not customers (studios want to sell in every store they can, customers only buy the game once).

Epic does not want to be a major store. They want to be the only store.

That is why they have been forcing exclusivity. That is the point: they are anticompetitive.

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.

Intel vs AMD in the past is a typical example on how money + exclusive deal could almost kill off a competitor.

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.

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.

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.

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.

"Unity does not currently have ANY realtime-GI solution in their latest versions"

Not 100% true; there is ray-traced GI.

I take this back. I tried it. It's completely fucking unusable. Editor crashes every couple of minutes, can't get it to work.

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.

Most 3D games that aren't photo-realistic still need semi-realistic lighting to look good..

Good lighting can make simple stylized shapes and colours look better.

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.

Superhot is the most innovative shooter I've played in years!

Incredibly even more tangential but:

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)

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

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.

PBR gets you photo-realism, GI gets you a self-consistent looking scene so fewer things look out of place

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?'

https://medium.com/swlh/what-makes-godot-engine-great-for-ad...

Yes please I have always wondered why is this not a thing

Because of Electron.

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.

I really love ImGui but what you described (accurately, I don't know why you got silently downvoted) is my biggest problem with it for general UI use.

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...

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.

Godot is open source. There's nothing stopping people from adding this functionality.

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.

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++.

I don't understand, the IDE for Godot is created with Godot.

Thanks, that's the point I was trying to make. It's more clear when you have read the article.

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.

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.

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.

Regarding multi-window, I notice that most electron apps don't support multi-window.

It's not impossible, but apparently very hard.

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.

It's interesting. Can you easily deploy a Godot ui to the web?

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...

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.

I'll put https://news.ycombinator.com/item?id=23308303 in the pool for inviting a repost.

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.

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.

As I mentioned, the lack of damage tracking is an important problem. It leads to high CPU/Battery usage which isn't great for laptop & phones.

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 :

https://godotengine.org/article/why-does-godot-use-servers-a...

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

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.

People already do to some extent.

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

> 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.

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.

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?

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.

So why would someone wait for that feature before changing to Godot if that's already a feature?

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.

Yes, why are you waiting for Godot?

Sorry, I’ll get my coat.

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.

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.

Doesn't Godot allow binding with multiple languages? You can even use Rust for that instead of GDScript.

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#.

You mean bindings aren't stable and require reworking all the time?

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.

[0]https://github.com/perbone/luascript

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.

There's C# and C++ support, with third-party bindings to other languages (Rust, Python, etc)

GDScript is very "python like", never feels like a hurdle.

Tell me more.

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.

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.

Because Unreal doesn't scale down like Unity does, by improving Godot, they reduce Unity's attractiveness to the small coding communities.

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.

Numbers are misleading here. I don't have any stats but I think Unreal games make more money.

But the market here is game developers, not people who buy the games that developers make.

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.

Only if you ignore the network effect of developers knowing your platform vs others...

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)

Measured by number of games that might be true, but measured by players I'd wager it's not.

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.

But that's my best guess..

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.

And if it is to believe their numbers, the large majority of Switch games as well.

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.

epic's biggest competitor is unity. Godot competes more with unity than unreal engine, and therefore, it's a strategic attack on unity.

Unless you are selling millions of copies I don't think Epic Games would care what engine you are using for your indie game.

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.

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.

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.

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?

So if I wanted to make a simple 2d game, should I go with godot, pygame, or a JavaScript game engine?

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.

You don't have to use GDScript, C# support is very strong at this point.

Fair point.

Unfortunately for me anyway, I'm using the Steam version which doesn't support C#.

Why can't you just download Godot yourself https://godotengine.org/download/windows and grab the 64-bit mono c# version?

I can, I just like using Steam to manage it. I'll probably change in the future, though.

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.

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.

All of the above, really. At the risk of worsening your analysis paralysis, another good option is LOVE2D, https://love2d.org/

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.

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.

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.

[0]: https://twitter.com/monolithofminds/status/12599133551769272...

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.

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

Now someone please ELI5 how this compares to the algorithm Unreal Engine employs?

Looks awesome! Might need to give godot a try :)

Reply on news.ycombinator.com