Continuing the thread on Compute. This time we will enlighten a bit about how GPU works.
Common sense tells us that if one of these "compute units" have 64 threads, it means they have 64 parallel processors inside right? Well, not quite so..
Expand thread (🧵👇)to find out.. Link to the first thread in case you missed it:

https://twitter.com/reduzio/status/1832562398894366987

Compute is incredibly powerful, and can be used for rendering, physics or even for game logic, but also it can be very hard to understand.
I will try to do a few threads to explain at a Glance what exactly it is to kick-start your learning!
Expand 1st thread to find out! (👇🧵).. The first important thing to understand is that, if processors have "cores", GPUs have "compute units" (using AMD terminology, which is more standard).

Compute units can internally run a number of "threads" in "parallel" (32 to 64 depending on vendor), but this is fuzzy..

Have you ever wondered how it was like to render graphics during the PC gaming golden era? (1990s)
There were "video cards" available, but they were not exactly GPUs, they were far more basic. How much? expand thread to find out! (🧵👇).

Even though today you can buy an RTX 4090, which still, for compatibility, internally it still contains many of the same things as a video card from the 80s (called VESA, otherwise your PC may not boot)...

This is something that probably requires a bit more context. Many new folks are using Godot and ignore this, but the reality is that there was a _very_ long process from 2019 from 2023 where we rewrote almost the whole engine from scratch to make Godot 4.0.. (expand thread 🧵)..

https://twitter.com/gamedevdotcom/status/1832054898424508531

So the 3.x branch, while getting some new features, was majorly set in stone. As most problems users required major architectural changes to fix, solutions took many years to arrive.
Users complained about the same things over and over, and the answer was always "In Godot 4"..

One common mistake I see with new users of #GodotEngine interactive music is that, to create layered music you have to render the individual instrument tracks separately and then use AudioStreamSynchronized to join them. This is the wrong approach 🛑 (expand to read more 🧵).. To add/remove layers (typical of boss battles when getting closer, or progressive dungeon music that gets more epic as you go), you have to *render each layer accumulatively* with all instruments, then use AudioStreamInteractive to switch layers using "same position" option..

I see people looking at game art and mistakenly comparing it to how other games look as if thinking the tech must be the same. Folks, I am sorry to tell you, you are likely wrong because artists/devs are very good at fooling us 😉!
Here a thread to help distinguish (expand! 🧵👇) Lets first look at the "baseline" of "modern" graphics that people compare to, Doom 3 (20 years old).
You can tell its old because:
- Only direct light (no bounce, refs or AO).
- Low texture res.
- Low geom detail.
- Sharp stencil shadows.
A technical marvel, but outdated..

Many are surprised about why a language like GDScript (in Godot) has gotten so much traction and community, to the point its now in the 30 most loved programming languages (according to SO), despite early criticism of not being C# or a standard language.. (expand thread 🧵👇) I think what is most important to understand above all else is that the majority of programmers are not language purists. Programmers use a language as a means to an end. To put it simple:

Most programmers just want to get things done.

So how does this apply to GDScript?

Ever wondered how physics engines resolve multiple collisions at the same time, or how can something so complex as a cloth or rope be simulated? If you've never seen the code, it sure feels like black magic, doesn't it?
Here's a short thread🧵 explaining it (expand to read!👇).

As you can imagine, an algorithm in a single function taking a number of bodies or particles, then solving everything in one go is way too computationally and mathematically complex. So, how does do these engines do it so efficiently?..

I think this is a topic that would benefit from more technical explaining, given there is a _huge_ amount of demand to have in-editor gameplay in #GodotEngine.

Why does it work like this in Godot? (Expand thread below!) 🧵👇. The first thing to understand is that there is a key difference between Unity and Godot:

Godot runs the game in a _separate process_.
Unity runs the game in the _same process_.

Why does Godot do this?

Since this seems to have sparked some interesting discussion, here is my take of why I would _not_ implement something like Nanite in Godot and instead go for something else. Some complex technical points in thread, but make sure to fully unroll and read them first (thread) 🧵👇 The first thing to understand is that this type of technology is more the realm of cinematic renderers. It requires more modern, dedicated GPUs as a baseline.

Most Godot users currently do not need or aim for this with their games, hence not a priority..

One of the most interesting things when working with game engine technology is spatial indexing algorithms.

