https://github.com/godotengine/godot
Here is an array of bug fixes/improvements that I have made to the Godot engine in the last two weeks.
This issue arose in our GLES2 (lower end) backend. When a user gave an object a negative scale, the object was rendered inside out.
The fix required doing two things. One was tracking whether the scale was negative or positive. Which is done here.
And the other was updating the culling code to accurately flip when needed. Which is done here.
A bonus is that now the culling state only changes when necessary. This should result in slightly improved rendering times especially on complex scenes.
The next bug came from the way that reflection maps were calculated from the environment map. For some reason, when using HDR environment maps, reflections on objects would look like fireworks were going off (see below).
It look a lot of searching and experimentation to realize that the issue was with the quality setting. The code for determining quality was accidentally using the mobile setting in place of the desktop setting. For many rendering features Godot defaults to a low-quality version for mobile unless you specify to force high-quality on mobile. In this case, unless you specified to force high-quality on mobile, you would get low-quality even on a desktop that had high-quality enabled.
With the improved quality I was able to reduce the default size of the reflection maps (increase rendering speed while decreasing memory usage), while maintaining improved visual quality.
In the GLES2 backend the environmental fog was affecting materials that were set to be "unshaded" including in-editor gizmos. "Unshaded" specifies that environment effects (and light) should not affect the object.
The issue here turned out to be that a compile-time define using #ifdef ... #endif was misplaced and was accidentally including fog code when it should not have.
This one is actually two bugs combined into one.
Bug 1 resulted in objects with a particular setting (no depth test) being drawn behind the background unless they were in front of another object.
The solution was to specify that objects drawn without depth testing be drawn after all other opaque objects are drawn (e.g. with the transparent objects). This way they would always be drawn over things like the sky (which is what you expect when you select "no depth test").
Bug 2 resulted from the sorting algorithm not correcting taking into account the user set priority of objects. Priority is used to specify the order in which transparent objects are drawn. The solution was just to sort by depth and priority instead of just by depth
MultiMeshInstance2D
PR: https://github.com/godotengine/godot/pull/29411
Related Issues: related bug, enhancement suggestion
The MultiMeshInstance2D takes advantage of hardware instancing to draw thousands of objects using one draw call. Instead of drawing each mesh one for every instance you can specify all instances in a large array and submit it to the GPU all at once. This significantly speeds up rendering by reducing the amount of CPU time spent on draw calls and reducing the amount of memory transfer between CPU and GPU.
The implementation required that I add a new node entirely that can be accessed when using the 2D renderer. The implementation is very similar to the way that the MultiMeshInstance works in 3D and the way MeshInstance2D works in 2D.
In order to get it to work I had to fix a couple related bug. One (linked to above), resulted when users compiled without 3D support but still used a MeshInstance2D. In order to fix this, I had to ensure that the Mesh class was included when compiling without 3D.
The second related bug was in the shader code. In the shader code there was a variable that did not get properly initialized under some compile conditions. It would have caused the shaders to crash when the program started.
#ifdef USE_INSTANCE_CUSTOM
attribute highp vec4 instance_custom_data;
#endif
...
// if USE_INSTANCE_CUSTOM is false, then the following line would cause the shader to crash
vec4 instance_custom = instance_custom_data;
// therefore, replace with the following as "instance_custom" still needs to be used
#ifdef USE_INSTANCE_CUSTOM
vec4 instance_custom = instance_custom_data;
#else
vec4 instance_custom = vec4(0.0);
#endif
The last bug was caused by colors for MultiMeshes not initialized in GLES2 leading objects to be rendered completely black. This was fixed by properly initializing the instance colors using a call to glVertexAttrib
glVertexAttrib4f(INSTANCE_ATTRIB_BASE + 3, 1.0, 1.0, 1.0, 1.0);