Improve GridMap and 3D level design workflow

[Nodragem]

Describe the project you are working on

I have been working on a Top-down Action/Adventure starter kit. It inspired all the ideas I've got to improve the level design workflow in Godot. It is open source and available here: https://github.com/Nodragem/top-down-action-adventure-starter-kit

Describe the problem or limitation you are having in your project

There are many little things that can be done to make the on-grid level design experience (e.g. gridmap) greater and I will be listing them here, as a working plan for future contributions.

I am very happy to get feedback and help in shaping this plan for better on-grid level design tools and implementing it!

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Outside Gridmap

• change default drag-and-drop behaviour of 3D asset to add as sibling Change default parenting behavior when drag-and-dropping to 2d and 3d editor godot#91874
• preview/thumbnail of packedscene containing a node3d/mesh
• absolute snapping
• snapping relative to a Gridmap
• hide big gizmo in selection mode (to easily select small objects in levels)
• easier to understand grid properties in Editor Setting (e.g. Grid Division Level Max?)

Gridmap Small Features (but impactful)

• moving the gridmap to its own bottom panel Move GridMapEditor to bottom panel godot#96922
  • surface tools and actions in the UI
  • fix rotation of the selection area after pasting
  • better integration with 3d editor (transform mode to rotate, move, scale gridmap)
  • allow keeping focus on Gridmap even when click else where (not in transform mode)
