Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Godot 4.0 preliminary changelog

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog.

[Unreleased] (4.0-dev at commit 8f838f33b)

Added

Editor

  • macOS: More built-in mouse cursors are now exposed (such as diagonal resize cursors).
  • macOS: Support for building Godot with Clang sanitizers.

Rendering

  • Vulkan renderer.

Changed

Core

  • Increased the maximum number of OpenSimplexNoise octaves (6 → 9).

Editor

  • Improved the Video RAM debugger usability.
    • The Video RAM tab is now refreshed automatically when switching to it.
  • CSV profiler measures can now be saved anywhere on the filesystem, not just in the project folder.
  • Times are now displayed as milliseconds in the profiler and performance monitors (instead of seconds).
  • Improved the batch rename dialog usability and design consistency.
    • Clarified error messages when there are regular expression errors.
  • Optimized editor icon generation to speed up editor startup.
  • The number of replaced results now appears in place of the matches counter when replacing text in the script editor.

Removed

Fixed

GUI

  • Fixed OptionButton minimum size.
  • TabContainer is no longer too large when tabs are hidden.
@glinesbdev

This comment has been minimized.

Copy link

glinesbdev commented Sep 8, 2018

So after 3.1 is released, computers with a 32 bit architecture will no longer be able to run Godot?

@suptoasty

This comment has been minimized.

Copy link

suptoasty commented Sep 9, 2018

@glinesbdev the way i read it is that only mac os will no longer have 32-bit and fat godot support. and this commit helps godotengine/godot@f04958c support that. Your question makes it sound like all 32-bit will be removed

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Sep 10, 2018

@glinesbdev 32-bit will continue to be supported on Windows and Linux, but Apple dropped 32-bit support from macOS several years ago (the last macOS version available as 32-bit was 10.7, which is EOL since November 2014).

@flamendless

This comment has been minimized.

Copy link

flamendless commented Nov 3, 2018

I am really waiting for the opengl 2.0 compatibility

@aaronfranke

This comment has been minimized.

Copy link

aaronfranke commented Nov 5, 2018

Don't forget about Typed GDScript (var x : int etc)

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Nov 5, 2018

@aaronfranke It's already mentioned 🙂

  • Optional static typing in GDScript.
    • Does not currently improve performance, but helps write more robust code.
@unsignedFoo

This comment has been minimized.

Copy link

unsignedFoo commented Nov 14, 2018

Really excited about those improvements. Excited to see OpenGL2.0 too. Any new about WebGL?

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Nov 14, 2018

Any new about WebGL?

The plan is to remove WebGL 2.0 support and re-add WebGL 1.0 based on the OpenGL ES 2.0 renderer, which is faster and more compatible.

@peterorme

This comment has been minimized.

Copy link

peterorme commented Dec 16, 2018

Are there any updates about targeting single-board computers like the Raspberry Pi in Godot 3.1?

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jan 2, 2019

@peterorme This will be possible again in 3.1 thanks to the OpenGL ES 2.0 renderer. You will still have to provide an export template for ARMv7 (which you can compile yourself), though. I can't make any guarantees about its performance on SBCs, but give it a try anyway 🙂

@motorsep

This comment has been minimized.

Copy link

motorsep commented Jan 3, 2019

Is there anything in this release for blazing fast PC VR and mobile VR (Oculus Rift/Oculus Go/Quest) ?

@Olm-e

This comment has been minimized.

Copy link

Olm-e commented Jan 3, 2019

@peterorme : it is already working : you can compile godot-master on Raspi3, I've done it and it works with 2D games at least ... ;)
(be sure to not compile Webm as it does crash the compilation, to have > 1Gb of pseudo-swap file, and be patient ;) )

@ZZKJInc

This comment has been minimized.

Copy link

ZZKJInc commented Jan 5, 2019

Still no terrain object. Even though the screenshot provided for 3.1 shows a terrain.

@Jummit

This comment has been minimized.

Copy link

Jummit commented Jan 6, 2019

@ZZKJInc 3d terrain is too high level and would add something most people would not use, which is against Godot's philosophy.
If you want a 3d terrain editor, use this plugin: https://github.com/Zylann/godot_terrain_plugin

@skarmiglione

This comment has been minimized.

Copy link

skarmiglione commented Jan 8, 2019

Hello! where can i see the status about c#?

@uldall

This comment has been minimized.

Copy link

uldall commented Jan 18, 2019

@vini-guerrero

This comment has been minimized.

Copy link

vini-guerrero commented Jan 18, 2019

Are there any tutorials on the websockets feature? I saw the documentation but couldn’t make it work properly yet...

@Olm-e

This comment has been minimized.

Copy link

Olm-e commented Jan 28, 2019

@motorsep : I read "Improved buffer writing performance on Windows and Linux." and could see great improvement in fps on previously crawling scenes, specifically with shadows, now getting 90fps where I had 15 ... :) (on linux and vive openvr)
so yes, some blazing VR is now more possible on PC (still pay attention to your project setup, disabling VSync, hiding 3d window when editing, etc... )

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Apr 7, 2019

I updated this changelog for the current state of 3.2-dev (up to godotengine/godot@3dabe86).

By the way, if you have Tig installed, you can use tig +10000 3.1-stable..master --no-merges to preview all commits that have been done since 3.1's release in a convenient way.

@Antokolos

This comment has been minimized.

Copy link

Antokolos commented Apr 8, 2019

I don't mean to be pressing and all that, but please take a note at this few issues:

  1. Shaders caching: without that feature we'll be experiencing freezes any time new material will appear in the camera
    godotengine/godot#13954
    "Ouch. I don't know why this isn't as high of a priority as literally (in the literal sense) anything else in 3.1. Having your game freeze every time a new object that hasn't been used yet enters the screen is an enormous deal-breaker for most people, and asking people to use hacky solutions that work sometimes is honestly pretty awful." (c)
  2. LOD is not working:
    godotengine/godot#8806
  3. 3D occluders. It is REALLY, REALLY important and MUST HAVE feature for any 3D engine.
    godotengine/godot#9786
    All this features are extremely important for 3D games' optimization. Gamers don't care if the game was created in Godot or in Unreal Engine, but gamers care a lot about 60 FPS. So, please, place all these features (with or without Vulkan, it is really not that important) on the top of the list for 3D in 3.2.
@samvila

This comment has been minimized.

Copy link

samvila commented Apr 10, 2019

How about this?: godotengine/godot#24086

@xcrdev

This comment has been minimized.

Copy link

xcrdev commented Jun 12, 2019

Are there plans to add audiostreamopus back in?

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jun 12, 2019

@xcrdev See godotengine/godot#19303. Someone needs to step up to do it 🙂

@girng

This comment has been minimized.

Copy link

girng commented Oct 6, 2019

My goodness, awesome!

Engine.get_physics_interpolation_fraction() to get the fraction through the current physics tick at the time of the current frame.
This can be used to implement fixed timestep interpolation.

Any examples of this? This sounds nice.

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Oct 6, 2019

@girng This is used in lawnjelly's smoothing add-on :)

@girng

This comment has been minimized.

Copy link

girng commented Oct 6, 2019

@Calinou nice. Thanks for the link. That's awesome LOL

edit: Wait, shouldn't this be what the core physics engine should do? Or am I missing something lol

@kone9

This comment has been minimized.

Copy link

kone9 commented Oct 6, 2019

Woo son muchas cosas nuevas

@Giakaama

This comment has been minimized.

Copy link

Giakaama commented Oct 8, 2019

Will NOTIFICATION_WM_QUIT_REQUEST will be available on Android ?

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Oct 8, 2019

@Giakaama According to Handling quit requests in the documentation, it should already be available on Android.

Note that pressing the Home button isn't considered to be a quit request, as the application will be merely suspended (instead of killed).

Edit: The MainLoop documentation states that NOTIFICATION_WM_QUIT_REQUEST is only implemented on desktop platforms, which means the documentation page contradicts it. I'll open a pull request to update it accordingly.

@follower

This comment has been minimized.

Copy link

follower commented Oct 9, 2019

Can I suggest a more positive & inclusive wording replace "...when working with artists to make it harder for them to mess things up" in this document?

Perhaps some variation of one of these:

  • "...when working with artists to help prevent inadvertent changes".
  • "...when working with artists to help prevent inadvertent code-related changes".
  • "...when working with artists to help prevent inadvertent non-art-related changes".
  • "...when working with artists to enable a friendlier workflow for them".
  • "...when working with artists to provide them a tool tailored to their needs".
  • "...when working with artists to provide them a tool tailored to their role".

Thanks.

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Oct 9, 2019

@follower I changed it to:

  • This is helpful for education, or when working with artists to help prevent inadvertent changes.
@follower

This comment has been minimized.

Copy link

follower commented Oct 9, 2019

@Calinou Thanks!

@jahd2602

This comment has been minimized.

Copy link

jahd2602 commented Oct 10, 2019

I don't know how to pull request a Gist but there is a typo:
NOIFICATION_APP_PAUSEDNOTIFICATION_APP_PAUSED

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Oct 10, 2019

@jahd2602 Thanks for reporting it. I fixed it 🙂

Even though any gist is a Git repository, there's no way to open pull requests for a gist.

@lancewrath

This comment has been minimized.

Copy link

lancewrath commented Oct 14, 2019

will there be a headless server for mono in 3.2?

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Oct 15, 2019

@lancewrath There are plans to distribute official headless Mono binaries. It should be possible to build them yourself already, see Compiling with Mono in the documentation (use platform=server).

@lancewrath

This comment has been minimized.

Copy link

lancewrath commented Oct 16, 2019

@Calinou Ah thanks i wasn't aware of the server option in the platform var.

I didn;t really see in the Change logs but will the [Export] functionality in C# support support Arrays, i think at the very least the Resource[] and NodePath[] class arrays are a big must IMO.

@Giakaama

This comment has been minimized.

Copy link

Giakaama commented Oct 26, 2019

@Giakaama According to Handling quit requests in the documentation, it should already be available on Android.

Note that pressing the Home button isn't considered to be a quit request, as the application will be merely suspended (instead of killed).

Edit: The MainLoop documentation states that NOTIFICATION_WM_QUIT_REQUEST is only implemented on desktop platforms, which means the documentation page contradicts it. I'll open a pull request to update it accordingly.

Regarding this, So when killing an app on android the NOTIFICATION_WM_QUIT_REQUEST should be called ? On 3.1 doesn't work .

@xpie23w

This comment has been minimized.

Copy link

xpie23w commented Oct 27, 2019

add Terrain Editor 3d!!

@kuroodo

This comment has been minimized.

Copy link

kuroodo commented Nov 6, 2019

Ability to convert a Sprite to a Mesh2D, Polygon2D, CollisionPolygon2D or LightOccluder2D.

Wasn't this added already in 3.1.1? I was definitely using it the other day on 3.1.1.
godotengine/godot#27553

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Nov 6, 2019

@kuroodo It was, but this changelog mentions all changes from Godot 3.1 to 3.2 (not 3.1.1 to 3.2). This is because some changes may only land in point releases, so a linear changelog wouldn't make sense for us.

@paxetgloria

This comment has been minimized.

Copy link

paxetgloria commented Dec 11, 2019

@ZZKJInc 3d terrain is too high level and would add something most people would not use, which is against Godot's philosophy.
If you want a 3d terrain editor, use this plugin: https://github.com/Zylann/godot_terrain_plugin
@Jummit, how can you possibly know that "most people would not use" it?

@Jummit

This comment has been minimized.

Copy link

Jummit commented Dec 11, 2019

I can say for sure that more than 50 percent of Godot users will not use 3D Terrain. This is because Godot is currently mostly used for 2D games. I don't get all the fuss about adding high level features to Godot; being able to add them as addons has no downsides.

Looking back on my old comment, I'll change my oppinion: Replacing the GridMap node with a Terrain node would be great.

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Dec 11, 2019

@Jummit GridMap serves a very different purpose from terrain, as it's more or less a 3D TileMap. Many popular games still use GridMap-like structures today 🙂

@Jummit

This comment has been minimized.

Copy link

Jummit commented Dec 11, 2019

Many popular games still use GridMap-like structures today slightly_smiling_face

Interesting, I didn't know that! I always thought it was a Godot only thing. Can you show some examples?

@lodu44

This comment has been minimized.

Copy link

lodu44 commented Dec 11, 2019

I think so little use 3d, it's precisely after that it does not allow optimization, with the level of distance that are missing and are cruelly lacking.

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Dec 11, 2019

@Jummit Games like Trackmania come to mind here. All official and user-made tracks are made by placing pre-made blocks on a 3D grid (with a system similar to autotiling to handle connections).

@lodu44 LOD and occlusion culling will be implemented in 4.0, as part of the new Vulkan renderer.

@smt923

This comment has been minimized.

Copy link

smt923 commented Dec 14, 2019

I can say for sure that more than 50 percent of Godot users will not use 3D Terrain. This is because Godot is currently mostly used for 2D games. I don't get all the fuss about adding high level features to Godot; being able to add them as addons has no downsides.

you're right about addons, but people probably aren't using Godot for 3D because it's lacking 3D features that other 3D engines have out of the box, it'd be a good idea to make these as easy to use as possible so more people might try Godot, see that it now has feature parity to other 3D engines and start using it for 3D, I've chosen Unity or UE4 over Godot for things purely because Godot doesn't match the terrain, ai and navmesh tools of the other engines

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Dec 19, 2019

@kuroodo Sorry for the late response, but the feature you mentioned was cherry-picked into 3.1.1. This means it's both available in 3.1.1 and the current 3.2 betas.

This particular changelog all tracks changes from 3.1 to 3.2, not just from the latest 3.1 patch release to 3.2.

@ShlomiRex

This comment has been minimized.

Copy link

ShlomiRex commented Jan 17, 2020

amazing! Keep up the good work!

@RichardR01

This comment has been minimized.

Copy link

RichardR01 commented Jan 19, 2020

Has there been any improvements, for 3D, in shadowing and a fix for the fire flies in reflective materials? Also we need FXAA antialiasing, IMO, as MXAA produces artifacts and does not do a good job at removing the jaggies. I get better results having it off.

Shadows produce artifacts depending on the orientation of the light and camera and look pretty bad in general. Also, in the material shaders, for SpatialMaterials, refraction does not work. It makes transparent objects opaque and the scale slider does nothing. (I assume because this is meant for a texture?) On that note, it should not be scale, but IOR for Index of Refraction.

I didn't want to come here to complain but I am finding it hard to get any information on how people deal with these issues, and I feel they need to be brought into the light. If there is no plans on fixing/supporting 3D for Godot, why not just make Godot strictly 2D? If I could help in the development of Godot, I would; but I am just a bad artist who blames his tools (for good reason), and am quite frustrated.

MSAA artifacts (bad aliasing)
https://i.imgur.com/BgQ8EnZ.jpg

Shadow artifacts
https://i.imgur.com/SP0O9sq.jpg

Bad shadowing
https://i.imgur.com/QGU36MG.jpg

Reflected firefly starburst
https://i.imgur.com/wA91Bzs.jpg

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jan 19, 2020

@RichardR01 There is a FXAA shader available here. It works with both the GLES3 and GLES2 renderers. As for the MSAA artifacts on the screenshot, this seems to be due to screen-space reflections; try disabling them.

Shadows produce artifacts depending on the orientation of the light and camera and look pretty bad in general.

Try disabling contact shadows. These are known to create artifacts and generally decrease performance.

Also, try playing around with the bias values in the light nodes. If your game is based around a camera that never moves or a camera that moves constantly at a high speed (e.g. a racing game), you can set the DirectionalLight depth range to Optimized instead of Stable. This will increase the effective shadow resolution, at the cost of stability when the camera moves.

As for the bad shadow filtering, try decreasing the directional shadow size in the Project Settings. There are known issues with the filtering when the size is set too high.

Finally, the firefly starbursts should be alleviated by increasing the radiance size in the Environment resource.

