Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot 4.0 gets SDF based real-time global illumination

godotengine.org

Post reply on HN
Print view View original

131–140 of 150 posts

Re: Godot 4.0 gets SDF based real-time global illumination

#131

Post by mratsim »

paulryanrogers wrote: post #118
jfkebwjsbx wrote: post #116

Earlier quoted context omitted.

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.

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.

Re: Godot 4.0 gets SDF based real-time global illumination

#132

Post by bryal »

dahart wrote: post #97
hellofunk wrote: post #24

Earlier quoted context omitted.

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

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 you know how this ray marching compares to normal ray tracing time complexity wise, with regards to the amount of geometry?

Re: Godot 4.0 gets SDF based real-time global illumination

#134

Post by baxuz »

Jasper_ wrote: post #54
anigbrowl wrote: post #44

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

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 unsupp…

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.

Re: Godot 4.0 gets SDF based real-time global illumination

#135

Post by paulryanrogers »

jfkebwjsbx wrote: post #129
comex wrote: post #125

Earlier quoted context omitted.

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.

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.

Re: Godot 4.0 gets SDF based real-time global illumination

#136

Post by paulryanrogers »

Sander_Marechal wrote: post #126
comex wrote: post #125

Earlier quoted context omitted.

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.

Re: Godot 4.0 gets SDF based real-time global illumination

#137

Post by paulryanrogers »

mratsim wrote: post #131
paulryanrogers wrote: post #118

Earlier quoted context omitted.

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.

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 benefit…

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.

Re: Godot 4.0 gets SDF based real-time global illumination

#138

Post by mrlala »

Sander_Marechal wrote: post #126
comex wrote: post #125

Earlier quoted context omitted.

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

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

Re: Godot 4.0 gets SDF based real-time global illumination

#139

Post by ttgo »

krapp wrote: post #88
ttgo wrote: post #87

Earlier quoted context omitted.

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, God…

>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

Re: Godot 4.0 gets SDF based real-time global illumination

#140

Post by dahart »

bryal wrote: post #132
dahart wrote: post #97

Earlier quoted context omitted.

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

Post reply on HN