text:
Rigid bodies disconnect from joints frequently when exclude_nodes is on

Godot version:
3.2.4 beta 5
OS/device including version:
Ubuntu 20.04 LTS
Issue description:
As of this beta release, whenever a rigid body is moved, collision shapes are added/removed from it or collision shapes are moved within it (i.e. collision data changes in any way) - the body disconnects from any joints connected to it. The node paths in the joints do not change, but the node no longer has any effect on the physics simulation. In order to get this working again, at least one of the node paths (via set_node_a() or set_node_b()) must be set to @"." or some other irrelevant value, then set back so it's pointing to the correct body again.
I was using 3.2.4 beta 3 earlier, and that version of the engine had no problem with physics bodies or collision data being changed at runtime and would not disconnect any joints from doing so.
After doing some more investigating (and writing most of the above message), I thankfully discovered that the issue only occurs when the property exclude_nodes is set to true, so I do have a way of continuing my game in the meantime. The problem coincides exactly with the following warning message:
WARNING: remove_rigid_body: A body connected to joints was removed. Ensure bodies are disconnected from joints before removing them.    At: modules/bullet/space_bullet.cpp:505.
Steps to reproduce:

Set up a scene roughly similar to my minimal reproduction project:

One rigid body containing a mesh and a collision shape should be present
One joint (e.g. hinge) should have node_b set to this body and node_a blank
Before playing the scene, turning the joint exclude_nodes property ON should result in the behaviour I described when playing; turning it OFF should result in the normal expected behaviour

Play the scene and open the remote tree; try setting the transform of the collision shape to a different value, or changing the scale of the body, and see whether the body continues hanging or falls into the void (corresponds with the warning message detailed above).

Minimal reproduction project:
joint_disconnect_example.zip
Note - I've never posted an issue on GitHub before, so I'm uncertain about a few things such as what the title should be. Please correct me if I didn't do this right.

Can you reproduce this bug in 3.2.4 beta 4?

Can you reproduce this bug in 3.2.4 beta 4?

Thanks, just checked and it seems to work fine in beta 4 (based on the minimal reproduction project).

Thanks, just checked and it seems to work fine in beta 4 (based on the minimal reproduction project).

This is a regression from #43899.

This is a regression from #43899.

Thank you for your help! Hope this report was useful - again, I've never opened an issue before so wasn't sure how to go about it.

Thank you for your help! Hope this report was useful - again, I've never opened an issue before so wasn't sure how to go about it.

authors: Calinou Dominic-ATOR madmiraal


text:
Theme property "colors/font_color_selected" has no effect for TextEdit

Godot version:
3.2.3 stable
OS/device including version:
Windows 10
Issue description:
Theme property "colors/font_color_selected" has no effect for TextEdit, while it works fine for LineEdit.
Theme property setting

When not selected

When selected

Steps to reproduce:
Create an empty theme template, change "colors/font_color_selected" property for TextEdit, check the result in Theme Preview.
Minimal reproduction project:
Test.zip

This is caused by override_selected_font_color is false by default, so the check below fails.
https://github.com/godotengine/godot/blob/8a6d4dd5ed770f4dc464bbc6af912b96c63bbc2c/scene/gui/text_edit.cpp#L1261-L1263
@Paulb23 @bruvzg Not sure if you guys are the right ones to CC, but should this even be an option? If the user wants a custom selected font color, why do they need to set a color AND set this option to true for every TextEdit?

This is caused by override_selected_font_color is false by default, so the check below fails.
https://github.com/godotengine/godot/blob/8a6d4dd5ed770f4dc464bbc6af912b96c63bbc2c/scene/gui/text_edit.cpp#L1261-L1263
@Paulb23 @bruvzg Not sure if you guys are the right ones to CC, but should this even be an option? If the user wants a custom selected font color, why do they need to set a color AND set this option to true for every TextEdit?

Yeah this is intended, though an additional bug is the feature not being ported to LineEdit.
We could potentially get rid of the property for 4.0 as it's compatibility breaking by checking if font_color_selected == Color(0, 0, 0, 0) instead. This would however prevent reuse of that theme where the font colour should not be overridden. In addition Color(0, 0, 0, 0) would no longer be a valid value.

Yeah this is intended, though an additional bug is the feature not being ported to LineEdit.
We could potentially get rid of the property for 4.0 as it's compatibility breaking by checking if font_color_selected == Color(0, 0, 0, 0) instead. This would however prevent reuse of that theme where the font colour should not be overridden. In addition Color(0, 0, 0, 0) would no longer be a valid value.

source: gharchive/issue

authors: EricEzaM Paulb23 floppyhammer

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
C# Export: System.IO.FileNotFoundException; Missing System.Drawing

Godot version:
3.2.3.stable.mono.official
OS/device including version:
Windows 10
Issue description:
I'm trying to export a game that contains QR code scanning and generation capabilities using a C# library called ZXing.Net. However, when I try to load or save a QR code on the HTML export, the game hangs with this error in the console:

System.IO.FileNotFoundException: Could not load file or assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.

Steps to reproduce:

Create a Godot project, which contains a C# script that uses System.Drawing.
Export the project to HTML, and attempt to use that script.

Minimal reproduction project:
Test_Project.zip
Test_HTML5.zip

Hey,
System.Drawing is not compatible with Web assembly:

That's not an issue with Godot.

Oh, great. How can I deal with QR codes?

@neikeq Any idea where we should document this limitation?

These limitations seem to be described in the System.Drawing documentation: https://docs.microsoft.com/en-us/dotnet/api/system.drawing#remarks (and I hope this is turned into a compiler warning with .NET 6: https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1416).
I'm closing this since it's not a Godot issue.

How can I deal with QR codes?

I can't help much with that. I did a quick search where the last comment seems to have managed to make it work with ImageSharp: https://github.com/micjahn/ZXing.Net/issues/273#issuecomment-830017377
The relevant parts I found in his project were the package references to ImageSharp and ZXing.Net's ImageSharp bindings, and the image loading and QR decoding code:

https://github.com/sabitertan/BlazorWasmBarcodeScanZxingNet/blob/d8fce2f4bf60e6069229fa7a81ee6d4e1b2bdcc2/BlazorWasmBarcodeScanZxingNet/Client/BlazorWasmBarcodeScanZxingNet.Client.csproj#L10-L12
https://github.com/sabitertan/BlazorWasmBarcodeScanZxingNet/blob/d8fce2f4bf60e6069229fa7a81ee6d4e1b2bdcc2/BlazorWasmBarcodeScanZxingNet/Client/Pages/Index.razor#L125-L130

authors: Calinou JapanYoshi JupiterRider neikeq


text:
Editor freezes or crashes when loading a project due to GPUParticles3D

Godot version
Last reproduced with v4.0.dev.calinou.9b8095ad0
System information
Manjaro Linux w/ KDE. Tested on Ryzen/Radeon and Intel/Nvidia machines
Issue description
A project I am working on became impossible to load in Godot 4 Editor.
I am able to run the game itself just fine, but when attempting to open the game project in the editor, it either freezes or crashes.
Crashes happen with this output:
pure virtual method called
terminate called without an active exception
--Type <RET> for more, q to quit, c to continue without paging--
Thread 1 "godot" received signal SIGABRT, Aborted.
0x00007ffff7af2d22 in raise () from /usr/lib/libc.so.6