Also, in the material shaders, for SpatialMaterials, refraction does not work.

Does it work in the Material Testers demo (which is in this repository)? If not, it may be an issue with your graphics hardware. Otherwise, it's likely a configuration issue somewhere in the SpatialMaterial (check the one in the demo).

On that note, it should not be scale, but IOR for Index of Refraction.

We don't claim to be physically accurate, so I'm not sure if that's a good idea 🙂

If the scale doesn't match IOR, it may be possible to change this for 4.0, but we need to see whether it would incur a performance cost.

If there is no plans on fixing/supporting 3D for Godot, why not just make Godot strictly 2D?

We're not flawless, we're work-in-progress. 3D will be much improved in 4.0, but we already consider it to be usable for many projects in 3.x. Godot 3.2 will make it significantly better by improving the asset pipeline.

@ibsantos

This comment has been minimized.

Copy link

ibsantos commented Jan 21, 2020

Any plans to add support for opening encrypted and/or compressed arbitrary files (via File.open_encrypted, File.open_encrypted_with_pass, File.open_compressed)? Currently I think only resources exported by godot are accepted by those methods, otherwise an error = 15 (unrecognized) is returned. There are already some issues on this topic, like #32881 and #28999, for instance.

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jan 21, 2020

@ibsantos Someone needs to step up to implement this feature 🙂

@emo10001

This comment has been minimized.

Copy link

emo10001 commented Jan 22, 2020

So with the integration of Assimp, does this mean we'll be able to import .X models? It's a supported file type according to the Assimp site. Also, direct importing of blend files? Because that would be awesome!

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jan 22, 2020

@emo10001 I don't remember the exact list of model formats in Godot's implementation of Assimp. I was definitely able to import MDL, MD2, MD3 and MD5MESH formats at least. I guess it'd be nice to provide a testbed project so the support for various model formats can be checked easily.

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jan 22, 2020

On another note, this changelog is now merged into Godot 3.2 🎉

Stay tuned for the upcoming Godot 4.0 changelog!

@emo10001

This comment has been minimized.

Copy link

emo10001 commented Jan 27, 2020

@Calinou hey I was just thinking about the Assimp integration with it's focus on FBX. I certainly don't claim to know all the industry buzz, but hasn't there always been issues with FBX due to it being proprietary? Has the Godot team found a way around that? Or has then been some agreement or change to FBX that would allow it?

Thanks!

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jan 27, 2020

@emo10001 I believe Assimp's FBX support is the fruit of reverse engineering. It doesn't rely on Autodesk's proprietary SDK. In 3.2, we've had an Assimp contributor work on improving Assimp's integration with Godot (and Assimp's FBX support itself).

@eltharionx

This comment has been minimized.

Copy link

eltharionx commented Jan 28, 2020

@Calinou
No mention of this game breaking change with this update from v3.1.2stable to v3.2RC4:

v3.1.2stable
AStar
int get_closest_point ( Vector3 to_position ) const

v3.2RC4
AStar
int get_closest_point ( Vector3 to_position, bool include_disabled=false ) const

With the new default include_disabled=false, and the expected behavior to be defaulted to true... it breaks backward compatibility. Recommend highlighting as potential breaking change in ChangeLog.

@Calinou

This comment has been minimized.

Copy link
Owner Author

Calinou commented Jan 28, 2020

@eltharionx This shouldn't be a breaking change actually per godotengine/godot#32249.

@eltharionx

This comment has been minimized.

Copy link

eltharionx commented Jan 28, 2020

@Calinou Understood that there is a fix for this. I guess it's "breaking" in the sense that one may need to go back into their code and update all their get_closest_point( x ) to get_closest_point( x, true). Specifically, I needed to do this, and only was able to figure this out the long way since there was no mention in it here in this ChangeLog.

@akien-mga

This comment has been minimized.

Copy link

akien-mga commented Jan 28, 2020

@eltharionx Actually you're right, it's not godotengine/godot#32249 which is breaking, but the previous PR that prompted the need for this argument: godotengine/godot#30112.

This is probably fine with false as default value, but it does break compatibility and should be identified as such indeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.