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.
So far we have been a few months on Patreon and the net result has been overwhelmingly positive, as we get enough funds each month to hire our lead developer and an intern! Still, it's time to start thinking about our next hire to continue speeding up Godot's development as well as its visibility and relevance in the gamedev industry.
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.
Maybe you have already seen an AdPod around. They are three-sided giant multitouch capable screens. The company behind them customizes them for very important customers for promotion campaings for things like movies (Disney, Universal). They "skin" the device cosmetically for the targeted product and develop interactive apps that run on them. People walking by can interact with them, something which creates great product awareness and also entertains. Now they have decided to use Godot for such development work! The switch from the well-known non-free engine they were using formerly has been a wise decision.
Both testers and developers are doing a great job, but we need to go ever faster to get Godot 3.0 out as soon as possible - especially now that the master branch is in feature freeze, meaning that new features will have to wait for Godot 3.1 to be merged. We propose to have a special bug hunting day on Saturday, 9 December, to focus on fixing the bugs reported for the 3.0 milestone. Testers are also encouraged to use this opportunity to file new bug reports, after checking existing issues for potential duplicates.
We are all working hard on fixing the remaining issues for delivering a stable Godot 3.0 as soon as possible, but we definitely need a hand to speed up the work!
Godot keeps growing steadily in both users and contributors, and 3.0 will be our best release yet. As our community keeps expanding, the development process also reshapes to accommodate new contributions. While our process is completely transparent, it is not obvious for a large part of the community how new features, fixes and improvements are added. This short article will attempt to shed some light on it.
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.
Our campaign for the initial Patreon goal (hiring Juan full time) has been a huge success thanks to our community's support. Thanks to this, Juan is able to spend a lot more time working on Godot and helping other contributors. However, many areas remain where more dedicated developer time would be highly beneficial to advance the project faster.
Godot 3.0 is in it's final march towards a stable release, hopefully before year's end. The first Beta will be releases shortly and then candidates and stable... you can help and be a hero!
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!
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.
Godot has grown a lot and, nowadays, and new users expect us to have quality documentation comparable to commercial offerings. For this, the documentation system we currently have needs tweaks and improvements. As we, game engine developers, are not experienced in the web side of the programming world, everything seems daunting to us (please don't laugh), so any help with the following items would be hugely appreciated!