Freezes show this backtrace after I stop the process manually:
Thread 1 "godot" received signal SIGTSTP, Stopped (user).
std::atomic_flag::test_and_set (__m=std::memory_order_acquire, this=0xa0ce7e8) at /usr/include/c++/9/bits/atomic_base.h:195
195     /usr/include/c++/9/bits/atomic_base.h: No such file or directory.
(gdb) bt
#0  std::atomic_flag::test_and_set (__m=std::memory_order_acquire, this=0xa0ce7e8) at /usr/include/c++/9/bits/atomic_base.h:195
#1  SpinLock::lock (this=0xa0ce7e8) at ./core/os/spin_lock.h:43
#2  RID_Alloc<RendererStorageRD::Material, true>::owns (this=0xa0ce7b0, p_rid=...) at ./core/templates/rid_owner.h:223
#3  0x00000000052e253d in RID_Owner<RendererStorageRD::Material, true>::owns (this=0xa0ce7b0, p_rid=...) at ./core/templates/rid_owner.h:475
#4  0x00000000052d396a in RendererStorageRD::free (this=0xa0ce510, p_rid=...) at servers/rendering/renderer_rd/renderer_storage_rd.cpp:8674
#5  0x000000000520577a in RenderingServerDefault::_free (this=0xa07f790, p_rid=...) at servers/rendering/rendering_server_default.cpp:68
#6  0x0000000005248d6f in CommandQueueMT::Command1<RenderingServerDefault, void (RenderingServerDefault::*)(RID), RID>::call (this=0x7fff500d8f78) at ./core/templates/command_queue_mt.h:322
#7  0x00000000051207e1 in CommandQueueMT::_flush (this=0xa07f938) at ./core/templates/command_queue_mt.h:373
#8  0x000000000512086e in CommandQueueMT::flush_if_pending (this=0xa07f938) at ./core/templates/command_queue_mt.h:404
#9  0x000000000521ffa2 in RenderingServerDefault::free (this=0xa07f790, p_rid=...) at servers/rendering/rendering_server_default.h:910
#10 0x0000000004d42282 in GradientTexture::~GradientTexture (this=0x7fff500344c0, __in_chrg=<optimized out>) at scene/resources/texture.cpp:1517
#11 0x0000000002089b19 in memdelete<RefCounted> (p_class=0x7fff500344c0) at ./core/os/memory.h:115
#12 0x0000000005910a37 in Variant::_clear_internal (this=0x1ddac098) at core/variant/variant.cpp:1309
#13 0x0000000001ffded3 in Variant::clear (this=0x1ddac098) at ./core/variant/variant.h:257
#14 0x0000000001ffdef8 in Variant::~Variant (this=0x1ddac098, __in_chrg=<optimized out>) at ./core/variant/variant.h:672
#15 0x00000000022bb5de in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::Element::~Element (this=0x1ddac060, __in_chrg=<optimized out>) at ./core/templates/map.h:49
#16 0x00000000022bb61d in memdelete_allocator<Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::Element, DefaultAllocator> (p_class=0x1ddac060) at ./core/os/memory.h:127
#17 0x00000000022b5080 in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::_cleanup_tree (this=0xa51dce0, p_element=0x1ddac060) at ./core/templates/map.h:487
#18 0x00000000022b505d in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::_cleanup_tree (this=0xa51dce0, p_element=0x1ddcf050) at ./core/templates/map.h:485
#19 0x00000000022b5074 in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::_cleanup_tree (this=0xa51dce0, p_element=0x1ddb6d70) at ./core/templates/map.h:486
#20 0x00000000022b5074 in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::_cleanup_tree (this=0xa51dce0, p_element=0x1dde6060) at ./core/templates/map.h:486
#21 0x00000000022b5074 in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::_cleanup_tree (this=0xa51dce0, p_element=0x1dde3100) at ./core/templates/map.h:486
#22 0x00000000022b505d in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::_cleanup_tree (this=0xa51dce0, p_element=0x1dde0ef0) at ./core/templates/map.h:485
#23 0x00000000022ac37c in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::clear (this=0xa51dce0) at ./core/templates/map.h:647
#24 0x00000000022a465a in Map<StringName, Variant, Comparator<StringName>, DefaultAllocator>::~Map (this=0xa51dce0, __in_chrg=<optimized out>) at ./core/templates/map.h:664
#25 0x00000000052dbd1e in RendererStorageRD::Material::~Material (this=0xa51dcb0, __in_chrg=<optimized out>) at servers/rendering/renderer_rd/renderer_storage_rd.h:374
#26 0x00000000052f6565 in RID_Alloc<RendererStorageRD::Material, true>::free (this=0xa0ce7b0, p_rid=...) at ./core/templates/rid_owner.h:279
#27 0x00000000052e2563 in RID_Owner<RendererStorageRD::Material, true>::free (this=0xa0ce7b0, p_rid=...) at ./core/templates/rid_owner.h:479
--Type <RET> for more, q to quit, c to continue without paging--c
#28 0x00000000052d3a31 in RendererStorageRD::free (this=0xa0ce510, p_rid=...) at servers/rendering/renderer_rd/renderer_storage_rd.cpp:8682
#29 0x000000000520577a in RenderingServerDefault::_free (this=0xa07f790, p_rid=...) at servers/rendering/rendering_server_default.cpp:68
#30 0x0000000005248d6f in CommandQueueMT::Command1<RenderingServerDefault, void (RenderingServerDefault::*)(RID), RID>::call (this=0x7fff500d8f78) at ./core/templates/command_queue_mt.h:322
#31 0x00000000051207e1 in CommandQueueMT::_flush (this=0xa07f938) at ./core/templates/command_queue_mt.h:373
#32 0x000000000512086e in CommandQueueMT::flush_if_pending (this=0xa07f938) at ./core/templates/command_queue_mt.h:404
#33 0x000000000521da0a in RenderingServerDefault::canvas_item_clear (this=0xa07f790, p1=...) at servers/rendering/rendering_server_default.h:825
#34 0x00000000042b85eb in CanvasItem::_update_callback (this=0x1b0506f0) at scene/main/canvas_item.cpp:418
#35 0x00000000020a7547 in call_with_variant_args_helper<__UnexistingClass>(__UnexistingClass*, void (__UnexistingClass::*)(), Variant const**, Callable::CallError&, IndexSequence<>) (p_instance=0x1b0506f0, p_method=(void (__UnexistingClass::*)(__UnexistingClass * const)) 0x42b8572 <CanvasItem::_update_callback()>, p_args=0x7fffffffcbf0, r_error=...) at ./core/variant/binder_common.h:218
#36 0x00000000020a5ea0 in call_with_variant_args_dv<__UnexistingClass> (p_instance=0x1b0506f0, p_method=(void (__UnexistingClass::*)(__UnexistingClass * const)) 0x42b8572 <CanvasItem::_update_callback()>, p_args=0x0, p_argcount=0, r_error=..., default_values=...) at ./core/variant/binder_common.h:365
#37 0x00000000020a45f2 in MethodBindT<>::call(Object*, Variant const**, int, Callable::CallError&) (this=0xb790200, p_object=0x1b0506f0, p_args=0x0, p_arg_count=0, r_error=...) at ./core/object/method_bind.h:285
#38 0x0000000005b8f98a in Object::call (this=0x1b0506f0, p_method=..., p_args=0x0, p_argcount=0, r_error=...) at core/object/object.cpp:832
#39 0x00000000059085f9 in Callable::call (this=0x7ffff6bfb0e8, p_arguments=0x0, p_argcount=0, r_return_value=..., r_call_error=...) at core/variant/callable.cpp:62
#40 0x0000000005b888de in MessageQueue::_call_function (this=0x9908550, p_callable=..., p_args=0x7ffff6bfb100, p_argcount=0, p_show_error=false) at core/object/message_queue.cpp:258
#41 0x0000000005b88c1a in MessageQueue::flush (this=0x9908550) at core/object/message_queue.cpp:304
#42 0x000000000432f6d4 in SceneTree::physics_process (this=0xa1d6030, p_time=0.0166666675) at scene/main/scene_tree.cpp:415
#43 0x000000000203f407 in Main::iteration () at main/main.cpp:2515
#44 0x0000000001ffff1a in OS_LinuxBSD::run (this=0x7fffffffd1f0) at platform/linuxbsd/os_linuxbsd.cpp:278
#45 0x0000000001ffcf34 in main (argc=4, argv=0x7fffffffd6f8) at platform/linuxbsd/godot_linuxbsd.cpp:58

In rare cases the game loads fine, so the same action may have 3 different results, seemingly at random.
I have tested this issue in many version of Godot 4, and was not able to find a version that consistently loads the project yet.
At first I though a specific texture file was responsible for this, but then it turned out it makes no real difference.
This is a real showstopper. Me and a small team are completely stuck because of this.
So if there's anything I can do to help fixing this issue - please let me know.
I've bisected my source tree and found that https://github.com/unfa/liblast/commit/7de4dfb580d5bb9ed6fad125313396eb5c226c6b is the first bad commit.
I am trying to understand what in that commit has made this game project freeze or crash Godot.
Can anyone reproduce this?
Steps to reproduce

Follow instructions to clone and install this game project: https://github.com/unfa/liblast
Load the project in Godot 4.0 Editor
Observe as Godot Editor crashes or freezes
Switch to this commit: 65fed80abc57a06c00322b2195430dd801209234
Try loading the project in Godot Editor again
Observe as the project loads fine

Minimal reproduction project
No response

Based on https://github.com/unfa/liblast/commit/7de4dfb580d5bb9ed6fad125313396eb5c226c6b#r52886238 it seems the culprit is CPUParticles?

@Zirael07: I think it's GPU Particles. I did not use CPU Particles anywhere.

Duplicate of #49895

authors: Zireael07 qarmin unfa


text:
BakedLightmap atlas size not respected

Godot version
3.4.beta.3 mono
System information
Windows 10
Issue description
BakedLightmap node is not respecting the atlas size as you can see:

Also i remenber in the older version there was an error message that tells you that the size of the uv's were too big, in thet version i haven't see that error anymore.
Steps to reproduce
Bake a scene with 3d models imported with low lightmap texel size (for example 0.01) and light baking as "Gen Lightmaps". Then bake
Minimal reproduction project
No response

The Atlas Max Size likely defines the smaller dimension only. Alternatively, it means that individual layers are being clamped in size, not all layers as a whole.

Yes, Atlas Max Size refers to the individual layers, which are then stacked on top of each other to create a single image.
Right now there isn't any way to limit the total height of the atlas, so if you want to keep images below 2048 in both dimensions you will need to disable atlassing.
We could implement multi-image atlases, so instead of a single image for all layers, multiple images are used, but I don't really have the time right now. If anyone is interested, I'll be happy to give guidance on what needs to be changed.

We could implement multi-image atlases, so instead of a single image for all layers, multiple images are used, but I don't really have the time right now. If anyone is interested, I'll be happy to give guidance on what needs to be changed.

For reference, support for multiple atlas in BakedLightmap is being tracked in https://github.com/godotengine/godot-proposals/issues/2147.

Yes, Atlas Max Size refers to the individual layers, which are then stacked on top of each other to create a single image.
Right now there isn't any way to limit the total height of the atlas, so if you want to keep images below 2048 in both dimensions you will need to disable atlassing.
We could implement multi-image atlases, so instead of a single image for all layers, multiple images are used, but I don't really have the time right now. If anyone is interested, I'll be happy to give guidance on what needs to be changed.

I don't understand why multi-image atlases is left behind in a backlog, this is so critically important  for proper lightmapping setup with performance in mind.
Any relatively large interior static scene will greatly benefit from baked lightmaps that nicely packed in pow2 textures with fixed size, not in one huge atlas and not in thousands small textures, this is just ridiculous.
And no GIProbe is not an option for interior scenes with small details due to the poor quality, noticeable light leakage and unnecessary performance impact.
What should be done to implement multi-image atlases? Instead of stacking on top of each other to create a single atlas we need to constrain each atlas to fixed width and height, and constantly check whether we fill one out completly? This just screams for an efficient UV packing algorithm...

