blackears / cyclopslevelbuilder Goto Github PK

Right now undo is chewing up a lot of memory. It would be a good idea to cache some of this data to disk so that the editor remains stable.

Provide non-destructive versions of the CSG operations.

Create a command that generates a mesh from the blocks so the whole thing can be drawn with fewer draw calls.

Seeing the Sizes / Dimensions while creating objects would help. Otherwise you'd have to place a character model or capsule to understand the size of something (and then you have to move it around to wherever you are).

Of course, having a default texture that shows 1x1 meter would also help (additionally):

(image source)

For stairs / ramps, it would be useful to have as a debug info

• the incline in degrees,
• and rise to horizontal run ratio (please cm, not inch)
  • this is already shown in Tool Properties, but not up-to-date if you change it when placing a stair and using the Ctrl+Mouse Wheel to change the step height

When creating stairs/ramps, it can easily happen that their incline is too steep: having this info in numbers would help immensely

(image source)

In 4.1.dev d6dde819b, adding a CyclopsConvexBlock node spams errors if done outside of a CyclopsBlocks parent:

res://addons/cyclops_level_builder/tools/tool_block.gd:238 - Invalid get index 'global_transform' (on base: 'Nil').
res://addons/cyclops_level_builder/cyclops_global_scene.gd:238 - Cannot call method 'get_children' on a null value.
res://addons/cyclops_level_builder/tools/tool_block.gd:238 - Invalid get index 'global_transform' (on base: 'Nil').
res://addons/cyclops_level_builder/cyclops_global_scene.gd:238 - Cannot call method 'get_children' on a null value.
res://addons/cyclops_level_builder/cyclops_global_scene.gd:238 - Cannot call method 'get_children' on a null value.

When creating the node, I suggest checking whether its parent is a CyclopsBlocks. If not, print a human-readable error message using push_error() (to let the user know about invalid usage) then queue_free() the node.

The error message could be:

Cannot create a CyclopsConvexBlock node outside of a CyclopsBlock parent. Create a CyclopsBlock parent first, then use the buttons in the 3D editor toolbar after selecting the CyclopsBlock node to create new CyclopsConvexBlocks.

As I'm holding right-click and using WASD to fly around with the camera in Godot, pressing the Shift key to fly faster runs the "Duplicate" hotkey unintentionally, causing all sorts of jank where things get stuck, and i need to press Esc, clear the selection and finally remove the duplicated mesh in order to get back to track.

Could this hotkey be disabled, alternatively having it changed to something different which doesn't collide with the default Godot-editor controls?

Would be nice if when placing the first block down, it would place it at Y=0, instead of an arbitrary position away from the camera. To hard to determine were the first block will place, and would prevent the need to move back to an origin/desired locaiton.

Also when creating blocks in 2D (orthographic), have origin at X/Y/Z=0 (depending on the view) and default to 1 block "height". Currently it placed block very far away, and makes the resulting block EXTREMEMLY long haha.

Currently dragging UV Transform settings snaps to increments of 0.125 (I think) but for fine tuning UVs it's too high, and typing them in manually can be difficult to get the right amount. Would it be possible to lower the default setting snap amount or make it adjustable? If it can be changed in code, where would that be?

Right now spheres are being used for vertices. Use billboarded points instead.

Right now, you can use Escape to cancel shape drawing, but not right mouse button (unlike Blender). I'm pretty used to using right-click to cancel such actions, so I'd like to see this in Cyclops 🙂

If you really want to use freelook while shape drawing, use Shift + F to toggle it. (Note that you won't be able to rotate the camera, only move it.)

• Related to #10.

When creating a prism, you don't know exactly where each point will be snapped to until you click.

I suggest drawing a translucent yellow sphere to denote the location where the next point will appear when you click, based on the current grid snap distance.

Adding little edge indicators that extend beyond shapes in the direction of the edge can be useful for lining things up.

Hey, I'm Nathan from GDQuest. This follows up on our short exchange on your channel.

For convenience, I went ahead and compiled all the notes in a single post. That way, you can review quickly and filter desired changes before opening too many unwanted issues in the tracker.

I kept the feedback focused on what the add-on is currently at, it seems to be what you desired.

Please don't hesitate to take and leave what you want, ask for more details and whatnot. I'm happy to help wherever you'd like help, and happy to not touch or bother you with areas you'd rather keep full control of.

Initial question

I was wondering if you tried leveraging built-in nodes, such as MeshInstance, and if you faced specific limitations that prevented you from using them?

I'm asking because you need to re-implement features Godot provides for them such as simple and box selection, focus, etc. And this choice will affect future UX improvements the Godot developers bring to the 3D editor.

Toolbar

Observations:

1. Firstly, the Godot toolbar isn't too great right now, and this is not your fault at all, but it limits the clarity of the user interface you can provide due to offering only a horizontal layout and getting visually cluttered quickly.
   • It limits the ability to use descriptive text labels, hurting accessibility
   • The toolbar doesn't make it clear what are your add-on's tools
   • Usability gets worse as multiple add-ons add widgets to the toolbar
   • Modeling tools aren't available until you select a specific node, which also limits accessibility and discoverability (as opposed to having some UI piece that's always present)
