Godot: Polygon2D/Skeleton2D rendering bug when the polygon's rest pose is outside the viewport

Created on 30 Jan 2020  路  14Comments  路  Source: godotengine/godot

Godot version:
3.2.stable

OS/device including version:
Windows10 x64 1809

Issue description:
Polygon2D texture is not rendered with Skeleton2D if the rest pose of the polygon is outside the viewport but when animated polygon should be inside the viewport. Same results in the editor and when scene is playing. GLES2/GLES3 both.

Steps to reproduce:
Play example scene or pan in the editor so that the transparent icon moves outside the viewport
capture

Minimal reproduction project:
skeleton_bug.zip

bug core

Most helpful comment

We should be able to add the custom rect as a property of Canvas items and then expose it to the editor. That should make this way easier to solve.

Eventually I guess we need to recompute bounding rect from the animation, but I don't know how slow that would be.

All 14 comments

I can confirm. Faced the same problem in my project.

Is there a workaround for this problem? I'm trying to animate a snake-like creature, but since it's a long straight line down in its Rest Pose (because setting up the Skeleton), and then more horizontal for its animation, if it's too low on screen, half its segments disappear.

https://www.youtube.com/watch?v=0P_ctbHoTvs

@SaffronStreams You could change the CanvasItem's culling rect to be large enough to cover the whole pose, so it never fully leaves the screen. I don't remember how to do it exactly though. I think you need to increase the Extra Cull Margin property or something like that.

I've gone down a little rabbit hole looking for how to override or change the culling rectangle or force the canvasitem to be drawn, but although I've found some possible hints, those properties/methods have no documentation on them or discussion online.

Coming back to this problem as I have a wide spider model that suffers greatly from this problem.

I've found there's a get_viewport().get_visible_rect() method, but the rectangle passes a constant, so you cannot change it. Can't find it in Project Settings.

There are also nodes called VisibilityNotifier2D/VisibilityEnabler2D, but those don't seem to work/override what Skeleton2D does to visibility.

I'm somewhat surprised that this issue hasn't been added to a milestone yet. It is pretty breaking for the 2D experience. How can we get dev attention for this? Or is this an edge case I just keep bumping into?

I'm somewhat surprised that this issue hasn't been added to a milestone yet. It is pretty breaking for the 2D experience. How can we get dev attention for this? Or is this an edge case I just keep bumping into?

I can't guarantee this will be fixed for 4.0, as reduz may be too busy handling other issues right now. We try to reserve milestones for critical issues where we can reasonably assume they'll be fixed by the time the version is released.

Yeah, I read reduz has to work on specific Vulkan stuff because of the sponsorships that have been granted. I guess all other attention is dependent on interest by contributors. Then again, perhaps there's room for an extra hire in the budget who can devote some time back to 2D? I understand wanting to improve 3D to draw in more people, that's where the big budget is, but some of the earlier people came in especially because of the 2D capabilities, so I would hope that keeps getting attention as well.

I'm going to spend some more time looking for a workaround, but have been considering looking into C++ (even though the idea is daunting) so I could contribute to a solution. Then again, that solution might simply be to make visible_rect of viewport not a constant but changeable, perhaps with a warning in code or something?

This seems to fix it for me.

extends Polygon2D

func _ready():
    var custom_rect:Rect2 = Rect2(Vector2.ZERO,Vector2(1000,1000))
    VisualServer.canvas_item_set_custom_rect(get_canvas_item(), true, custom_rect)

I had been looking at VisualServer, wondering if it was something I needed to do there, but couldn't really figure out what does what. This code (slightly adapted*) certainly does something. It helps for certain nodes, doesn't for others. Is there some more documentation available on how this method works? (the docs are pretty sparse :-) "Defines a custom drawing rectangle for the CanvasItem.")

*func correct_all():
var custom_rect = Rect2(Vector2.ZERO, Vector2(3000,3000))
for polygon in $polygon.get_children():
print("check: " + polygon.name)
VisualServer.canvas_item_set_custom_rect(polygon.get_canvas_item(), true, custom_rect)

(I set it at 3000 because my base models are pretty big (for if I ever need to zoom in for cut_scene))

Without this code (look when Drider (spider-like) character enters and leaves screen):

without_code

With code:
with_code

(Thanks for the help btw, seems like this is a promising path)

Yeah I've used the physics server stuff before, which uses a function called get_rid() on the nodes that use it. It was pretty confusing to find it for the canvas nodes. I think get_canvas_item() should be renamed to get_canvas_rid().

Also you might be able to use a Control node to copy its rect to use, so you can visually see it in the editor.

extends Control
func _ready():
    var custom_rect = Rect2(rect_position, rect_size)

I figured it out. I took over the Vector2.ZERO from your example code, but that determines the position of the rect within the base node of my character. I've now put it at Rect2(Vector2(-2000, -2300), Vector2(6000,2500)); which seems to do the trick!

(Remember, the Drider you see on screen is scaled down ( to .17 to be exact), I make them so big because I like to have the possibility to zoom in. If I ever need to look for performance gain, it's probably there that I'll find it.)

We should be able to add the custom rect as a property of Canvas items and then expose it to the editor. That should make this way easier to solve.

Eventually I guess we need to recompute bounding rect from the animation, but I don't know how slow that would be.

Fixed in 3.2.3 with #40869, but still relevant to fix for master.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SleepProgger picture SleepProgger  路  3Comments

RebelliousX picture RebelliousX  路  3Comments

mefihl picture mefihl  路  3Comments

testman42 picture testman42  路  3Comments

Zylann picture Zylann  路  3Comments