Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPUParticles2D with collision not colliding with Occlusion layer of MapTileLayer #92052

Closed
4X3L82 opened this issue May 17, 2024 · 2 comments · Fixed by #92173
Closed

GPUParticles2D with collision not colliding with Occlusion layer of MapTileLayer #92052

4X3L82 opened this issue May 17, 2024 · 2 comments · Fixed by #92173

Comments

@4X3L82
Copy link

4X3L82 commented May 17, 2024

Tested versions

  • Reproducible in 4.3.dev6
  • Not reproducible in 4.3.dev5

System information

Godot v4.3.dev6 - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Wed May 8 17:46:43 UTC 2024 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 Laptop GPU () - AMD Ryzen 9 5900HX with Radeon Graphics (16 Threads)

Issue description

The new TileMapLayer (4.3.dev6) seems to break the Occlusion Layer: GPUParticles2D with collisions enabled go right through it.

Here is a TileMap + GPUparticles2D right above it in version 4.3.dev5:
4 3-dev5
You can see there are no particles underneath the tiles.

Here is a TileMapLayer + GPUparticles2D right above it in version 4.3.dev6:
4 3-dev6
You can see that a particle is underneath the tiles (thus ignoring the collision/occlusion).

And yes, in both cases they have a fully set Occlusion Layer (layer added, polygons set, etc.).

There's issue 91907, but I'm not a 100% sure if it's the same bug. That issue is talking about shaders & occlusion layers and texture_sdf. It could be the same underlying issue ("Occlusion layer is broken with TileMapLayer"), but it could be something else too.

Steps to reproduce

Create a TileMap / TileMapLayer, add a TileSet and configure it to have an Occlusion Layer.
Add some Tiles to the TileSet and configure them to have a shape on the Occlusion Layer.

Place some tiles in the Viewport.

Create an GPUParticles2D, and enable Collisions (either "Rigid" or "Hide on Contact").

Place the GPUParticles2D above the tiles (you can keep the default particles, so that it's "raining"):

  • In the TileMap/dev5 version: The particles bounce/hide
  • In the TileMapLayer/dev6 version: The particles ignore the TileMapLayer/Occlusion Layer (they fall through)

Minimal reproduction project (MRP)

dev5&6.zip

The zip file has 2 directories, one with "TileMap" (v5) and one with "TileMapLayer" (v6).
Due to the change of TileMap into TileMapLayer (from dev5 to dev6), there are 2 separate projects in this zip file.

@cosparks
Copy link
Contributor

Light occluder instances with sdf_collision enabled are drawn to a signed distance field texture. This texture is what the engine uses to detect collisions between GPUParticles2D particles and light occluders (it's passed to the particle process shader particles.glsl for 2d particles), so if an occluder isn't being drawn to it, then particles won't be able to collide with it.

It is very likely that this is the same bug as that other issue.

@cosparks
Copy link
Contributor

cosparks commented May 20, 2024

It looks like my fix for enabling / disabling sdf collision on LightOccluder2D instances might be the culprit here actually:
#90883

Before that fix went in, by default, all light occluders were being drawn to the sdf texture and the engine was just ignoring the LightOccluderInstance::sdf_collision flag. The current behaviour should be that if you want gpu particle collisions, you have to enable SDF Collision under your TileMapLayer's occlusion layers:

That said, even with SDF collision enabled in the editor, the occlusion layer in your project still isn't being drawn to the sdf texture so particle collisions still aren't working.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants