GLES2 and GDNative, progress report #4
Latest update on the GLES2 and GDNative developments. This month, a lot of time has been spend on refactoring the way materials work together with shaders, but also the C++ bindings got some nice new make-up!
Latest update on the GLES2 and GDNative developments. This month, a lot of time has been spend on refactoring the way materials work together with shaders, but also the C++ bindings got some nice new make-up!
Another month, another progress report! This time with the early beginnings of 3D rendering in GLES2 and some GDNative ecosystem updates.
Godot VR support is slowly improving. The OpenVR drivers are now supplied through the asset library and we have the first version of our Oculus drivers available!
Because of the big release there have been many GDNative related tasks that needed to be addressed. Apart from that, the month was mostly spent on implementing more 2D items in the renderer as well as working on getting custom shaders running.
Thanks to our very supporting patrons I have the opportunity to work part-time on Godot! My work will be mostly about implementing an OpenGL ES 2.0 compatible rendering backend for Godot 3.1, as well as maintaining the GDNative system and bindings. The first month I spent on getting started and familiar with the rendering in Godot.
GDNative changed a lot since it was first introduced. From being a scripting-centered module it quickly became a more general purpose tool than we initially assumed. Here we present the way GDNative and related technologies work together.
A considerable number of users requested a more efficient way to have GI (Global Illumination) in their projects. Godot 3.0 currenty offers the GIProbe node, which provides a real-time approximation to GI. This generally works and looks pretty, but it's quite shader intensive, which makes it not work on mobile or low end GPUs. The newly added VR support also suffers with GIProbe, as it has to render in very high resolutions.
Right on time before Beta Freeze, our superstar contributor Pedro Estebanez completed Onion Skinning support! This implementation is really good, and allows visualizing future and past frames. This helps animators have a much greater deal of control on repositioning objects on every frame.
The past year we've been hard at work behind the scenes adding support for AR and VR to Godot. Support for basic mobile VR and full support for OpenVR is ready for Alpha 2. OpenHMD support is being worked on and we have a working ARKit implementation.
When Godot started (a decade ago), there were not many good physics engine available and Godot always had quite demanding API requirements for them (such as Area nodes, KinematicBody, RayCast shapes, etc.), so they were not usable without a lot of modification. This led us to implementing our own custom engine. Now, thanks to the work of Andrea Catania, we are introducing Bullet as a new and better maintained backend for the 3D physics!
The next alpha release of Godot 3.0 is about to be published and it will be the first version that ships with C# support. This post gives an introduction to C# scripting in Godot and how to use it in your project.
Godot uses a considerably different approach to rendering (and rendering abstraction) than other, popular, game engines. The motivation behind it was not to achieve the maximum performance in extreme use cases, but accomodate better to most user's needs.
The Godot Engine contributors were not idle during Juan's long holidays - lots of interesting features were implemented over the last two months, and they all converge towards making Godot 3.0 an impressive release! This progress reports covers the work done by all contributors apart from Juan, who will showcase his recent renderer improvements in the next progress report.
Another month of work, another progress report. This month work was divided into completing the exporters, GDNative (formerly DLScript) and the new particle system.
A short introduction to the new GDNative module (formerly DLScript) and how to use it in a project. This is a very early version, but the overall process will stay the same.
February was spent mostly rewriting the import and export workflow of Godot, so not many pretty visual features were added. At the end of the month, I also went to San Francisco for GDC.
Most of the internal code in Godot was written over a decade ago, and many design decisions that were taken back then, did not stand the test of time. January was spent mostly updating Godot internals and breaking compatibility, now that we have the chance.
It's been a month since the second progress report, and progress continues towards the new Godot renderer. This milestone was (and will likely be) the most difficult, due to the techniques that had to be implemented.
It's been a month since the first [progress report](https://godotengine.org/article/godots-new-renderer-progress-report-1), and progress continues towards the new Godot renderer. Little by little every system falls into place, and rendering starts feeling a lot more mature.
We decided to skip the planned 2.2 release to work at full steam on the upcoming Godot 3.0 and its new OpenGL ES 3.0 / OpenGL 3.3 renderer. We aim for a Godot 3.0 release in the first quarter of 2017, and it should bring an incredible load of features and improvements. Juan Linietsky will also be working full-time on Godot for the coming months thanks to the Mozilla MOSS award that we received earlier this year.
As many of you have probably heard, a new rendering backend is being worked on for Godot. One of the most common comments when evaluating godot by potential users is that, for 2D, Godot is awesome but for 3D it's pretty far from the mainstream alternatives. For Godot 3.0 (our new release being worked on) we are working hard to change this.
For most game developers, shaders are this scary monster that presents itself with such a complexity that seems out of reach. In reality, shaders are quite simple by default and just get more complex the more you add to them.
If you ever lurked in Godot source code, and tried to follow the flow of the logic, you most likely noticed that most code related to scene, formats, etc. always ends up in a giant "server" class. These really large classes, which Godot calls "severs", generally abstract some implementation or architecture.
Godot has many built-in types. Built-in types are used for non-pointer API arguments, where you need to pass around information fast and you don't really care much about keeping a reference. One of the early built-in types in Godot is Image, which is like a Vector, but with a little more information related to image data (such as width, height, format and whether or not it has mipmaps).