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 Generate thumbnails on imported scenes. godot#96544
• 👷 hide big gizmo in selection mode (to easily select small objects in levels) Add a setting to disable Select Mode manipulator gizmo #7834 (comment) and Rename Select Mode to Transform Mode, and create a new Select Mode without transform gizmo godot#101168
• absolute snapping
• snapping relative to a Gridmap
• 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
• custom color of grid Add an editor setting for the GridMap grid color godot#101101
• 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: Update gridmap editor nodes when the gridmap node transform changes godot#99393
• 👷‍♂fix: selection tool not aligned with cells when when working centerX, centerY, centerZ are falsed and half-size grid: Selection Cube in Gridmap not selecting correctly in some workflows godot#101398
• 👷‍♂fix: the cursor preview is not updated when moving/scaling, rotating the gridmap see: Update gridmap editor nodes when the gridmap node transform changes godot#99393
• 👷‍♂fix: jump to current mouse position and using cut and duplicate in Gridmap: Gridmap Duplicate/Move tool: Cursor is jumping to a new position godot#101428
• 👷‍♂ fix: when pressing undo during a cut, the cut still exists: Gridmap Moving/Duplicating tool: Undo does not cancel the operation correctly godot#101430
• gridmap editor settings's size of previews does not update immediately Editor Settings: Gridmap Preview Size not being updated godot#101432
• 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 and Make Gridmap paint tile preview visible when overlapping with current tiles #11537
• 🚀 hide current tiles under the preview when moving selection (duplicating and move operations)
• 🚀 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.

[Nodragem]

For reference:
godotengine/godot#101101
godotengine/godot#101103

I think we definetely need the cursor preview's opacity to be in the settings as it is up to the user's preference.

Also, I think we definitely need to get this one done:
godotengine/godot#5526
#11537

[Nodragem]

I update the todo-list above with the most recent contributions I've seen, I also marked some of the task as:

• 👷 being worked on by someone
• 👷‍♂ the ones I will be working on in the next 2 weeks (please let me know if you were planning to work on one of them!)
• 🚀 the ones I will be working on later on

Mainly, I am prioritising bug fixes for now and small improvements.

[jamesmintram]

Started a WIP branch For: multi selection in palette (which will allow for random paint/fill)
Here: https://github.com/godotengine/godot/pull/101942/files

[jamesmintram]

allow multiple tiles to be selected in the palette, and allow to set probability by tile

