-
-
Notifications
You must be signed in to change notification settings - Fork 21k
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
Preview resolution value for curves to alleviate performance issues of long curves #90357
base: master
Are you sure you want to change the base?
Conversation
574053c
to
06d17cf
Compare
Would be best to wait for this change before attempting a merge #86195 |
Unsure why the unit test is failing with |
You need to add the argument to the bind: ClassDB::bind_method(D_METHOD("set_preview_resolution", "resolution"), &Curve2D::set_preview_resolution); |
06d17cf
to
dbd2c18
Compare
dbd2c18
to
d150dcf
Compare
…sues of long curves. Curves now preview in editor with a fixed resolution per curve section that can be defined by the user.
d150dcf
to
1e6ebed
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally (rebased on top of master
739019e), it works as expected.
path_3d_detail_settings.mp4
One concern I have though is that the debug_preview_resolution
property is part of the Curve2D/Curve3D resource, while I think it should be part of the Path2D/Path3D node, like #82321 does for its debug color property. The resource does not have any visual representation of its own, so a subdivision count property feels out of place (and may be confused with the existing Bake Resolution).
I don't see the point in not having this as an editor setting, instead. |
You may need per-path adjustments to ensure performance remains good in the editor (while preserving as much detail as possible), as some paths can be very long and complex while others can be shorter. |
real_t offset; | ||
point == 0 ? offset = 0 : offset = c->get_baked_distance_at_point(point); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
real_t offset; | |
point == 0 ? offset = 0 : offset = c->get_baked_distance_at_point(point); | |
real_t offset = point == 0 ? 0 : c->get_baked_distance_at_point(point); |
Don't use assignment inside a ternary
real_t offset; | ||
point == 0 ? offset = 0 : offset = curve->get_baked_distance_at_point(point); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
real_t offset; | |
point == 0 ? offset = 0 : offset = curve->get_baked_distance_at_point(point); | |
real_t offset = point == 0 ? 0 : curve->get_baked_distance_at_point(point); |
@AyyZerrAsa Are you planning to apply suggestions / improve this PR? What I don't like about this PR is that no matter how short given path segment is, it would still draw all Also another missing optimization/simplification is using only a single segment for path segments with relevant out/in zero vectors (they're straight line segments, no need to subdive them). +I support godotengine/godot-proposals#9459, disabling the fishbones/arrows drawing should be possible one way or another (whether by a project setting, or per Path2D/3D property (like the one being added in this PR)). |
Fixes #81707
Curves now preview in editor with a fixed resolution per curve section that can be defined by the user. This helps avoid the issue with long curves producing a very large amount of primitives/draw items, which decrease the responsiveness of editing path3d/path2d curves.
closed
property toCurve3D
#86195Godot.Path3d.Fix_2.mp4