This means, ability to store 2D or 3D objects in space and query them efficiently without having to test every single of them. Here is a list of most common ones! 🧵👇 Octree/Quadtree. An octant (3d) is divided in 8 subregions (4 in 2D) recursively:
Pros: Fast updates, insertions, deletions.
Cons: Hard to balance, same object can be contained in many octants (making it less efficient and threaded queries harder)..
Typically used for rendering.

Since I'm at it. I'm going to write a brief history of how video game music playback happened on consoles on the technical side. This is a topic I love and you' ll see this is quite fascinating!

So, how did this start? (thread 🧵👇). 8 bit systems just had square (also called pulse) waves. This was just a simple oscillator moving dc from - to +. Some hw had quirks (envelopes, analog filters, basic dac, etc), Maybe tri, noise (for perc) or saw wave, but that was it..

Did you know? The original version of Godot (before it was open sourced) used the Squirrel programming language. ()..
What happened with it? Where did it go? Read on below.. (🧵👇) squirrel-lang.org
Squirrel is very similar to the Lua programming language () but it has some fundamental differences:
- Friendlier C style syntax
- Class support
- No GC
- Easier to bind

I much prefer it over Lua, myself, but It never got much traction..lua.org

Did you know? Common knowledge says that normal maps can be in OpenGL or DirectX format, and that different game engines/DCCs support different normal map formats.. but this is not quite true and more on the myth side.
Want to know why? Read below! (🧵👇). In truth, shader code in all game engines look more or less the same for processing the normalmap. A tangent basis is generated using normal/tangent/binormal and the normal map is just multiplied by it.
Notice, nothing is "negated" or flipped. It's a 3x3 matrix mult everywhere..

One of the things that makes me the the most proud in Godot 4 is also the least visible of them all: The engine foundation.

Godot 4 has now by far one of the best (if not the best) foundations you can find in a game engine... (thread blow🧵👇) This enormous amount of work took part from 2018 to 2022, the time it took Godot 4 to be made. The whole engine core was in large part redone, helping fix a tremendous amount of bottlenecks/design dead ends, while still keeping the foundation relatively simple..

Implemented an occlusion aware trilinear voxel filter in HDDAGI. This makes the reflections look a lot more believable (it looks like a low quality video version of the scene). This also has significant advantages quality wise... 🧵👇 First, this removes a lot of high frequency information from the scene, reducing the rays needed to converge (noise). But also, one of the devil's hidden in the details in HDDAGI is that every voxel _already_ has the full GI information in real-time, which is computed cheaply..

Ever wondered where the general design of Godot comes from? (all is nodes, even scenes are nodes).
Ariel and I were tech leads in several companies, and tech consultants for many, many others.
We worked with several game engines, our own, other's in-house or commercial ones..🧵👇 After working with almost a dozen projects, there is one thing we started to notice in all of them:

Developers will tend to fight the game engine and work around it.

Time and time again, we saw a client's project, we saw a hard struggle against the engine..

The best piece of advise I can give to those moving from Unity to Godot is: You have to imagine Godot "Scene Tree" as "A tree of components without entities". This has two quirks:

- Its much cleaner to understand scenes at a glance
- Composition is far more flexible.

Thread🧵 You don't need multiple scripts per node for behaviors, add more child nodes with scripts.
Also, prefabs or scene composition as a concept do not exist. You can simply instantiate or inherit any scene anywhere else. You can also make the instance editable and do local changes..

Want to understand in depth why the Unity debacle and why it is critical that FOSS becomes the de facto business model for the game industry?

Please make sure to read on!🧵.. To begin, you have to understand what is the "whole product" concept is:

There are many variations of it, but the main idea is as follows..en.wikipedia.org/wiki/Whole_pro…

While on the topic of switching software. I started doing 3D modelling far before most artists today. In 1994, I learned 3D Studio 2.0 and even back then I used this to make videogames. I was very comfortable with 3D Studio, but in the late 90s I moved to Linux..🧵 Of course, while working on Linux was a blast for me as a programmer, doing 3D on it was super hard. There were some FOSS projects at the time but nothing came close to 3D Studio. Until Blender came out..

I made this graphic to explain how I see in my mind the difference between proprietary and FOSS innovation.
FOSS is everywhere and relies on the collective intelligence, while proprietary can focus investment better and advance faster in specific areas.. but.. 🧵 While it seems proprietary innovation has an edge, FOSS can also catch up very fast, so proprietary software innovations often have a limited window to profit until FOSS alternatives appear and displace them. Unless they keep innovating and reinventing themselves, of course..