@KoxaKoxama There are many things that need our attention and we have to set priorities one way or another, we can't please everyone. Whether you think this is ridiculous or not doesn't really matter, so you can skip that part in future posts on Godot's issue tracker.
That said, I did look into this issue a while back, and I made some progress. The only thing preventing larger lightmaps is the fact that the Image resource has a maximum size.
As a quick fix I tried saving a TextureArray resource directly, but it appears that the saving code for this resource type was never implemented, only the loader was. Implementing this saver would take quite some time and testing, and the solution would not be ideal anyway, so I left it there.
There are two options moving forward:

Implement the saver for TextureArray.
This is my work-in-progress changes: diff.txt in case someone wants to continue working on it. But as I said, the solution is not ideal since images won't be compressed.

Instead of saving a single image or a single texture array, add support for saving multiple images.
Since the CPU lightmapper already generates a list of images, saving them separately should be easy, but this needs some changes in LightmapperCPU in order to keep track of which meshes ended un in which image. It's not a complicated process, but it takes some time and some careful testing to make sure everything keeps working as expected. I can provide more specific details if anyone is interested.

@JFonS  There is no need for an implementation of TextureArray saver.
Support for saving multiple images/atlases from lightmapper is exactly what I was wondering about, currently there is two extreme options how baked lightmaps are stored, it's either thousands of small textures or one unreasonably huge texture, both of which is harmful for performance, especially a very big non power of two atlas.
When texture atlas size is specified, lightmapper needs to keep texture size as pow2 and try to fill it with as much UV's as it can, and then create another texture and fill it with rest, repeat untill all mesh is done. A perfect middle ground.

As I mentioned, the TextrueArray approach was an attempt to get a quick fix. As I also mentioned, saving multiple images is possible, but requires a bit more work. After taking another look, I see the lightmapper already keeps track of the correspondence between meshes and images, so it's just a matter of correctly saving and loading the images. I will give it a go one of these days, when I have some spare time.
Note: the master branch has an image size limit of 2^24 (16.7M) instead of 2^14 (16.3k), so for 4.0 this is much less relevant.

Fixed by #58102.

Fixed by #58102.

Not fixed at all. Same error as before Failed determining lightmap size. Maximum lightmap size too small?

authors: Calinou JFonS KoxaKoxama akien-mga gdlq grevius5


text:
Soft-body with plane when the camera start bellow the plane even when the soft body passes in front of the camera

Godot version
v4.0.dev.custom_build [88b347dc2]
System information
Ubuntu 21.04. RTX 2060
Issue description
This issue is very strange but like the title says. If the softbody plane mesh start above the camera, it is complete invisible even if the soft body is in direction with the camera view.
Steps to reproduce
Use the InvisibleCloth.tscn scene from the Minimal reproduction project
Minimal reproduction project
Godot 4.0 SoftBody.zip

This happens because the visibility AABB isn't automatically adjust to account for the displayed vertices. I'm not sure if it's possible to do this in a cheap way.
In the meantime, increase Extra Cull Margin on the mesh.

Good to know that. Since this is not related to soft bodies then the issue can be closed or rename to explain the cause

This happens because the visibility AABB isn't automatically adjust to account for the displayed vertices. I'm not sure if it's possible to do this in a cheap way.

Soft bodies are supposed to update their AABB after calculating the new vertex positions, but there's probably a bug either in godot physics or in the vulkan renderer.
https://github.com/godotengine/godot/blob/30cf49e8d0325759b36af698f0c08d95629d1e09/scene/3d/soft_dynamic_body_3d.cpp#L90
@jcostello Do you know if it happens also in 3.x or just in 4.0?

@pouleyKetchoupp 4.0

Can confirm using the originally linked project in Godot 4.0 alpha 1.

Still occurs in Godot 4.0 alpha 4 with the originally linked project.
Workaround: Move the SoftBody so that it is in view of the Camera or increase Extra Cull Margin.

authors: Calinou James103 jcostello pouleyKetchoupp