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

Refactor collision shape editor to a common code base #1157

Open
Tracked by #15
Xrayez opened this issue Jul 3, 2020 · 3 comments
Open
Tracked by #15

Refactor collision shape editor to a common code base #1157

Xrayez opened this issue Jul 3, 2020 · 3 comments

Comments

@Xrayez
Copy link
Contributor

Xrayez commented Jul 3, 2020

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 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:

Basically very similar to godotengine/godot#11019 but to operate on Shape2D resources.

Annotation 2020-07-03 204730

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:

  1. Edit the shapes via CollisionShape2D.
  2. Save the edited resource.
  3. Drag-n-drop the resource to VisualShape2D.

vs

  1. 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.

@Xrayez 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
@Xrayez
Copy link
Contributor Author

Xrayez commented Nov 25, 2020

@Xrayez
Copy link
Contributor Author

Xrayez commented Nov 25, 2020

Use case

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.

@Shadowblitz16
Copy link

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.

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

No branches or pull requests

3 participants