2. Tools aren't very quick to select as you have to use the mouse to reach them
3. Tools aren't the easiest to spot and distinguish at a glance
4. Grid snapping and display dropdown aren't descriptive

Proposal:

1. There is no very satisfying solution for this, it's a general issue in Godot, and a well-known one. This point is mostly to open discussion.
   • The most Godot-like thing for pretty powerful editor interfaces is using the bottom panel (examples: tilemap, animation, animation tree, shader graph...).
   • It gives you a lot more control over the UI design and allows you to have your own toolbar, completely separate from Godot's main toolbar (see animation and tilemap panels for examples)
   • Your tools can always be visible, allowing the user to start modeling anytime.
2. Shortcuts! At least for the most important tools I'd register custom shortcuts
3. Several suggestions:
   • Add an icon for each tool with a color code
     • Green to add, blue to select, for consistency with Godot tools.
   • Visually group and separate selection tools (vertex, edge, face) from modeling tools.
   • Use editor styles for consistency with built-in tools.
   • Block tool falls into two categories currently, but what I'd consider is giving vertex/edge/face the features of the block selection. If you click on a deselected block, it gets selected and vertices appear. Shift click can select other blocks or vertices...
     • I can write a dedicated proposal for that if that's desired because there are many details to outline.
     • The short pitch is I'd consider separating the selection and modeling tools for clarity. I'd add a block selection tool for selecting, moving, and deleting entire blocks.
   • If sticking to the Godot toolbar, I'd have just icons with tooltips similar to what Godot does. Again, not ideal at all, it's a limitation of the toolbar design and not something I find particularly great. But that'd make the add-on more accessible to users with small displays (e.g. 13" laptop), and the UX more consistent with Godot.
   • If going to a bottom panel, I'd definitely have icons + labels for tools, and similarly some grouping.
4. There again there's a difference if you stick to the toolbar or not.
   • If sticking to the toolbar, I'd consider either adding an icon to each dropdown and units for the grid snapping (little gray "m" as seen in the Inspector). Or I'd offload options to a vertical "..." menu that would open a modal window

Materials dock

Observations:

1. Without docs the UI has limited discoverability
   • You have to figure out that you must drag and drop specific resources onto the dock's look and feel is quite different from the rest of the Godot interface
2. Materials can't be removed individually, it seems, it's all or nothing
3. Remove All instantly removes materials and cannot be undone. It's a sensitive operation

Proposal:

1. Have an "Add materials" button that pops up a file browser alongside the Remove All button
2. Reuse the look and feel of the file system dock in gallery mode
   • Give material entries a fixed width
   • Use the string API to trim long text
   • Have a panel with darker background for the area containing the materials
   • Use editor styles for the materials so the look matches user theme and adapts to light themes automatically
3. It's not an essential operation, but it'd probably be nice to be able to select and remove a material? Multiple materials? I'm not 100% sure without testing extensively.
4. Add a confirmation popup or if possible, undo redo support

Other suggestions:

• There are few materials in the demo scene, but back when I worked as a 3D game artist (worked in UDK so with similar modeling tools), we used larger numbers of materials. It may be useful to have a filter bar at the top of the dock, similar to Godot's file filter.

UV dock

Observations:

UV transform options feel like inspector properties but are put in a separate dock with a pretty different user experience.

Proposal:

Use the inspector plugin API to integrate the UV controls and future block-level properties into the inspector. On top of offering a feel similar to the rest of the inspector, it could be extended with interactive widgets or modal windows if needed.

Making this work with probably involve using the scene API to select Block nodes in the scene dock when using the Block tool.

Note that selecting individual block nodes in the scene dock with your Block tool would allow you to leverage the Focus command in Godot (F key), allowing the user to recenter the camera just like when they select regular 3D meshes.

I hope that some of the above is useful. You are welcome to take or leave anything, of course. I'm happy to participate in further discussion or help tackle some issues if desired.

When more than one shape is selected, pressing Convex Merge in the toolbar will collapse them together, creating a single shape with all the outer points (the empty space is filled, as the resulting shape is convex).

This can be used to quickly create bridges, angled corners and more.

• Related to #17.

Add a staircase tool to quickly draw a staircase with a defined step height, which can be set in the toolbar. The number of steps is automatically determined based on the shape's height, and each step's width is also set automatically based on the shape's depth.

Drawing is performed in a similar fashion to the box tool. The staircase's direction is automatically set based on the direction your cursor is moving towards (i.e. the position of the last point relative to the first one).

• Related to #15.

Godot's own OccluderInstance3D baker is not able to bake Cyclops nodes into an occluder, since it only accepts MeshInstance3D nodes. This means you can't use Godot's occlusion culling unless you manually place occluders, which is time-consuming.

It should be possible to manually create an ArrayOccluder resource to give to an OccluderInstance3D node. This bypasses Godot's own occluder baker entirely. This can be one occluder per shape, or one for the entire collection of blocks (which may be faster to render).

Additionally, the baked occluders could be shrunk along the normals to avoid overocclusion (similar to gongpha/gdQmapbsp@9d031ad).

• Related to #16.

Add a cylinder tool that allows you to specify an angle arc where the cylinder should be drawn, then the depth by clicking a second time. The level of detail per full turn (probably 32 by default) could be adjusted in the toolbar.

It's important that the tool lets you draw cylinders that are not full-circle easily, as it's common to use 90-degree and 180-degree cylinders in level design (or sometimes even unusual values like 45-degree).

Since outward cylinders are convex, they can be created as a single block. Being able to create inward cylinders would be very useful in level design, but these must be drawn as separate blocks. This will likely require a lot of refactoring and may be better implemented separately (e.g. using a prefab system and a default set of prefabs).

The icon bar has a blue line drawn under it. I think it has something to do with the PanelContainer that contains all the buttons. The component needs to be redesigned so that the buttons sit neatly in a row with no extra UI elements appearing behind them or expanding the size of the toolbar.

Hi! I recently learned about this tool through Gamefromscratch and it looks really cool.

However, one of the top questions on my mind is, "What version of Godot is this compatible with?" Since 4.0 was released relatively recently and introduced a lot of breaking changes, and since the 3.x line is still considered the "LTS" version, it seems valuable to call this out prominently in the documentation somewhere.