I have had a thought about a very simple way to implement this (it would stack nicely onto godotengine/godot#101942 )

UX wise I thought something like:

Holding ALT+Left Clicking a tile will increment a counter associated with it (this counter displayed on the tile)
Holding ALT+Right Clicking will decrement the counter

Then you end up with a selection of tiles + weights which will be used when painting/filling.

Could be a low effort/high reward kind of thing.

Following on from that a more sophisticated system could be developed to:

add random tile preset: possibly to save a selection of tiles and probabilities as a preset.

[Nodragem]

yes, we are on the same wavelength, I was thinking about low effort/high reward features when writting this list.

However, I would avoid as much as possible to hide features behind modifier keys. I was thinking about adding a percentage and little arrows on tiles that are selected in the pallette. But it might also mean that the multi-selection is done with little checkboxes (as in Android or iPad when multi selecting files) to avoid deselecting by accident. Probably need a "deselect all" and "select all" button as well.

Note: one feature I want to add is a "tool settings panel" on the left of the Gridmap bottom panel, to set the brush size, shape, etc. We could use it for randomisation tool settings too?

Edit: probably need to update the "list view" to be better organised, or delete it, if we want to display the probabilty directly on the tiles.

[Grandro]

Thanks a lot for opening and maintaining this proposal and for your contributions!
As someone who has also struggled with the GridMap for a longer time now, I would like to add some additional thoughts/ideas to this conversation:

The thing that hinders my workflow the most is selecting the right mesh from the GridMap UI. As soon as you have a few meshes that look fairly similar you either have to have very descriptive names for them (which is pretty difficult if you have many meshes) or inspect the meshes somewhere else in order to tell them apart. Extra difficulty is added because the preview does not consider the rotation of the meshes godotengine/godot#76643 (but I think this is even true for the whole transform).
So what I do all the time is open the scene I use to generate the MeshLibrary and select the mesh I want to place, copy the name and paste it into the search bar of the GridMap:

After some time I can also copy-paste already placed meshes, but the controls to do that are a little awkward right now and after you paste a mesh the GridMap always looses focus (I did not see this happening in godotengine/godot#96922). Additionally, I want to mention that the GridMap search bar content is always reset after you change the scene tab, so you have to be sure what you are searching for.

This work"flow" brought me to the idea, if it wouldn't be smart to link the scene you use to generate the MeshLibrary closer to the items of the generated MeshLibrary. Losing the power of being able to visually and spatially tell which mesh you want to place is a huge loss. I am not familiar with the technical limitations/difficulties of generating a MeshLibrary, but it would be great to not have a MeshLibrary item be referenced by an ID or Name but by its global position within the scene you generate the library from (for example). There could then be an extra Viewport within the GridMap UI where you can freely roam with your camera and just click on the mesh you want to place. The GridMap would then find the link between the clicked mesh in the scene and the MeshLibrary item it corresponds to.

This could either be an additional tab in the GridMap UI or replace the icon/name based selection.

Please let me know what you think about that idea. I can also open a new proposal if it is feasible to implement.

[Nodragem]

Hello! thank you for giving your feedback, it is always nice to learn how people are using the gridmap.

After some time I can also copy-paste already placed meshes, but the controls to do that are a little awkward right now and after you paste a mesh the GridMap always looses focus (I did not see this happening in godotengine/godot#96922).

Did you try the 4.4beta1? now the Gridmap is not loosing focus after a copy-pasting. Use X to move, C to duplicate.

Also, in 4.4beta1, you can pick/sample an existing tile in the gridmap with the tile picker using R.

The GridMap would then find the link between the clicked mesh in the scene and the MeshLibrary item it corresponds to. This could either be an additional tab in the GridMap UI or replace the icon/name based selection.

Concerning showing the meshlibrary scene next to the gridmap scene, it would require a lot of changes. We are trying to focus on small changes that would make a great difference first.

I think your problem might be solvable by adding labels/tags to the gridmap, and improving the search feature (e.g. fixing the search that resets), and maybe improving the list view so that we see the full name of tiles.

This being said, naming convention is a very important part of working with 3D tilesets, so that they are easy to filter out. You can find how the team behind Skyrim organised their naming convention here and compare it with yours: http://blog.joelburgess.com/2013/04/skyrims-modular-level-design-gdc-2013.html

It is probably too late for you to change your approach, but in 3D it is simpler not to use tiles because they are way too many combinations. Developers often use a modular asset approach (e.g. walls, corners, floors, ceiling) as explained here: https://www.youtube.com/watch?v=QBAM27YbKZg. The idea is that you can recreate any tile using wall, corner, floor, ceiling assets.

[Nodragem]

Note for later, the gridmap search seems to be doing a fuzzy search, which might not be ideal to filter tiles based on a naming convention:

[Grandro]

Thank you for you answer and the insightful resources. I have watched the talk and read the blog post.

Did you try the 4.4beta1? now the Gridmap is not loosing focus after a copy-pasting. Use X to move, C to duplicate.

Yes, I think the changes in 4.4beta1 improved the usability of the GridMap a lot. In my earlier comment I meant to say that I did not encounter the issues I mentioned in the new version that I encounter in the current stable release, but I still wanted to mention them because they are part of my current workflow.

Concerning showing the meshlibrary scene next to the gridmap scene, it would require a lot of changes. We are trying to focus on small changes that would make a great difference first.

Yes, I did imagine that. Maybe I am also not entirely clear about what the goals of the GridMap node are. The resources you shared suggest to have a good naming convention, but I believe no matter how good your naming convention is, finding the right mesh(es) will still pose a significant difficulty. An example of a name for a mesh they used was UtlBayCorInMidPRTT01L01: Analyzing a string of that length for each mesh, even if you are very familiar with the naming convention, is exhausting and time consuming. The string also takes up a lot of space so the formatting when displaying it adds extra difficulty. They said they implemented the feature to be able to use the mouse to scroll through similar meshes while placing them to alleviate this issue.

I think I understand better now why not using a GridMap might be the right choice for me. Having this modular power to stick together meshes to create Prefabs seems very lucrative and is definetely not the purpose the GridMap wants to serve (currently). But still, I think if there is a node that could manage meshes in a visually pleasing way, it is the GridMap. Otherwise you would have to build this mapping system that uses scenes as prefabs that you can place directly into the editor within an additional tab maybe. But if this existed, it would have to have very similar features to the GridMap. This would introduce redundancy and I just feel like these two approaches could be combined. Currently, there basically is not any workflow to 3D mapping if you don't use the GridMap. I understand that this is way out of scope, but I think it should be considered for changes in the future.

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

Here's an image with the situation.

The box is an object with collision shape belonging to position 1, but raycasting you get gridmap position 2.

[Nodragem]

They said they implemented the feature to be able to use the mouse to scroll through similar meshes while placing them to alleviate this issue.

That sounds great! to add a shortcut to go to the next/previous mesh sounds like an easy quality of life feature to implement!

Otherwise you would have to build this mapping system that uses scenes as prefabs that you can place directly into the editor within an additional tab maybe.

I would say that the scope of the Gridmap is to put together repetitive, static meshes on a grid while using multimesh instances behind the scene to boost performance. Multimesh instances allow to render the same mesh multiple times at low cost.

For level design, Gridmap has definitely its use case for anything static and on-grid. But as soon as I start using dynamic objects (scene with scripts), I find it better to use the 3D editor. I need to see these objects in the Outliner, and in the Inspector so I can modify their settings (e.g. a trapped tile with a timer).

Level design in Godot can be largely improved, but my belief is that it will be about getting the 3D editor better integrated with the Gridmap (e.g. snap tools that snap to a gridmap's grid, rotate by 90 degrees with ASD), and getting better filtering options in the FileSystem (e.g. tags). Note that we now have thumbnail previews of 3D asset in the FileSystem (in 4.4 beta1), which really improve the Level Design workflow.

[Hiiamwilliam]

As soon as you have a few meshes that look fairly similar you either have to have very descriptive names for them (which is pretty difficult if you have many meshes) or inspect the meshes somewhere else in order to tell them apart

From this description and the picture you provided, I believe your situation would benefit greatly from autotiling. It should decrease the need to search for the correct item by a lot, since the system would choose the correct mesh according to the rules you setup.

Or, perhaps some logic of the Inspector Dock could be replicated in the GridMap menu? When you select a MeshInstance and edit its Mesh, the Inspector shows an area where you can rotate said Mesh. This could help with identification.

---

Regardless of autotiling, I agree. Once you have a lot of items, repeatedly filtering for the correct one, especially if you're using comprehensible names, will still feel like bad workflow.

I suppose adding a Tree (with collapsible items) would help organize items. So, as an example using the image you provided, you (or the MeshLib creation process) could create "Wall_1_Main_Top", "Wall_1_Single_Down" etc..
Selecting that group would only show the items under that group. It's essentially a shortcut to Filtering, but without using the Filter - so you could select a group and still use the Filter to find an item that belongs to this group.
This could replace one of the two methods of showcasing items, the "bullet point list" way. Its icon already looks like a list of sorts.

One of the tasks on this proposal is "select mesh with keyboard (1-9, favorite bar)". I think the 1-9 hotkeys should, instead, select a group. I feel this is more powerful than having the shortcuts select a single item.
With groups, you could also have new hotkeys to quickly change between items of the same group. Without groups you would end up changing to a floor piece when you want wall pieces etc..

[Calinou]

One of the tasks on this proposal is "select mesh with keyboard (1-9, favorite bar)". I think the 1-9 hotkeys should, instead, select a group. I feel this is more powerful than having the shortcuts select a single item.

The way it works in Trackmania is that the number row keys select a category of blocks when pressed once, then you press it again to select the actual block you want to place.

It was presented differently in older games, but the idea is similar:

Pressing 2 would net you:

Then pressing 1 would result in:

Also of note is that you get a real-time rotating preview of the currently selected block (not a pre-rendered image):

tmnf_preview.mp4