Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
21. February 2020


Global Illumination describes several algorithms used to calculate non-direct lights in game engines.  In Godot, it’s implemented using the GIProbe node, which can calculate emissive lights and secondary reflections, giving you more accurate lighting in your scene at the cost of performance.  In this tutorial we will go step by step through the process of setting up a GIProbe.  You can learn more in the video embedded below.


The first step for setting up global illumination is to go through the scene, select each model that will participate in the calculations and select Use in Baked Lighting in the Geometry Instance section.

image


Once you have your models set to participate, it’s time to create a GIProbe node.  Add a new Node to the Scene (doesn’t matter who it is parented to) of type GIProbe.

image

Now size the GIProbe box using the red/pink control handles, so that it envelops your scene.  You can have multiple GIProbes per scene and having them overlap serves no purpose.

image


Now with at least one light source in the scene, with GIProbe selected, click Bake GI Probe in the menubar.

image


This will calculate the indirect lights in your scene.  You can also have a GIProbe calculate the effects of emissive lights in your scene.  Emissive lights are lights that are projected from textures.  In a SpatialMaterial you can turn emissive on in the Emission tab by selecting Enabled.  Emission is the color of the light emitted, while energy is the strength of the energy emitted.

image

Emissive lights will only be shown after being baked by a GIProbe.  Emissive lights cannot move without baking the scene again.  You can cause a GIProbe to bake lights in code using the following code:

	get_node("../GIProbe").bake()

This is an expensive operation and should not be performed lightly.

There are a couple of ways to control the quality of the lighting generated by a GIProbe.  The first is by setting the Subdiv property in the GIProbe.

image

The higher the resolution, the better the results but more expensive the calculations.  You can also change the quality of lighting in Project Settings by enabling High Quality in Voxel Cone Tracing. 

image

Once again, this is a trade off between quality and performance.  Finally I should point out that GIProbe only works with the OpenGL ES3 renderer, not in ES2.  On ES2 you are instead stuck with traditional Light Baking, which takes less processing power, but produces inferior and less dynamic results.

Another thing to be aware of is dealing with the GIProbe inside the Godot Editor.  The GIProbe, as shown above, is a giant green lattice, which can make viewing your scene somewhat difficulty.  You may be tempted to hide the GIProbe like so:

image

Unfortunately this turns the GI off completely!  If instead you want to hide the GIProbe in the viewport, you turn it off in the viewport menu.  In the viewport, select View->Gizmoes->GIProbe.

image

This value is a toggle and controls ALL GIProbes in the scene.

You can learn more about Global Illumination and GI Probes in the video below.

Programming Design


11. February 2020


The comes a time in every project where you have to switch from a developmental Work In Progress branch to the main branch and that time just occurred for the Godot game engine.  The WIP Vulkan (and C++14) port is now the official branch on the Godot Github.

Details from the Godot news page:

The Vulkan port is not ready yet, but we need to get it merged into the master branch as a lot of further development planned for Godot 4.0 depends on it.

We plan to rework a lot of Godot's internals (core) to allow fixing long-standing design issues and improving performance (including GDScript performance improvements). Moreover, our long-awaited port to C++14 will also happen now that the vulkan branch is merged into master, and many other codebase-wide changes were waiting for this: code style changes, Display/OS split, renaming of 3D nodes to unify our conventions, etc.

The scope of the planned changes means that it would be impossible to do these changes in the master branch while keeping the vulkan branch separate, just as it would not be possible to do all those changes in the vulkan branch itself before merging into master: any rebase/merge would become extremely difficult due to the sheer amount of lines of code that will change.

Up until now, we've been very cautious with regard to what changes we allow in the vulkan branch, as well as what new PRs we merge in master, to ensure that the vulkan branch can always be rebased on top of master for a later merge. I've been rebasing it periodically over the past 8 months, and even though we've been very conservative in the scope of the changes, in later months a full rebase could easily take me a full day of work.

So we need everything in the main branch to stop limiting ourselves.

Moving the development branch from 3.2 to 4.0 has some side effects, specifically outstanding Pull Requests.  Unfortunately the simplest option seems to be the best in this case, to close those requests and hopefully “port” them to the new master branch.

While closing PRs may seem a bit abrupt, we ask all contributors to understand that this is done to help us cope with the sheer amount of proposals in parallel to having to refactor a lot of the engine's codebase. This closing does not mean that we reject the PRs, nor that we do not seem them as worthy contributions. But by asking the authors to re-assess their own proposals and make them compatible with Godot 4.0, we will save a lot of precious development time and get ourselves some breathing air in the current overcrowded PRs.

Closed PRs will have the salvageable label, which we use to denote PRs with code that could be salvaged to make a new, updated (and possibly improved) PR, either by the original author or by a new contributor. So we will not lose code in the process, since everything will still be accessible from the closed PRs and easily identifiable thanks to the salvageable label.

If you use a major release version downloaded from Godot’s download page or from Steam, this change doesn’t actually effect you.  If you want to check out the new Vulkan master branch but don’t want to build the code yourself, you can get a nightly build here.

Learn more about this change and it’s ramifications in the video below.

GameDev News


3. February 2020

The Epic MegaGrant program was first announced at GDC of 2019 and is a $100M fund by epic games to support game developers, open source projects and others.  The Godot Engine project just joined past recipients such as the Blender foundation, receiving a cool 1/4 million USD in funding.

The story was broke by Gaming On Linux, but has been all but confirmed by Tim Sweeney, CEO at epic, in this Twitter exchange.

image

Details from GamingOnLinux:

Some good news to share for the free and open source Godot Engine, as the lead developer Juan Linietsky announced during GodotCon that Epic Games have approved them for an Epic MegaGrant.

This was announced during Linietsky's talk on porting Godot Engine over to the Vulkan API, which is coming with Godot Engine version 4.0 later this year. Epic Games have approved them for a sum of $250,000 USD which they've known for a little while, but they only just got the okay to announce it.

The GodotCon YouTube livestream video link is available here.  You can learn more about the Epic MegaGrant program here or by watching the video below.

EDIT – There is not an official news story up on the Godot website.

GameDev News


29. January 2020


After 10 months in development, Godot 3.2 has been released.  The release includes dozens of new features including C# support for Android and WebAssembly, glTF2.0 support, a new Android build system and a ton more.

The primary features of the Godot 3.2 release include:

This only represents the top level features, there were a ton of smaller changes and improvements, for a complete list of changes check out the complete changelog.  You can learn more about this release in the video below.

GameDev News


18. January 2020

GotM.io (Game Of the Month) is a completely free hosting services for hosting and sharing your Godot developed game.  In just a few moments you can host your Godot developed game by simply uploading the PCK file.

First you need to be able to generate a PCK file, a process we just described in this tutorial.  With your generated PCK file, you simply have to register and account using your GitHub, Gmail or Twitter credentials and upload.  Gotm.io recently launched the Game Hosting Dashboard enabling you to configure your home page and manage installed games.

This is just the beginning of GotM.  According to their roadmap there are a number of great features coming down the road including statistics, leaderboards, commenting, achievements, remote play together and more.  Check out GotM.io in action, including how easy it is to make and publish a Godot title in the video below.

GameDev News


AppGameKit Studio

See More Tutorials on DevGa.me!

Month List