(I would just submit a PR to add the docs myself but I don't actually know what versions it supports!)

Right now, when you select a shape and move it, it only moves along the XZ plane until you hold Alt. This is good behavior, but when you hold Alt, the previous XZ movement you've done is replaced by the Y movement. Instead, I expect all future mouse movement to only affect the Y axis until I release Alt, while keeping the XZ plane movement intact for the current move operation.

This allows moving an object along 3 axes with a single mouse drag, while still benefiting from the default behavior (XZ plane constraint). See godotengine/godot-proposals#3006 for a video that shows the behavior I'd like.

This proposal applies to all kinds of dragging (shape, vertex, edge, face).

The undo stack is chewing up a lot of memory at the moment when editing large scenes. It would be a good idea to cache large objects to disk.

I think it might be interesting to have a button on the toolbar so that the user can activate or deactivate the collision of a block on your map
I saw that inside the block data there is a bool that defines the collision, however it doesn't seem to be working

Add an extra display mode that displays the checkboard pattern on all surfaces instead of assigned materials.

Currently, you have to go click the tools to select them. It'd be nice to have keyboard shortcuts.

The simplest way to go about that is using the _input() function, which is the first function to receive inputs. It lets you consume input events by calling Viewport.set_input_as_handled().

You can use Shortcut resources or plain input event checks, either works.

Then, you mentioned the issue of keys clashing with the editor keys.

As far as I know, the plugin API doesn't let you register customizable shortcuts to the shortcut editor.

Until it does, you have workarounds like this one from a teammate to register to the project settings instead, which allows users to customize shortcuts in case there's a conflict with one of their shortcuts: godotengine/godot-proposals#2024 (comment)

The code example uses serialized Shortcut resources but it works the same if you do it 100% in code.

Basically simplified stairs

In 4.1.dev d6dde819b, this error prevents enabling the add-on:

Cannot open file 'res://.godot/imported/materialTest.glb-89a5487d9d67cb795bea9d0f40563ce7.scn'.
Parser bug (please report): Trying to check compatibility of unset value type
res://addons/cyclops_level_builder/cyclops_level_builder.gd:85 - Parse Error: Preload file "res://icon.svg" does not exist.
Parser bug (please report): Trying to check compatibility of unset value type
res://addons/cyclops_level_builder/cyclops_level_builder.gd:85 - Parse Error: Preload file "res://icon.svg" does not exist.

Since the icon path is not always res://icon.svg (and not all projects even have an icon as you can remove it), I suggest reading the value of ProjectSettings.get_setting("application/config/icon"). If that string is empty, use GradientTexture2D.new() as a placeholder instead.

Right now, all geometry is flat-shaded. This makes cylinders impossible to draw without their geometry looking visibly blocky, even if the geometry itself has enough detail. Smooth shading should be used when it makes sense, ideally doing this automatically based on the angle of each face relative to the others in the shape.

The default angle threshold could be 44°, so that octagons are still flat-shaded but anything smoother is smooth shaded by default. This is the angle threshold used by Cube 2 engine games by default (/lerpangle). This angle threshold could be configured by a project setting or CyclopsGlobalScene node.

There could also be a per-shape property to override the angle threshold for a specific shape, though I don't think this would be needed often. In my experience, an automatic threshold can get you pretty far without having to worry about it 🙂

Related Godot proposal for CSG: godotengine/godot-proposals#1862

• Related to #4.

Right now, you can press Backspace to remove the last drawn point in a prism that isn't finalized yet. This makes it impossible to remove a point that was drawn a while ago when drawing a complex prism, without removing all points that lead to the problematic point beforehand.

Right-clicking a drawn point in prism shape drawing mode should remove the point in question. This can be used to correct mistakes as undo/redo keys don't work here.

Right-clicking far away from a prism point shouldn't do anything, so you can keep using freelook while placing points.

Letting users specify vertex color info per face could let materials be more dynamic.

Right now, all faces are drawn, even if they face other solid objects. This can impact performance in complex levels, especially when using the Forward Mobile rendering method which lacks a depth prepass (which means overdraw is expensive there).

There should be a way to mark certain faces not to be drawn, similar to assigning a nodraw texture in GtkRadiant. (The mesh generation should skip those faces entirely, as opposed to using an invisible material.)

Doing this automatically would be nice, but I think it's good to have this as a manual step for now.

Materials can't be removed individually, it seems, it's all or nothing.

It's not an essential operation, but it'd be nice to be able to select and remove a material or multiple materials at the same time.

At the moment, all hot keys are hard wired. Provide a way for users to configure them.

Gizmos would be easier to use than the current default-drag for XZ plane and Alt-drag for Y axis system.

Being able to set the rotation of the grid based on a selected face (or manually) while working on off-angle brushes would be absolutely amazing. One of the pain points when working in Hammer/Trenchbroom is working on 45s (and more-so for weirder angles).

Example: Clicking on the red face rotates the grid, so now you can work "off angle" and drag out new parts.

As you have multiple blocks selected, would it be possible to add a feature which ties them into a group so that they can be re-selected later?

It's a huge time-saver being able to duplicate/move around structures you've set up prior, compared to having to select each and every block related to that structure.

Some sort of "Group" selection mode could perhaps be added on the top-bar:

Coming from the source engine using Hammer Editor, the hotkey to group is CTRL+G, (and ungroup being CTRL+U) which doesn't seem to be tied to anything in Godot by default from what i can find.

Materials can't be removed individually, it seems, it's all or nothing

There could be an an "Add materials" button that pops up a file browser alongside the Remove All button

While Godot will currently allow exporting the scene using Scene/Export As/Gltf, it could be useful to have a more dedicated exporter just for cyclops blocks.

• Related to #4.

Right now, when you click once with a shape drawing mode, nothing happens. This is likely because only a "click-hold-release" workflow is programmed, and since the mouse hasn't been moved by more than a few pixels between the mouse press and release, drawing is canceled.

Instead, I expect the first point to be visible, allowing me to move the mouse to the desired location, then clicking a second time to set the shape's depth.

To implement this, there should be an "hysteresis" distance below which the shape is considered to be drawn in "click-click" fashion. This means that if the mouse has moved by less than 8 pixels between its click and release location, it should be considered as a click and not a drag.

In 4.1.dev d6dde819b, adding a CyclopsGlobalScene node prints an error (regardless of whether the scene already contains a CyclopsBlocks node):

Node not found: "ToolInstance3D" (relative to "/root/@EditorNode@15951/@Control@6/@Panel@7/@VBoxContainer@15/@HSplitContainer@18/@HSplitContainer@26/@HSplitContainer@34/@VBoxContainer@35/@VSplitContainer@37/@VSplitContainer@63/@VBoxContainer@64/@PanelContainer@103/MainScreen/@CanvasItemEditor@9121/@VSplitContainer@8948/@HSplitContainer@8950/@HSplitContainer@8952/@Control@8953/@SubViewportContainer@8954/@SubViewport@8955/Node3D/CyclopsGlobalScene").
res://addons/cyclops_level_builder/cyclops_global_scene.gd:59 - Invalid set index 'mesh' (on base: 'null instance') with value of type 'ImmediateMesh'.

This error seems to prevent the node from getting its custom icon in the Scene tree dock, even though it's visible in the Create New Node dialog.

The node's functionality seems to work fine in the editor regardless of this error. Running the project will cause a script error.

The addon uses styles that are different from those of the Godot editor and will not play well when users the changes their editor theme.

When possible to get the editor styles you want to avoid adding style boxes and other things on nodes. For example, to make a clickable icon or label you can create a Button node and set its flat property to true.

In other cases, you can import styles from the editor theme into your UI's theme resource. In the theme editor, click Manage Items... in the top-right, go to the Import Items tab, and Editor Theme. This is especially useful for getting constants such as spacing and whatnot.

To mimic the editor styles you sometimes have to go look at the engine source code to see what they use because it's not always obvious.

It's unfortunately impossible to use the UV Transform as the actual face is completely whitened out when using face to select:

Right now XZ is assumed for dragging by default. Provide button to let users choose the axis/plane to drag along instead. This is better for mobile devices too.

• Related to #4.

Right now, you need to press Enter to confirm prism shape drawing. Double-clicking a point or within the shape should confirm the drawing too, so that you don't have to move your hand from the mouse to the keyboard to perform this operation.

It'd be nice to have a confirmation popup or if possible, undo redo support

• Related to #14.

Currently, lightmaps can't be baked on a Cyclops level (although VoxelGI, SDFGI and ReflectionProbe all work as expected). This is because no UV2 is generated for the shapes, and no lightmap size hint is set for the meshes either.

Godot doesn't expose xatlas (which is internally used to create UV2 for imported 3D scenes), so a custom method must be used here. Fortunately, shapes are usually quite simple and guaranteed to be convex, so this should be less complex than xatlas.

A lightmap scale project setting or CyclopsGlobalScene node should also be added to control the lightmap size multiplier. This can be used to make lightmaps more detailed or more coarse, depending your needs (in terms of bake times and file size).

• Related to #8.

Right now, the default material is just a grid, with no visible subdivisions.

Similar to what I proposed in godotengine/godot-proposals#6138, I suggest adding a subtle checkerboard pattern that tiles twice on each grid square (which means a 4×4 checkerboard pattern is visible on the texture). This would make it easier to count subdivisions when working with smaller grid sizes, as each checkerboard tile would be 0.25 units by default.

I was thinking about making those adjustments myself, but I noticed there are Aseprite source files (and I don't have Aseprite to modify those directly).

After upgrading to 1.0.1, all the materials that i've added under the "Materials" tab go away after clicking away (to either the "Uv Transform"/"Tool Properties" tab, or by de-selecting the "CyclopBlocks" node entirely).

I constantly need to re-add the materials manually before being able to assign them to faces with this.
This also happens from creating a brand-new Godot project with a fresh install of the addon, just to confirm.

1. empty:
   

2. added some materials:
   

3. selected the "Uv Transform" tab, then went back to the "Materials" tab again, now it's all gone:
   

"download the zip"

for any noob that dont know where the zip is pls add an installation tutorial for child's and idiots.
i am not joking not anyone knows how to use github and where to find things.

Icons would make the tools easier to spot. I can provide SVG files if you'd like.

Ripping these right from Trenchbroom since they are very nice to have, and are used a lot.

Outlining the used area would be handy (can be seen in any of the videos below, the white outline).
Have the outline be draggable to quick and easily position it wherever you want.

Being able to have the UV window zoom-able and tiled when you are zoomed out past 100% (have a grid so you can see when it tiles).

Rotate and change the rotation origin from within the window would be nice. Maybe also have quick buttons to flip on X & Y, and also rotate left & right by 90°?

Shearing usually isn't used too too much, but might be a nice addition.

Having configurable incremental snapping would be great for trimsheets, being able to bump the alignment of the texture with arrow keys would also be extremely nice.