You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the problem or limitation you are having in your project:
Impossible to edit Shape2D resources outside CollisionShape2D nodes, which also provides the editor plugin for modifying the shapes via editor handles.
Describe the enhancement and how it helps to overcome the problem or limitation:
Create AbstractShape2DEditor and AbstractShape2DEditorPlugin. That way, it would be fairly easy for plugin and module writers to come up and combine different implementation for shape editing. I personally would find this useful in goostengine/goost#2 for creating VisualShape2D to debug and visualize individual collision shapes without having to create sprites etc, see: #1126.
As of now, I've currently managed to implement a dedicated editor for modifying polygon-based shapes (ConvexPolygonShape2D, ConcavePolygonShape2D) in VisualShape2D by inheriting AbstractPolygon2DEditor currently implemented in Godot without issues at all: godotengine/godot#11019. On a side note, it's currently not possible to do this in Godot, and it won't be possible to do due to resolution of godotengine/godot#21394. But for visualizing purposes (other than physics), it's a perfectly acceptable use case.
The problem is that, while I've managed to implement polygon editing, I'm left with no straightforward tools to actually implement other shape editing as implemented in CollisionShape2DEditor. While you can still edit a shape via the inspector, it's obviously not as intuitive as doing it via editor handles.
Describe how your proposal will work, with code, mockups, and/or diagrams:
The left capsule shape is edited through CollisionShape2D, and on the right that's VisualShape2D (see no handles). The task is to make it work for both nodes, and any other nodes which can be implemented in the future (either in Godot directly or other community-driven modules).
If this enhancement will not be used often, can it be worked around?:
It's perfectly possible to copy-paste the code needed to make this happen in C++ modules for other nodes, but that would mean bloating the module, and the possible bug fixes and features would have to be synchronized between Godot and Goost codebases manually.
To summarize the current hurdles:
Edit the shapes via CollisionShape2D.
Save the edited resource.
Drag-n-drop the resource to VisualShape2D.
vs
Edit the shapes via VisualShape2D.
Is there a reason why this should be core and not an add-on in the asset library?:
It's already part of core. No GDScript need to be exposed to users, and no API changes.
I can implement this myself.
The text was updated successfully, but these errors were encountered:
Xrayez
changed the title
Refactor collision shape editors to a common code base
Refactor collision shape editor to a common code base
Jul 3, 2020
Found a use case by @briansemrau for Box2D integration with Godot. You can clearly see the amount of code written for editing polygon-based shapes vs other static shapes like CircleShape2D:
I've been implementing polygon boolean operator nodes in goostengine/goost#39 for editing polygon-based shapes as well, and some of them replicate the functionality behind CSG nodes in 3D. The editor there would greatly benefit from using the same codebase already available in the engine, like generating circle-based shapes for boolean operations.
The would be nice to see in 3d nodes too.
I would really like to see VisualShape and CollisionShape to have similar APIs for both 2d and 3d and just remove polygon nodes in favor of just passing a shape resource.
I would also like to see collision shape to have a border thickness like VisualShapes in which either it's treated as a collision margin or having it just be there to shrink the shape down a bit.
Describe the project you are working on:
Goost - Godot Engine Extension.
Describe the problem or limitation you are having in your project:
Impossible to edit
Shape2D
resources outsideCollisionShape2D
nodes, which also provides the editor plugin for modifying the shapes via editor handles.Describe the enhancement and how it helps to overcome the problem or limitation:
Create
AbstractShape2DEditor
andAbstractShape2DEditorPlugin
. That way, it would be fairly easy for plugin and module writers to come up and combine different implementation for shape editing. I personally would find this useful in goostengine/goost#2 for creatingVisualShape2D
to debug and visualize individual collision shapes without having to create sprites etc, see: #1126.As of now, I've currently managed to implement a dedicated editor for modifying polygon-based shapes (
ConvexPolygonShape2D
,ConcavePolygonShape2D
) inVisualShape2D
by inheritingAbstractPolygon2DEditor
currently implemented in Godot without issues at all: godotengine/godot#11019. On a side note, it's currently not possible to do this in Godot, and it won't be possible to do due to resolution of godotengine/godot#21394. But for visualizing purposes (other than physics), it's a perfectly acceptable use case.The problem is that, while I've managed to implement polygon editing, I'm left with no straightforward tools to actually implement other shape editing as implemented in
CollisionShape2DEditor
. While you can still edit a shape via the inspector, it's obviously not as intuitive as doing it via editor handles.Describe how your proposal will work, with code, mockups, and/or diagrams:
Basically very similar to godotengine/godot#11019 but to operate on
Shape2D
resources.The left capsule shape is edited through
CollisionShape2D
, and on the right that'sVisualShape2D
(see no handles). The task is to make it work for both nodes, and any other nodes which can be implemented in the future (either in Godot directly or other community-driven modules).If this enhancement will not be used often, can it be worked around?:
It's perfectly possible to copy-paste the code needed to make this happen in C++ modules for other nodes, but that would mean bloating the module, and the possible bug fixes and features would have to be synchronized between Godot and Goost codebases manually.
To summarize the current hurdles:
CollisionShape2D
.VisualShape2D
.vs
VisualShape2D
.Is there a reason why this should be core and not an add-on in the asset library?:
It's already part of core. No GDScript need to be exposed to users, and no API changes.
I can implement this myself.
The text was updated successfully, but these errors were encountered: