Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
22. September 2015


In this next part in the ongoing Godot Tutorial Series we are going to begin looking at how you work in 3D in the Godot game engine.  Today we are going to cover the basics of 3D, followed shortly by another tutorial on working with 3D models.  As always I assume you have gone through the previous tutorials in the series or understand the concepts they cover.


There is an HD video version of this tutorial available here.


3D in Godot


After working with 2D in Godot, you will find that 3D is remarkably similar.  No doubt you have been overlooking the interface since the first day you loaded Godot:



The scene works remarkably similarly, you create a hierarchy of nodes that compose your 3D scene.  In 2D, the root class for displayable nodes was CanvasItem.  In 3D, the base class is instead Spatial:



Creating a Simple 3D Scene


Now let’s assemble a simple 3D scene.  Beyond a TestCube, Godot does not have any built in 3D primitives, so a cube we shall test with!


As it was with the 2D world, you still need a root node to hold your scene, in this case I am going to use Node.  Now let’s go ahead and add a Cube at the world origin.  The node name is TestCube:



So your scene should look like:



And in the 3D view:



Now let’s pause a moment to discuss working in 3D…


3D Navigation and Editing


The 3D Panel in Godot works quite similarly to the 2D view, however different angles and viewports come into play.  One important thing to realize up front is the axis directions in Godot.  Godot is a Y-up engine.  That is, the Y axis represents up and down on your screen, while X represents left and right.  The Z-axis then represents depth… imagine you had the ability to push your hand into your monitor… that would be the Z-axis.  Keep in mind, different tools use different up-axis, so you have have to take this into account when importing models.


It’s also often handy to have multiple viewports open when placing things in 3D.  This can be accomplished using the View menu:



Here is the result of a 4 viewport view ( also available by hitting Ctrl + 4 ):



You can set the individual camera of each view by clicking the label at the top left corner of a viewport:



You can also freely rotate the camera.  By default the controls are:

  • Scroll Wheel – Zoom in and out
  • Middle Mouse Button – Orbit
  • Shift + MMB – Pan
  • Ctrl + MMB – Zoom

Modifying entities in the scene is a bit different than 2D as there is now an additional axis.  You still translate, scale and rotate using the same toolbar and hotkeys:



However, the resulting widget is a fair bit different.  There is a color coded widget per axis, enabling you to make edits a single axis at a time.  Here for example is a rotation in effect:



Each axis is colour coded.  Red is the x axis, green is y, while blue is z.  You can see each axis rendered in the grid behind with the matching colour scheme.


You can also transform using direct numeric entry, via the Transform-> Transform Dialog… menu:





If you come from a different 3D background, there are actually several settings to make Godot perform in a way you are more familiar with.  Click settings at the top right corner of the IDE and there are a number of 3D settings you can configure including configuring Godot to work like Maya or Modo if you prefer.  You can also resize the gizmo and alter it’s transparency, etc.




Creating a Camera


Ok, now that you know how to navigate around the 3D interface, let’s hop back to our 3D scene and add some life.  Even though you’ve added a box to our world, if you run the game you will see nothing.  There are a couple reasons for this, the first of which is that there is no camera in the scene.  Unlike a 2D game, the default viewport isn’t enough, you have to create a camera.


A camera is simply a Spatial derived node, simply add one to the root of your scene:



Be sure you add the Camera node inherited from Spatial, Camera2D will not work.  Additionally InterpolateCamera is probably not what you want either… think of that class as more like a Camera Swing  arm that helps move the camera around instead of as a camera itself.  I will probably cover this in the future.


Once the camera is added to the scene, be sure to move it so it can see your cube, like so:



With a camera in the scene, you can click the “Preview” button at the top right corner of any view to preview what a camera sees.  This is one of the ways a split view certainly comes in handy, use one or more views for positioning your scene, and dedicate one to previewing your camera.


If you look down at the Inspector with your camera selected, you will see that there are several settings:



Projection determines the type of your camera, Perspective or Orthogonal.  With a perspective camera, as things get further away ( z-axis ) they appear to be smaller, mimicking the way the human eye works.  With an orthographic camera, sizes stay the same.  As a general rule, a 3D game uses perspective, a 2D game use orthographic.

Fovy is the field of view, or the number of degrees along the Y axis the camera can see.  A FoV of 180 for example would allow you to see both your left and right hand if you held them out to your side.  Most games however use much lower values.  On consoles 60-75 are typical values, while on a PC where you are much closer to the monitor, a higher value like 90 is often used.

Near and far values control how close the camera starts recording, and how far out it captures an image.  Basically this is the “range” of the camera.  FOV, Aspect Ratio and Near/Far plane all go together to calculate the camera’s view frustum.

The Current value is very important if you have multiple camera’s in your scene.  Whichever one is flagged as current is the one that will be rendered.  If only one camera is specified, current does not need to be set.


Adding a Light


If you press play at this point, you will still see nothing, as there is no light in the world.  Just like in real life, no light, no visibility.  There are three options available for lighting:



An omni light is like a light that radiates in all directions.  This a typical table lamp without a lamp shade.

A spot light on the other hand is a light with a defined beam and direction.  Think headlights on a car or the light of a flashlight.

A directional light on the other hand is basically a massive light source with a direction and that’s about it.  Think… the sun.


In this example lets fake a sun by adding a directional light to the scene. At this point your scene should look something like this:



The directional light shows up as a big wireframe arrow in the 3D scene.  Using movement and rotation, position it so it’s shining down on your box on an angle, like so:



You will notice in the Inspector you can now set properties for both the light and the shadows it creates:



In this case we will stay with default settings.  The most important settings you will see in those dialogs are Shadow, which enables you to turn shadow generation on and off, Colors, which sets the color of the light, and Energy, which sets the intensity of the light. 


Now that we finally have a camera, a light and a 3D object, if we press play we should see:


TADA!  Your first Godot 3D application!


The Video



4. September 2015


While on vacation I have been looking at the process of extending the Godot Game engine using C++.  Due to the vacation, this isn’t a proper tutorial, I may do one later on when I have access to video, etc…  There is pretty solid documentation of the process in this post on the Godot wiki beyond that however there is a huge lack of information.  So the following is mostly trial and error.


I worked entirely in Visual Studio for this example and am working from the most recent source from Github.  If you have trouble working in Visual Studio with Godot, be sure to check out this post.


We are going to have to create several files in the modules folder, but don’t worry many can be copy/pasted from an existing module.  I created a new module called modTest inside the modules folder, and the contents end up looking like:




Many I coped directly from gridmap, but I will show the entire contents below.

def can_build(platform):
  return True
def configure(env):







void register_modtest_types();
void unregister_modtest_types();



#include "register_types.h"
#include "object_type_db.h"
#include "modtest.h"
#include "modtest_editor.h"


void register_modtest_types() {


void unregister_modtest_types() {




#ifndef MODTEST_H
#define MODTEST_H

#include "scene/2d/node_2d.h"

class ModTest : public Node2D {
  OBJ_TYPE(ModTest, Node2D);




#include "modtest.h"



#pragma once

#include "tools/editor/editor_plugin.h"
#include "tools/editor/editor_node.h"
#include "tools/editor/pane_drag.h"

class ModtestEditor : public VBoxContainer {
  OBJ_TYPE(ModtestEditor, VBoxContainer);

  ModtestEditor(EditorNode * p_editor);

  VBoxContainer * container;
  Label* label;
  EditorNode* _editor;

class modtest_editor_plugin : public EditorPlugin
  OBJ_TYPE(modtest_editor_plugin, EditorPlugin);

  modtest_editor_plugin(EditorNode *p_editor);

  virtual void make_visible(bool isVisible);
  virtual void edit(Object *p_node);
  virtual bool handles(Object *p_node) const;

  EditorNode * _editor;
  ModtestEditor* modtestEditor;



#include "modtest_editor.h"
#include "tools/editor/plugins/canvas_item_editor_plugin.h"
#include "tools/editor/editor_settings.h"

#include "scene/main/viewport.h"

#include <iostream>

ModtestEditor::ModtestEditor(EditorNode* p_editor){
  std::cout << "New Modtest Editor" << std::endl;

  this->set_size(Size2(600, 600));
  label = new Label();
  label->set_text("Hello World");

  _editor = p_editor;

// **************************** PLUGIN BEGIN ********************************************

modtest_editor_plugin::modtest_editor_plugin(EditorNode * p_editor)
  _editor = p_editor;
  modtestEditor = memnew(ModtestEditor(_editor));
  std::cout << "Editor" << std::endl;


void modtest_editor_plugin::make_visible(bool isVisible){
  std::cout << "Make visible" << std::endl;
  if (isVisible){
    std::cout << "Showing" << std::endl;
    std::cout << "Hiding" << std::endl;

void modtest_editor_plugin::edit(Object *p_object) {
  std::cout << "Edit" << std::endl;

bool modtest_editor_plugin::handles(Object *p_object) const {

  return p_object->is_type("ModTest");

So that was a mountain of examples, but nothing particularly complicated.


The SCSub and files simply tell the Scons build system how to build your module, both of them can be copied in unchanged from the gridmap module.  It’s only if your module doesn’t build for every platform or you need to do something other than compile all the included cpp files that you need to alter either of these files.


Next up are the register_types cpp and h files, which registers your type with Godot.  ModTest is a simple Node2D extension type, it can be registered using ObjectTypeDB::register_type().  Additionally we have an editor we want to show when editing our new type, that is registered using EditorPlugins::add_by_type() .  The TOOLS_ENABLED means that you are building Godot with full tooling support, as opposed to building just a game (without the editor in the generated binary).


Our extension is completely pointless.  It’s inherited from Node2D and well, that’s about it.  Obviously you would add functionality as you go.  The simple fact it inherits from Node2D makes it available in Godot as a Node:



Next we register an editor and a plugin for our ModTest type.  The ModtestEditor class is going to be the editor displayed within Godot.  It’s a simple VBoxContainer.  In this case all we do is add a label with the text Hello World then add it to the editor using the passed in pointer to the EditorNode.  This is generally where the majority of logic will go.


Next up is the modtest_editor_plugin which inherits EditorPlugin.  This class is loaded with Godot by the call EditorPlugins::add_by_type<modtest_editor_plugin>().  The important call is modtest_editor_plugin::handles(), which attaches the editor to the type it edits.  In the constructor, we create an instance of our editor.  The make_visible() method is called each time the editor is needed, or no longer needed and toggles the visibility of our editor.


As you add or select a node of ModTest type, the editor will automatically be shown:



Obviously this is a barebones example.  As I implement a more detailed example I will share the results.


28. July 2015


We covered viewports a while back but now we are going to go into a bit more detail, as it’s an important subject.


There is a 1080p version of this tutorial available here.   Please note, the full screen portions didn’t display properly in the video.


One very important thing to understand is, the very root of your scene, the node that owns all of the nodes in a scene, is ultimately a viewport.  Consider this hierarchy:


In that node if you run the code:

func _ready():


You will see:



So, no matter how you create your scene, you will always have at least one viewport.  On the other hand, you can create more viewports within the scene as we will see later.


Full Screen Applications


It’s possible to set your application to run full screen, both using code or in the application settings.  To do it with code, create a new autoload script as described here.  This is a script, derived from node, that gets run automatically when your game launches.  Use the following code:

extends Node

func _ready():
   var root = get_node("/root")
#Event called when viewport size changed  
func resize():
   var root = get_node("/root")
   var resolution = root.get_rect()
#Input handler, listen for ESC to exit app
func _input(event):
      if(event.scancode == KEY_ESCAPE):


Of course this code does a lot more than just set the application full screen.  Due to the app going full screen, it is no longer easy to close the window, so I’ve also wired in some code to handle shutting down if the user hits Esc.  There is also an event handler connected to fire when the resolution changes, we simple print the resolution to the console when it changes.


You can accomplish the exact same thing (much easier) using project settings, like so:


Please note there are two check boxes to enable!  First you need to enable the fullscreen setting, then you need to turn it on.


Viewport Scaling

Now to illustrate how resolution works in Godot, I’ve created a Sprite Node( not centered, at 0,0 ) using this image, which illustrates the various screen resolutions.



The actual image is 1920x1080 in size, so it should show us the results that various settings have on our game.  Here is a run, using default settings on my laptop which has a 1600x900 display. 

The following display settings are very important.


The following screenshots are all scaled down but maintain the aspect ratio of the source image.  The Viewport setting has a profound effect on the results.  The options are:



Viewport == disabled.  Resolution is 1600x900 ( my native resolution ) and display resolution settings ignored.



Mode == 2d.  Image size is 1600x900.



Viewport stretch mode.  Image size is 800x600.



It’s the ultimate results that make the difference.  When viewport is set to disabled, the width/height are ignored completely and the resolution of the device is used.  In viewport set to 2D, the width and height are used and the results are simply scaled up (or down) to match the resolution of the actual device.  While in Viewport, the results are actually scaled down to the resolution specified.  This means our actual render results are at 800x600 ( or whatever resolution you specified ).   You would generally use this last mode if you were trying to create a pixel perfect game, or if you are trying to render to a lower resolution to improved performance.  Keep in mind on most machines the results will look somewhat horrible.




Handling Aspect Ratios

Now this resizing works great when you are dealing with the same aspect ratios, but once they start changing, it has a much more pronounced effect.  For example, content designed for a 4:3 screen ( iPad ) will look horrible on a 16:9 screen ( Galaxy Note ) for example.  You also need to decide HOW you are going to deal with different aspect ratios.  This isn’t a new problem, people watching single def signals on HD displays have been dealing with this issue for years.

I created a new Sprite, this time using a sprite 379x124 pixels in size, like so:


Then automatically position it in the center of the viewport on load:


func _ready():


As mentioned earlier, my laptops native resolution is 1600x900, so everything looks fine with an HD resolution.  For example, here is the result rendered at 1280x720 full screen (but scaled down on the blog):



Looking good!  Now lets try 640x480, a not so HD aspect ratio:



Ewwww…. ok… obviously not what we want.  The result of the resampling to fit a 640x480 image on a 1600x900 screen as stretched our ship almost to the point of being unrecognizable.

You do however have options here, once again under display settings called stretch_aspect.



Lets see the result on our 640x480 scene:











You may notice the pictures are literally camera shots of my laptop.  This is because the screenshots don’t capture the black bar portions of the image.

Basically you can choose to simply rescale the aspect ratio, which causes the sprites to distort if the source and destination resolutions don’t have a similar aspect ratio.  Choosing Keep will cause it to keep the aspect ratio specified and generate black bars, either horizontally or vertically, whichever is needed.  You can also tell it to keep the height or the width aspect ratio.  The remaining dimension ( height if you chose Keep_width for example ) will then be scaled to fit, causing distortion in that direction.



As mentioned earlier, the root node in the scene is always a viewport.  You can however create a viewport node within the scene or embedded within another node.


Consider this hierarchy of Nodes for example:



In the Editor it looks like a complete mess:


But when you run it, you can immediately see the results:


The nodes added to the child viewport are positioned relative to, and rendered within that viewport.




The Camera2D class in Godot is mostly just responsible for manipulating the transform of the viewport.  A Camera automatically applies itself to the closest viewport above it in the node hierarchy, and if there isn’t one, it affects the root node instead.  Only one camera can be active at a time per viewport.


Otherwise using a camera is extremely simple.  Consider a scene like this that extends beyond the viewport:



Simply drop a Camera2D node into the scene:



Set Current To On



And your view will automatically update to represent the camera’s position




Taking a Screen Shot


When running full screen, capturing a screen shot can become a bit tricky.  I got around it by handling the logic in code.  If you are interested, here is how I captured a screenshot using Godot:

      if(event.scancode == KEY_SPACE):
         yield(get_tree(), "idle_frame")
         yield(get_tree(), "idle_frame")
         var screenshot = get_viewport().get_screen_capture()

The location of “user://” is going to change from platform to platform.  On Windows 8.1 the screenshot was located at C:\Users\Mike\AppData\Roaming\Godot\app_userdata\Viewport on my computer.  On Linux, check for a directory named .godot in your home directory.


The command queue_screen_capture() doesn’t happen immediately.  This is why we yeild two frames before calling get_screen_capture(), which will have the results of queue_screen_capture() or return an empty image if it hasn’t occurred yet.


The Video


9. July 2015


In this part we are going to explore using Particles in the Godot Engine.  Particles are generally sprites, either provided by you or generated programmatically, that are controlled by a unified system.  Think of a rain storm, each drop of rain would represent a particle, but the entire storm itself would be the particle system.  You would not control each drop individually, instead you would simply say “rain here” and the system takes care of the rest.  Particles are often used for special effects such as smoke, fire or sparks.  The Godot game engine makes working with particles quite simple.


There is an HD video version of this tutorial available here or embedded below.


This particular tutorial isn’t going to go into a great deal of detail over the effects of each setting, as there is already an excellent illustrated guide right here.  Instead I will focus on using particles in a hands example.  As I mentioned earlier, particle systems are often used to create fire effects, and that’s exactly what we are going to do here, create a flaming/smoking torch.


Creating a particle system is as simple as creating a Particles2D node:


Creating one will create a simple system for you:



As always, the properties are controlled in the Inspector.  In this case we are creating 32 particles with a lifespan of 2 seconds aimed down and affected by gravity:



Now let’s suit it to our needs.  First we want to change the direction of our particles to up instead of down. This is set by setting the direction property, this is a value in degrees for the particles to be emitted in.



Here is the result:


Next, since this is a torch, we don’t want the particles to be affected by gravity.  Under Params, simply set Gravity Strength to 0:


And the result:


Now white dots are exactly convincing flames… so lets add a bit of color.  This can be done using Color Phases.  These are the colors the a particle will go through during it’s lifetime.  For a torch, we will start with a brilliant white, then orange and finally red, like so:


Be sure to set the Count to 3.  You can have up to 4 phases if needed.  Now our results look like:


A bit better.  Now we want to work on the size a bit.  Let’s start our particles off bigger and shrink as they move away from the source of the flame.


Resulting in:



Finally we slow it down slightly and decrease the spread:



And voila:



A fairly passable torch.  You could play with it a bit, use an image instead of a square particle, change the alpha value of each color phase or add another overlapping particle system to provide smoke.  Keep in mind though, more particles, more processing.


Here is a simple layer of smoke added as a separate particle system and the alpha lowered on the final two color phases:



Particles are as much an art to create as a texture or 3D model.  Play around until you achieve the effect you want.  Be sure to read that link I post earlier for the effects various settings have on your particle system.  One other area I never touch on was randomization.  In addition to numerous settings for controlling how particles are created, you can also randomize each of those values so your particles end up being less consistent.


As mentioned earlier, a particle can also be created from a texture or series of textures.  To set a texture, simply set it’s texture property:



In this example I am going to use this spritesheet to create a flock of animated birds:



Set H and V to correspond to the number of rows and columns in your TextureAtlas:



I am unsure of how to deal with TextureAtlases with empty squares, there doesn’t seem to be a way to set a total count, but I may have overlooked it.  Next you are going to want to specify the speed you want it to jump between frames of animation using Anim Speed Scale


I tweaked a few more settings:


And my final results are a fairly nice flock of birds:



One other feature available is the particle attractor ParticleAttractor2D, which can be used to attract particles, to either fling them out the other side or absorb them.  Think of it like a black hole that either sucks in or spits out the particles in it’s radius of influence:



Keep in mind that particles all have a lifespan, and once that lifespan has elapsed, it will fade away.


Particles provide a powerful way of implementing tons of graphically similar effects ( like fire, fog, flocking etc ) with a single controlling system.  They are as much art as programming though, so will take some time playing around to get the effect just right.


The Video



18. June 2015


So I decided to take a look at the process of extending the Godot Engine, and to my horror I discovered there is no solution file!  UGH…  Yeah, you can compile from the command line, but that’s not that pleasant of a development experience to an IDE warrior like myself.  I thought I found a solution that I posted about here and I almost did, but it still left me unable to debug and with mostly broken Intellisense support… so, yeah, not great.  Then I found this post, which although it didn’t work, it did fill in the missing pieces.  So, if you want to work with Godot using Visual Studio, here’s how you do it.


First you need to have a properly configured development environment… meaning Visual Studio, git and python, all in your PATH.  Next launch a Visual Studio command line, this guy…



Make and change to the directory you want to install Godot.  Keep in mind this process will make a godot folder, so if you want c:\godot\ run the following from c:\.


git clone

This will download the latest source for Godot Engine.  Next we want to build it for the first time and generate a Visual Studio solution file.  cd into the Godot directory and run:

scons vsproj=yes platform=windows

If you get an error here, first be sure you are using a Visual Studio command prompt, next be certain you are in the correct directory.  Otherwise your computer should churn away for a few minutes while godot libraries and tools are built.

After several minutes, in an ideal world you should see:



This means Godot successfully built and it created your Visual Studio project files.  Woot.  Now time to get Visual Studio to actually work.


First in the root of your project directory ( C:\Godot\ in my case ), create a file named build.bat, with the following contents:

set vc_path=%1
call %vc_path% & scons platform=windows


Next load the generated sln file in Visual Studio.  Give it a minute or two to parse all the files.  You will notice massive amounts of Intellisense errors, don’t worry, we will fix those next.

In Solution Explorer, right click your Project ( not solution, Project! ) and select Properties.


Select VC++ Directories then double click Include Directories:


Append the following to the value in Include Directories:


This adds the include directories Godot depends on.


Next click NMake on the left hand side.  We now want to replace the contents of Build Command Line and Output to:


Then click Apply then OK.


You should now be able to hit Build->Build Solution.  If all went right, you should see build progress in the Output panel:



You can now run and debug as normal, set breakpoints within the code, hit F5 and Godot editor will run.  Keep in mind, it’s the Godot Editor you are debugging, not the library, although since you have full source you should easily be able to step into Godot core code, you just may not be able to set breakpoints there.


You are now ready to extend or contribute to Godot using the full power and comfort of Visual Studio.


The following is a video showing exactly this process, just in case I missed a step.



GFS On YouTube

See More Tutorials on!

Month List