godot: Creating or loading GPUParticles nodes crashes engine on macOS with Compatibility GLES3 renderer (Apple Silicon)

What you can do in the meantime is add a macos override to the Rendering Method project setting as follows, before adding any GPUParticles to the project:

After clicking Add, set the override’s value to forward_plus or mobile. The project will look different than with the Compatibility rendering method (especially in 3D), but GPUParticles should work.

If you’re importing an existing project that has GPUParticles in its main scene, edit project.godot with a text editor before opening the project in the editor to add the override by adding this at the bottom of the file:

[rendering]

renderer/rendering_method.macos="forward_plus"

If there’s already a [rendering] section in project.godot, add renderer/rendering_method.macos="forward_plus" at the end of that section instead.

With Apple’s apparent new interest in gaming, do you think it would be worth submitting feedback to Apple dev support or another contact method for the issues that are clearly caused by a poor Apple implementation?

Unfortunately Apple has been quite clear that they have no intention of supporting OpenGL/WebGL.

Apple’s interest in gaming only extends to gaming on devices that support Metal (and soon WebGPU for web gaming). The future for Apple devices appears like it is going to be Metal/WebGPU only.

Unfortunately, that means it is on us to find workarounds because we are the ones who care about supporting multi-platform and low-end devices.

Just an update on this issue. It’s something that we are looking into, but it looks like there will be no easy solution.

GPUParticles work fine on intel macs. On Apple silicon macs, they cause this crash (likely because Apple silicon devices don’t have OpenGL drivers, they instead of a layer that implements OpenGL over Metal and apparently that layer is missing support for transform feedback).

The typical solution would be to use ANGLE to translate OpenGL to Metal so we don’t have to rely on Apple’s broken automatic translation. Unfortunately, the ANGLE over Metal variant has significant performance problems and leaks memory rapidly making it unusable. The ANGLE over OpenGL variant works much better, but doesn’t solve this crash.

Our best option is to workaround the performance issues and leaks. We already have identified a workaround for the leak, but it requires significant changes and we aren’t sure why they are necessary (https://github.com/godotengine/godot-angle-static/pull/3). We need to investigate how to workaround the performance issues still.

Needless to say the Apple ecosystem is not friendly to devs who want to support multi-platform and/or older devices. 😦

I just confirmed. This bug is fixed in dev6/master. Reverting https://github.com/godotengine/godot/pull/88816 re-introduces the crash.

So I can happily report that this issue is fixed by https://github.com/godotengine/godot/pull/88816 😃

Still happening on 4.1.3 on MacOS Sonoma 14.1. Crash immediately when adding or editing GPUParticles node in compatibility mode. However it works normally on 4.2 beta 4.

I wonder if this PR https://github.com/godotengine/godot/pull/88816 is responsible. It aimed at resolving a crash for super low end android devices. But seeing as this was an odd driver bug anyway, its possible that they shared a common root

just stumbled upon this and it is fixed in 4.3.dev6

Adding a GPU particles node also crashes Godot 4.2.1-stable with Driver.macos set to “opengl3_angle” on M1 macOS 14.2.1 (minor version increase from prev commenter).

https://gist.github.com/danneu/8cbe6c9f399f37dbbf4d5742e70cf0e5

Still happening on 4.1.1 on MacOS Ventura 13.5.2 😦.

It might be worth checking if ANGLE fixes this issue: https://github.com/godotengine/godot/pull/72831

relevant traceback (copy-pasted from #77681 )

handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.1.dev.custom_build (d9cf3695033a71902010239a27b7a264db7840cc)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] 1   libsystem_platform.dylib            0x00000001979daa24 _sigtramp + 56
[2] 2   libGLProgrammability.dylib          0x00000001fc63e27c glpLLVMCGSwitchStatement + 176
[3] 3   libGLProgrammability.dylib          0x00000001fc634ad8 glpLLVMCGNode + 588
[4] 4   libGLProgrammability.dylib          0x00000001fc63de60 glpLLVMCGBlock + 444
[5] 5   libGLProgrammability.dylib          0x00000001fc634aa8 glpLLVMCGNode + 540
[6] 6   libGLProgrammability.dylib          0x00000001fc63de60 glpLLVMCGBlock + 444
[7] 7   libGLProgrammability.dylib          0x00000001fc634aa8 glpLLVMCGNode + 540
[8] 8   libGLProgrammability.dylib          0x00000001fc650a9c glpLLVMCGIfStatementShortCircuit + 208
[9] 9   libGLProgrammability.dylib          0x00000001fc634ab8 glpLLVMCGNode + 556
[10] 10  libGLProgrammability.dylib          0x00000001fc63de60 glpLLVMCGBlock + 444
[11] 11  libGLProgrammability.dylib          0x00000001fc634aa8 glpLLVMCGNode + 540
[12] 12  libGLProgrammability.dylib          0x00000001fc63da68 glpLLVMCGFunctionDefinition + 2664
[13] 13  libGLProgrammability.dylib          0x00000001fc633744 glpLLVMCGTopLevel + 1480
[14] 14  libGLProgrammability.dylib          0x00000001fc65b20c glpLinkProgram + 10004
[15] 15  libGLProgrammability.dylib          0x00000001fc675140 ShLink + 208
[16] 16  GLEngine                            0x00000001fc829ac8 gleLinkProgram + 1228
[17] 17  GLEngine                            0x00000001fc797bcc glLinkProgramARB_Exec + 256
[18] ShaderGLES3::_compile_specialization(ShaderGLES3::Version::Specialization&, unsigned int, ShaderGLES3::Version*, unsigned long long) (in godot.macos.editor.dev.arm64) (shader_gles3.cpp:0)
[19] ShaderGLES3::_initialize_version(ShaderGLES3::Version*) (in godot.macos.editor.dev.arm64) (shader_gles3.cpp:678)
[20] ShaderGLES3::_version_bind_shader(RID, int, unsigned long long) (in godot.macos.editor.dev.arm64) (shader_gles3.h:204)
[21] ParticlesCopyShaderGLES3::version_bind_shader(RID, ParticlesCopyShaderGLES3::ShaderVariant, unsigned long long) (in godot.macos.editor.dev.arm64) (particles_copy.glsl.gen.h:29)
[22] GLES3::ParticlesStorage::_particles_update_instance_buffer(GLES3::ParticlesStorage::Particles*, Vector3 const&, Vector3 const&) (in godot.macos.editor.dev.arm64) (particles_storage.cpp:892)
[23] GLES3::ParticlesStorage::update_particles() (in godot.macos.editor.dev.arm64) (particles_storage.cpp:1102)
[24] RenderingServerDefault::_draw(bool, double) (in godot.macos.editor.dev.arm64) (rendering_server_default.cpp:87)
[25] RenderingServerDefault::draw(bool, double) (in godot.macos.editor.dev.arm64) (rendering_server_default.cpp:397)
[26] Main::iteration() (in godot.macos.editor.dev.arm64) (main.cpp:3405)
[27] OS_MacOS::run() (in godot.macos.editor.dev.arm64) (os_macos.mm:718)
[28] main (in godot.macos.editor.dev.arm64) (godot_main_macos.mm:77)
[29] 29  dyld                                0x0000000197653f28 start + 2236
-- END OF BACKTRACE --
================================================================

Is there any short-term resolution to unblock our team?

You can convert GPUParticles3D nodes to CPUParticles3D by selecting a GPUParticles3D node then using the GPUParticles3D menu at the top of the 3D editor viewport. This has some limitations though (no support for custom particle shaders, attractors, collision or turbulence).

This could be done at runtime automatically, but it would also break visuals in a lot of projects (to the point hiding particles entirely may be preferable in some scenarios).

It might be worth checking if ANGLE fixes this issue: #72831

For future reference, ANGLE does fix this issue but it’s no longer the default in 4.2.1 following #85785. (It was the default in 4.2 only.)

You can opt into using ANGLE in the Project Settings (Rendering Driver.macos). This may impact performance negatively though.

I tried doing that but it still crashes the engine. (on 4.2.1_stable and 4.3_dev - master branch)

+ I don’t know if it would help, but here’s the error report from macOS error reporter.

It might be worth checking if ANGLE fixes this issue: #72831

For future reference, ANGLE does fix this issue but it’s no longer the default in 4.2.1 following https://github.com/godotengine/godot/pull/85785. (It was the default in 4.2 only.)

You can opt into using ANGLE in the Project Settings (Rendering Driver.macos). This may impact performance negatively though.

I suggest we use a similar workaround as proposed in https://github.com/godotengine/godot/issues/54052, where we convert GPUParticles nodes to CPUParticles at load-time on macOS. This will break many particle effects, but it’s better than crashing the engine or not having any particles show up.

In the editor, GPUParticles rendering will likely need to be disabled on macOS so you can still edit their properties (without affecting the saved scene file).