Moving Cyclops Level Builder out of the viewport editor

[blackears]

Cyclops Level Builder started out with the design idea that you could drag-create objects directly in the viewport editor. As the project has become more complex, though, I keep running into more and more issues trying to keep Cyclops integrated.

The way the Godot editor is designed prevents me from responding to input or drawing graphics the way I would like to. And a lot of users are having installation issues with the 1.0.2 release due to how Godot's autoload feature works. I'm thinking of breaking Cyclops into a separate window for block editing, or maybe making it into a stand alone program, which should hopefully resolve these issues.. Let me know what you think.

[jkulawik]

I think turning it into a new tab (along 2D, 3D and Script at the top of the editor window) would be fine. I think that turning it into an external program removes the biggest advantage Cylcops has over Qodot+Trenchbroom, which is that it doesn't need an asset import pipeline.

I imagine that you would need to turn data into a resource that would be edited in that new tab (editor) and Cyclops nodes would hold those resources. One disadvantage this whole thing has is that you might have to essentially reimplement the whole 3D editor, but I haven't done anything like that and can't tell how much is reusable. Speaking of reusability, is it not possible to reuse Godot's built-in gizmos?

[mrezai]

I think same as jkulawik, the biggest advantage of Cylcops over Trenchbroom and Qodot combination is its editor integrated nature.
My suggestion is to list your problems and discuss about them in https://chat.godotengine.org maybe there are some proposal, API or workaround for them.
For graphics part of problems maybe this proposal and this pull request could be helpful.

[blackears]

A separate main window within the Godot editor I think makes the most sense. I'll need to see how feasible it is.

[jkulawik]

As to the Autoload issues, I believe that #121 should resolve them. I might implement it myself but would like some input on it first because I suspect there is more to it than meets the eye.

[blackears]

I liked your suggestion - I've not had time to look into it yet, though. Hopefully it will make the installation easier. I hope to get to it before next week.

[jkulawik]

You know what, I also had another idea. Perhaps you can just make this a Blender plugin? A large portion of the tooling is already there. Collision can be added by Godot's glTF importer. All it really lacks is the automatic UV handling, perhaps some snap options and a faster way of adding new blocks instead of Shift+A > Mesh > Cube.

[blackears]

I've already had a go at it in Blender. But I found Blender even harder to work with than Godot. Blender's Python API is really unpleasant to work with and missing a lot of features. You're also working in a text editor and having to reload all the time. It's UI controls are an after thought - you can't even use them when a tool is engaged. I'd much rather work in Godot. I have made a suite of UV tools for Blender, though: https://blendermarket.com/products/uv-tools

[Roosader]

If you made this standalone, I'd LOVE to see this on iOS/Android. I had asked you on Ko-Fi back in like May about making some touch friendly changes like making the points use screenspace (which you did which is pretty cool), but I think even just straight up porting this tool to those platforms and just recommending users to use a stylus without making really any significant changes (to limit the amount of work) would still be sufficient.

[blackears]

I'm focusing on stability and some core improvements at the moment. My main priority is desktop, but I know a lot of people would like this to work for tablet too. Maybe I can add a special mode for tablet, but that is likely going to be a while off.

[Roosader]

I'm not sure if it would even really be needed for you to add a special mode for tablets. Maybe just an as-is release with minimal changes like larger UI targets. Even released with no changes at all, I think it'd be super usable. If you'd be planning on keeping this open source, I'd even look into making some slight tweaks myself for that purpose and then sharing it as a fork or something. Either way, I really appreciate the work you've done on this and I think it's quite impressive :).

[redhossu]

From my experience as a level designer, the shorter the time between "making a change" and "feeling the impact of that change from the player's perspective," the better.
From this standpoint, the more seamlessly integrated the level editing experience is with the Godot editor, the better the workflow becomes.
Of course, many of Godot's limitations make this task quite challenging. I completely understand that.This will be an extremely challenging project.

[blackears]

My thinking on this has evolved. It might be easier to add a Geometry Nodes like feature to Cyclops. You could create a special node object to hold the Cyclops geo nodes structure and then have a separate window for editing it. That would allow the existing tools to keep working while having this second alternate 3D editor. That way the geo nodes editor can have all the improvements that are difficult/impossible to incorporate into the Godot 3D viewport editor.

[YellowSubm]

Well done! I think this is a great idea, go for it.

I found some information, not sure if they are useful to you.

This is a similar level editor. It has an editing method similar to Blender's point, line, and surface editing.
https://github.com/jarneson/godot-ply

This is a commit about exposing snap settings. It's very useful to me, as I have some of my own ideas about snap. When I work, I control myself to use different grid sizes at different stages to comply with the level's metric document. 10m, used for deciding pace. 1m, used for building areas. 0.25m, used for building interiors (wall thickness). 0.05m, used for detailed decorations. Therefore, I only need four metrics, and I plan to use two shortcuts to switch between different metrics.
godotengine/godot@d804630
godotengine/godot@0ba1027#diff-5f062f3f32862750d20cd1ed1b50d21de173ab5cd8ccb80a8dc8a05311e22691R629

This is a proposal about adjusting the material of each face of CSG. By the way, CSG has been completely refactored nowadays, not sure if it's feasible to build the plugin on CSG.
godotengine/godot-proposals#937

[blackears]

Is the CSG exposed? I've switched Cyclops to have it's own data structure modeled loosely after how Blender does it. Not sure if any CSG library Godot exposes would be useful for that.

I would have liked to do everything the viewport, but Godot has too many restrictions. I can't control the viewport camera, I can't queue a redraw and there are lots of other restrictions. Godot also has a very fixed rendering pipeline, so I can't do tricks with buffers either (or at least not easily. Having to use subveiwports makes what should be simple tasks very tricky. Maybe I can do it working directly with the RenderingServer, but I need to do more research on that). I also don't like that I can't customize the lighting pipeline much either - makes toon shaders and other non-realistic rendering impossible.

Anyhow, enough griping. There is a lot to like about Godot. But there are also a lot of restrictions that make editor plugins like this hard to do.

[blackears]

I'm actually reworking the snapping system right now. If you have any references which you think demonstrate good snapping tools, that might be useful to look at.

[YellowSubm]

Grid

I have some screenshots here, but I think they are pretty routine.
unreal

hammer++


trenchbroom

source2 ( I believe we can almost entirely adopt the approach of Source 2. )

(There's no Unity, simply because I don't have it.)
It's obvious that the engine will intuitively display the values of grid and angle. The workflow of Unreal Engine is more actor-oriented, hence the addition of scale. Specifically, it involves placing a 2m2m2m cover actor. For comprehensiveness, I think it would be reasonable to display grid, scale, and angle. (This is from the perspective of the engine, not Cyclops.)
Therefore, there should be 6 shortcut keys corresponding to increasing and decreasing the sizes of these three values. (For Cyclops, it would be 4 shortcut keys.)
Of course, I also hope there could be a place to preset schemes, which include these three values or other additional settings.
Just like（Similarly, for Cyclops, it is not necessary.）

• Plan: Tiny
  • Plan List
    • Tiny: 0.25m 0.125 1°
    • Mid: 1m 0.5 5°
    • Giant: 5m 2.5 5°
  • Reset
  • Save current setting in current plan
  • Save current setting in new plan

CSG

About CSG, more information can likely be found here:
godotengine/godot#94321
godotengine/godot-proposals#8149
Since dev6, the CSG functionality has been replaced. Many CSG-related issues remain unresolved. Therefore, I believe it is appropriate to propose solutions for the engine during the plugin development process. (By the way, due to this issue: godotengine/godot#46037, the current CSG in Godot is completely unusable for level greybox.)

[blackears]

Most of these examples are just using a power-of-two grid centered on the world origin. Cyclops already has that. There's a snapping settings window where you can adjust that.

The CSG library they're using looks useful. Hopefully that's accessible from GDExtension.