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

Mismatch between AABB and mesh when mesh and skeleton don't have the same transform #74656

Closed
SlugFiller opened this issue Mar 9, 2023 · 5 comments · Fixed by #84451
Closed

Comments

@SlugFiller
Copy link
Contributor

Godot version

Master (9b9bb41)

System information

Irrelevant

Issue description

Somewhat of a sequel to #71953. Sorry in advance for doing this report half-energy. I'm not sure if it counts as a bug, or is simply "You're not supposed to do that", i.e. undefined behavior.

Basically, if a mesh and a skeleton have mismatching transforms, in rendering, the mesh seems to attach to the skeleton based on the global position. For instance, if a skeleton's bone has rotation, and the mesh is moved in the direction that the bone's rest pose points at, the skeleton-transformed mesh would move in the direction that the bone's current pose points at. Basically, as if each of the mesh's vertices was moved.

Meanwhile, the AABB calculation seems to assume that the mesh and skeleton have the same transformation. That is, it attaches to the skeleton based on the positions of the vertices within the mesh, and not based on the global positions.

I've confirmed this in 2D, but it's likely present in 3D as well, since they use common code. At least for AABB.

Steps to reproduce

  1. Have a mesh (MeshInstance2D, MeshInstance3D, Polygon2D) with a skeleton (Skeleton2D, Skeleton3D) attached.
  2. Move the skeleton to a non-rest pose
  3. Move the the mesh's origin to being away from the skeleton.
  4. Do some action that relies on AABB. e.g occlusion culling, canvas group, etc.

Minimal reproduction project

Left as an exercise to the reader. I'm not even sure if this is unintended behavior, since skeleton and mesh with different transforms doesn't sound like something a user is normally supposed to do.

For the 2D case, it's possible to just take the project from #71953 and use the move tool to move the polygon.

@clayjohn
Copy link
Member

clayjohn commented Mar 9, 2023

I think images and/or an MRP are necessary here. Its not clear what the buggy behaviour is or if you are just misusing the skeleton.

@SlugFiller
Copy link
Contributor Author

Too lazy to MRP, have an image:
image

The Polygon2D inside CanvasGroup2 is translated 800px along the x axis. The associated bone gives a rotation of 45 degrees. These numbers are arbitrary, obviously. The skeleton is at 0,0. The drawing interprets it as the polygon first being moved, then rotated by the bone. The AABB calculation interprets it as being first rotated by the bone, then moved.

Incidentally, when moving the polygon, the rendering originally matches the AABB. Only when resizing the window, it suddenly "remembers" that it is wrong, and draws it in a way that doesn't match the AABB.

Here's an example of it looking correct:
image
Resizing the window causes it to jump to incorrect position shown above.

This is why I'm not sure whether the bug is in the AABB, or the skeleton shader.

or if you are just misusing the skeleton

It's fairly likely I'm misusing the skeleton.

@Zoomulator
Copy link

Zoomulator commented Mar 18, 2023

I seem to have the same problem. Tested with 4.0.1-rc2 that includes the recent #71953 fix, but it didn't fix it for me.
popping_polygons

My Polygon2D nodes are in fact translated differently to the Skeleton2D, but it hardly seems like I'm abusing the skeleton system. If that's the case, there's no indication that I should be doing things differently. The animation works as intended, except for the unexpected AABB culling.

I tried setting the Polygon2D:Offset property to the transform's offset and resetting the transform to be the same as the skeleton, but that offset isn't reflected in the Polygon2D UV editor so there's no (sane) way of adjusting the points and UVs in my case.

It seems rather limiting if this is the intended behavior, if you (like me) try to put multiple components of a character into sprite sheet. The MRP below only shows a pair of legs, but let's imagine there are overlapping parts in an armor set that aren't just a single continuous shape. I would need to provide a separate texture for each overlap each with a strict layout if I can't use the transform or the texture offset.

I've reduced my project to the following MRP. Rotate a bone or start the animation, then pan the view, zoom in and out and the polygons will disappear at some rotations.
Polygon2DBug.zip

@Zoomulator
Copy link

Zoomulator commented Mar 19, 2023

I've created a brute force workaround if anyone needs it. Add the following script to any Polygon2D nodes affected by this bug.

@tool
extends Polygon2D

func _ready():
	var use_custom_rect = true;
	var rect = get_viewport_rect();
	RenderingServer.canvas_item_set_custom_rect(get_canvas_item(), use_custom_rect, rect)

@GeekzGamingz
Copy link

GeekzGamingz commented Jun 13, 2023

I've created a brute force workaround if anyone needs it. Add the following script to any Polygon2D nodes affected by this bug.

@tool
extends Polygon2D

func _ready():
	var use_custom_rect = true;
	var rect = get_viewport_rect();
	RenderingServer.canvas_item_set_custom_rect(get_canvas_item(), use_custom_rect, rect)

This workaround doesn't seem to be working for me. Here is my code so I can quickly update all the children but doesn't seem to be working.

extends Node2D

func _ready():
	var poly = $"."
	for p in poly.get_children():
		var rect = get_viewport_rect()
		RenderingServer.canvas_item_set_custom_rect(get_canvas_item(), true, rect)
		print(rect)```

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