• change paste selects to a better name
• allow to rotate selected cells
• add flip/mirror horizontal/vertical Add flip/mirror option to GridMap #5883
• show mesh origins (Add a toggleable mesh origin display in the GridMap editor #6651)
• show colliders
• painting/selection tools: paint on top of or next to used cells (box stacking
• shortcuts? moving actions to A,S,D,F?

Gridmap Small Fixes:

• fixing moving/duplicating a set of tiles in Gridmap Fix copy-paste and cut-paste in GridMap godot#95322
• fix: selection rotation when working centerX, centerY, centerZ are True
• fix: in transform mode, the selection is not updated when moving/scaling, rotating the gridmap
• fix: gridmap does not update when used as a scene in a scene

Mesh Library and Gridmap Palette

• add "delete from mesh library" in the palette
• multi selection in palette (which will allow for random paint/fill)
• add tags or categories with tabs
• possiblity to work with multiple mesh libraries?

Brush improvements

• improve brush/eraser preview: hide current tiles under the preview: GridMap: hide tiles when mouse hovering over them (to give ability to see how gridmap will look like after placing new tile) godot#5526
• add brush spacing. Modular assets often come in 2x2 size to work on a 1x1 grid, hence to control spacing is important. More details here: Add a Brush Spacing property to GridMap to control spacing between tiles when using paint/fill tools #9612
• add brush size and shape. Possibly add a preset to save different shape/size.
• add tile blocks (or group of tiles): save selection of tiles on the gridmap as a tile block. This tile block is selectable in the palette as a tile. For instance, we select a corner made of a floor tile and 2 walls and we save it as a tile block. We can now select it in the palette and paint it as a normal tile.
• add random tile fill/paint: allow multiple tiles to be selected in the palette, and allow to set probability by tile (similar to what we have in Tilemap, except that we can set the probability ourselves).
• add random tile preset: possibly to save a selection of tiles and probabilities as a preset.

Gridmap Bigger Improvements:

• improving selection tool:
  • allow complex selections. At the moment we can only select cubes!
  • allow to add, remove from selection
• improving paint/selection tool:
  • allow Point, Line, Rectangle, Cube selection
  • select on xy, yz, xz plane
  • while having nice keyboard shorcut which do not conflict!
• clever fill tool: like terrain but needs to work with 3D modular assets rather than 2D tiles worflow.
• merging two gridmaps
• copy-pasting between gridmaps
• baking meshes to one mesh? (https://youtu.be/h_4W7GSspco?si=MbSiNzmoJfDJgjbw)
• placing scenes (but still appearing in the scene tree)? at this stage Gridmap Editor would be more of a Level Editor
• select mesh with keyboard (1-9, favorite bar)

Navigation Mesh:

• discuss the possibly to sunset the current navigation system by tiles? and replace it by navigation region.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This proposal will be divided into smaller proposal and PR. It is here to give a big picture.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No.

Is there a reason why this should be core and not an add-on in the asset library?

Gridmap is already core.

[Hiiamwilliam]

I'd like to share my thoughts. I've spent a good time working on a 3.X plugin (not published yet) to fix some issues and add some functionalities. However, I did some quick tests, and will consider the 4.4.dev3 version as reference for this comment.

Before thinking about future improvements, I'd prefer if some current limitations/bugs were taken care of - I'll list them with a bunch of other unorganized thoughts at the end. Meanwhile:

absolute snapping + snapping relative to a Gridmap

Snapping what to what? Nodes to the GridMap's cells?

easier to understand grid properties in Editor Setting

Seems unrelated to GridMap, how would this help?

fixing moving/duplicating a set of tiles in Gridmap

I think you linked the wrong url.

fix: selection rotation when working centerX, centerY, centerZ are True

This seems to happen only if Paste Selects is True.

allow to rotate selected cells

Do you mean "rotate Selected cells around themselves, without rotating the Selection"?

add flip/mirror horizontal/vertical

I think it would be better to add the ability to create and add flipped versions into the current MeshLibrary. The linked pull request suggests changing the cell's ...constructor(?). However, this would affect all cells, and not all cells need to be flipped. Performance impacts must be measured.

show colliders

Seems useful, but at the same time, not really? When is this information important within GridMap? Not all items have collision.

paint on top of used cells

I thought about this in my plugin. How would you do this? Check which cell is under the cursor, then paint on the cell's coordinate + Vector3.UP? What if there's a different cell on top of the cursor? What about painting a cell below or at the sides?

add tile blocks (or group of tiles)

Seems like a good idea. But I wonder, if you end up using a few cells to build several groups, workflow may not improve that much: you'll still need to select from several choices then paint blocks individually. Also, you may have to constantly switch between two different menus to pick what you want.

---

Thoughts about improvements:

• Reminder: currently GridMap has no dedicated contributor. This likely means that only trivial changes will end up being merged in a timely manner - bigger changes may be pushed to the future to not break compatibility. It is what it is.
  So, if you feel like making pull requests, set your expectations accordingly.
• MeshLibrary limitations:
  • This one liner should be removed: the GridMap menu's ItemList sorting.
    There is no reason for it to be like this. It changes the order of the MeshLibrary Items depending on their names, ignoring ID order. This can make different MeshLibraries be displayed in the same way, which is wrong. In the past (and present Godot 3.X), this causes a difference between which cell is selected in the ItemList and which cell is displayed by the cursor.
  • Make the menu remember what was the last selected item from the current GridMap. Not only it's an easy Quality of Life update, but it would fix an error that still occurs when you select a GridMap that has less items than the current one. This could be as simple as a MeshLibrary meta data entry.
  • MeshLibraries should have a better way to add and remove items.
  • Match how many bits MeshLibrary and GridMap accept.
  • When using the built-in functionality to generate MeshLibrary from a Scene:
    • Warn (somehow, somewhere) that Resources should be external.
    • Make it more flexible: #3821, #3406.
• GridMap limitations:

  • Make changing floors accept echo Input events. Currently, if you press and hold Q or E, it will apply only one floor change.
    Alternatively, add a functionality that centers all three plane levels to the cursor for quick changes.

  • improve paint/selection tool: select on xy, yz, xz plane

    Something changed between Godot 3 and 4. In 3, you can modify the extents of the Selection after creating it using Shift + Q/E. You can change the currently edited Plane and make the Selection grow/shrink in different directions. It's kinda weird, but it's something. If this is what you meant, then it's a matter of restoring/updating old behavior.

  • By far, the smallest change with biggest impact that GridMap can have is a signal or callback to get last edited cells.
    You mentioned several ideas that could be done via user-provided script if this information was available: paint on top of used cells, add tile blocks, add random tile fill/paint, clever fill tool, work with multiple MeshLibraries (by using a GridMap "manager" that signals to other GridMaps which cells should be modified), and possibly act as brush size and shape.
    It would also help with auto-tiling. Even this plugin mentions that the lack of information about last edited cells is a limitation. Note: that plugin doesn't work with Selections - so even plugins have trouble.

• Other changes:
  • Either make GridMap use the name of items instead of ID or provide a proper way to handle MeshLibrary refactoring.
  • About "show mesh origins": I can imagine it leading to either visual pollution if the proposed radius is too large or unhelpful pointers if it's too small. Also, I assume most items fit in one cell - you would add a whole new visualization mode just to check for a few big items.
    I think proper solutions to this require knowing the "actual occupied volume" of an item. I imagine this could be done if there were Collision Mask + Layer per MeshLibrary item instead of per GridMap AND the GridMap Editor could check for overlap before Painting/Erasing. Then, Erasing any cell of the bigger items would correctly erase them.
    Now, this wouldn't fix trying to erase a cell whose mesh has gaps by clicking on the coordinates of the gap... You would have to somehow define which neighboring coordinates around the origin are part of this cell, then make the Editor understand that.
  • About brush spacing: seems good but it's dependent on GridMap's cell Size and/or Scale. They can be changed in such a way that even if the spacing is respected, the meshes would still overlap. A more robust solution is to combine the mesh's AABB + cursor rotation to check for overlap. Works fine for Fill Selection, but has problems when Painting in self-intersecting manner.
  • A handy information that could also be made available along last edited cells is coordinates in the Selection. You could for instance write a plugin with custom actions to "Paint cells A and B with random rotation", or "replace items A with B" etc.

[Nodragem]

Thank you for this fantastic feedback!

I will try to digest your suggestions and edit my list of improvements accordingly later this week.

For some of my ideas, like "adding tile blocks" I will be making related proposals with pictures, so that it is easier to understand them.

Yes I intend to make PRs ! I am rather optimistic that a lot of trivial or uncontroversial changes can be made in combination to make the user experience better. Let's see how it goes.

[Nodragem]

As seen above, the Gridmap Editor bottom panel was officially merged yesterday, which opens the door to a lot of improvements to the gridmap!

However, I would like to open a discussion on the current shortcuts. I wonder if it would work better if the action tools are in the second rows of keys. Something like:

• F: Fill
• D: Duplicate and Move
• S: Cut and Move
• A: Delete

This way is it is very easy to use the fill tool (index finger moving), while juggling between tool mode (e.g. selection and pick).

[Nodragem]

@Hiiamwilliam I started to review your questions and suggestions.

Here for the questions.

absolute snapping + snapping relative to a Gridmap
Snapping what to what? Nodes to the GridMap's cells?

It would be to snap Node3D. The current "snap tool" simply moves Node3D by 1 units. If a Node3D is at location (0.2, 0, 0), and you move it up on the X axis, it will be moved to (1.2, 0, 0).

You can't snap Node3Ds to the 3D editor's grid or to a Gridmap's grid at the moment.

easier to understand grid properties in Editor Setting

Seems unrelated to GridMap, how would this help?

It becomes useful when the Snap tool can actually snap Node3Ds to the 3D Editor's grid.
If the 3D Editor's grid matches the units of your world, you will have an easier time to place Scene/Node3D objects.
Furthermore, it will be easier to combine Gridmaps if you can snap them on that common grid.

allow to rotate selected cells

Do you mean "rotate Selected cells around themselves, without rotating the Selection"?

Yes.

add flip/mirror horizontal/vertical

I think it would be better to add the ability to create and add flipped versions into the current MeshLibrary. The linked pull request suggests changing the cell's ...constructor(?). However, this would affect all cells, and not all cells need to be flipped. Performance impacts must be measured.

Here I am speaking about placing a mesh on the Gridmap. At the moment, we can rotate it, and I will add the ability to flip it. However, if you find that you use that variation a lot, the template/tile block feature I suggest elsewhere would do what you need (adding it as a "tile block"/"template" in the Gridmap palette).

paint on top of used cells

I thought about this in my plugin. How would you do this? Check which cell is under the cursor, then paint on the cell's coordinate + Vector3.UP? What if there's a different cell on top of the cursor? What about painting a cell below or at the sides?

yes pretty much how you say. The current code is already checking which cell is under the cursor, so it should be easy to implement.

I think it will already work pretty well with just adding on top of non-empty cubes, but if there is demand for it, we could detect which of the 6 faces of the cube the cursor is hovering. It would be more complicated to implement.

add tile blocks (or group of tiles)

Seems like a good idea. But I wonder, if you end up using a few cells to build several groups, workflow may not improve that much: you'll still need to select from several choices then paint blocks individually. Also, you may have to constantly switch between two different menus to pick what you want.

Let's say you build for instance a "healing shrine" location using walls, floor tiles, a statue and some curtains. That's something that will be re-used many times in your level. You would select it and save it as a template (or tile block). This template will then appear in the Gridmap's palette, as any other meshes. You won't need to switch between different menus, you can just paint it as a normal.

That feature should not be too difficult to implement as the Cut tools is already doing most of it!

Hope that helps. I will answer to your feature/fix suggestions in a second message.
Thank you very much for engaging in this discussion!

[geowarin]

Hats off to @Nodragem for the big improvements on the gridmap usability!

Here are other suggestions that came to mind when using the new interface:

• I'd like the picker tool to automatically switch to paint mode after picking a mesh
• I'd love the arrow keys (or maybe pgup/pgdown or j/k, if there are conflicts) to move to the next and previous mesh for total keyboard control 😄

On the subject of broader usability, I think GridMaps should take inspiration from the new TileMapLayers.
It is very frequent to have multiple GridMaps in the same scene for painting different layers like floor, wall, props, etc.

[Calinou]

I'd love the arrow keys (or maybe pgup/pgdown or j/k, if there are conflicts) to move to the next and previous mesh for total keyboard control 😄

Sometimes, I wonder if the arrow keys should be used to navigate the cursor in the 3D world instead, with Space placing the item on the grid at the current position. To select GridMap items, you'd use the 1-9 home row keys to enter the GridMap item ID (which would have to be shown clearly on each item). Combine this with the numpad-based camera controls and you won't have to touch the mouse quite as often as before.

This provides a workflow very similar to the Trackmania map editor, which has historically been very effective to use in a keyboard-only fashion for me.

[Nodragem]

I definitely think that the 1-9 keys could be use to select Gridmap items.

But for it to work well, we would need a favourite bar, where the user can place 9 items they will be using a lot for the level they are currently making. That bar could be a 9-column x 1-row grid at just on top of the Gridmap panel. The user would drag-and-drop items from the Gridmap's palette into that favourite bar.

Or, we could have 1-9 refering the first 9 items of the palette and we would have a system to reoder and pin items in the palette.

Probably worth its own proposal for further discussion. Please link the proposal to this one if you create one!

[Mickeon]

Adding to the list is two PRs that implement rendering/visual layers in a different way:

• Add rendering layer mask to GridMap godot#86992
• Preserve visual layer of meshes in GridMap nodes godot#94453

[Nodragem]

I start to think that most of the tools may need parameters, so I opened a proposal to add a tool settings panel in the Gridmap Editor:
#11206

[Nodragem]

Great news for people who make 3D levels in Godot:
godotengine/godot#96544

This was in my wishlist/todo list (in the first post). Combined with the default drag-and-drog behaviour (godotengine/godot#91874), it makes building levels much easier!

[andrispe]

Amazing work so far!

I have 2 feature requests I'd like to add to the proposal:

1. Ability to get from shape to cell position. This would be a really meaningful improvement to my current project where raycasting from camera a large object in the gridmap hits it in a way that it doesn't show that object's cell position, but a different cell's position. Meaning if hitting that cell means deleting it, for example, I could delete the wrong object.

2. Easier to work around, so less painful, but the ability for meshes to span multiple cells would be great. If an object is de facto 2x2x2, no other object should be able to fill that space (unless we're talking layer, etc).

[Calinou]

2. Easier to work around, so less painful, but the ability for meshes to span multiple cells would be great. If an object is de facto 2x2x2, no other object should be able to fill that space (unless we're talking layer, etc).

This would require each MeshLibrary item to declare the space it takes on the GridMap (with a Vector3i property that represents the number of cells on each axis).

For more fancy configurations, you'd want the region occupied by the item to have an arbitrary shape, not just cuboids, but this would be a lot more complex to define and implement.

[Nodragem]

1. Ability to get from shape to cell position. This would be a really meaningful improvement to my current project where raycasting from camera a large object in the gridmap hits it in a way that it doesn't show that object's cell position, but a different cell's position. Meaning if hitting that cell means deleting it, for example, I could delete the wrong object.

Do you mean when you use the mesh picker tool?

[kilojool]

A feature that I really would like is to be able to use different collision layers per shape in the same tile.
Shouldn't be too difficult to implement in code, but a good UI for it may be difficult to design.

[andris1]

1. Ability to get from shape to cell position. This would be a really meaningful improvement to my current project where raycasting from camera a large object in the gridmap hits it in a way that it doesn't show that object's cell position, but a different cell's position. Meaning if hitting that cell means deleting it, for example, I could delete the wrong object.

Do you mean when you use the mesh picker tool?

When raycasting I get a shaped id, but not the cell position. I want the cell position that shape belongs to.

Sometimes a shape spans multiple cells. So when raycasting, going through where on the gridmap the raycast landed does not guarantee the shape's cell position.