Remove GridMap from core

[fire]

Describe the project you are working on

Social VR game https://github.com/v-sekai

Describe the problem or limitation you are having in your project

Everyone I talk to that's experienced in 3d doesn't use the gridmap tool for 3d maps. They've either written a terrain system like zylann or modelled the world.

https://github.com/Zylann/godot_voxel

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

https://docs.godotengine.org/en/latest/tutorials/3d/using_gridmaps.html

Remove gridmap.

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

Delete the gridmap module from Godot Engine 4.0

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

It cannot be worked around with a mere few lines.

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

Gridmap is underused and should be an addon.

[WolfgangSenff]

Considering the functionality of GridMap editor (does it even exist really?!) is now extraordinarily subpar compared to the 2D TileMap editor, I really think this is a good idea. Switching it to an extension or addon would not be hard, imo, as well.

[Calinou]

I don't think GridMap should be removed – it still serves its purpose for tile-based level designs. Games with easy-to-use level editors often revolve around tile-based level design, with Trackmania probably being one of the best examples. Not to mention most 3D dungeon crawlers, or games with top-down views in general.

Removing GridMap from core will also pose an issue for people upgrading from 3.x, especially if no stable add-on is provided in time for 4.0's release.

Improving GridMap is a separate topic, much like what happened to TileMap in 4.0. This is entirely possible, but it requires finding motivated contributors.

[fire]

We say it serves the purpose, but the people I polled did not see it fit for tile-based level designs.

[KoBeWi]

Games with easy-to-use level editors often revolve around tile-based level design, with Trackmania probably being one of the best examples.

Trackmania supports CSG-like autotiles. The problem with Godot's GridMap is that you are supposed to model the level using quads, which is very cumbersome. It's not optimized for cube-based tiles; when you place a cube, all faces are rendered. Improving that would be enough to make it usable, but so far GridMap might end up being another VisualScript (i.e. not serving it's purpose well and not maintained).

[Mickeon]

To my dismay, I have to say GridMap is in need of so many improvements, yet no one is up to the task of maintaining it. As weird as it may sound, I wouldn't remove it solely for being part of Godot for so long. But, if it can be replicated exactly as it is, maybe even better as an extension, so be it, perhaps...

[TheDuriel]

Trackmania

Ignoring the fact that they use curves and csg, no you really can't make anything close to that using GridMap. Nor could you make something like roads in SimCity, another case where from the outset "3d tilemaps" sounds like it should work. Honestly, the old gridmap demo / 3d platformer demo kind of shows the extents of what is possible to accomplish here.

I struggle to find any reasonable application for GridMaps. MeshInstances perform better since culling works properly (sure that could be fixed), and the editor already has a grid snapping feature for easy placement.

As it stands, if I want a way to build levels of plain mesh instances, blender and the base godot 3d editor serve me better. If I want something editable at runtime, I need to write my own logic anyways. GridMap in comparison are cumbersome and don't provide any of the features I would be looking for.

If GridMap was simply a means of instancing Scenes in a grid. Then it would become useful to me. As it could then be used as tool for level creation past basic geometry.

Currently https://www.youtube.com/watch?v=r6NZPGLydG0 this can not be made with GridMap, even though on the outset it feels like it should be the correct tool for it. "Build levels with a Grid."

[dmaz]

Currently https://www.youtube.com/watch?v=r6NZPGLydG0 this can not be made with GridMap, even though on the outset it feels like it should be the correct tool for it. "Build levels with a Grid."

wait, why can't that be built with gridmap?

[TheDuriel]

The video doesn't really show all the fancy stuff, but regardless. Imagine collapsible blocks, spike traps, low gravity, the powerups. Effectively everything is a grid unit, the face or whole of a cube. Sounds like a good fit for a GridMap right?

And yeah, you could build the base geometry, the solid platforms. You couldn't place the spikes, or in later levels the ice or low gravity tiles. Because you can't do logic.

So at that point you would be instancing most of these things in the editor yourself anyways (or their faces), and enabling grid snapping to make it so. At which point, why bother with a GridMap. What does it have to offer?

[dmaz]

exactly though... the main editor is what you should be using for all those non static parts. though having a quick add, editable list for scenes would be a nice addition. but the whole point of gridmap is just the optimizations for static meshes that it brings.

[huttyblue]

Please do not remove the gridmap node. They are useful for a variety of things, especially in the prototyping phase. While they can't contain logic you can do logic with them by querying tile IDs based on your current coordinates.

I'm actively using gridmaps in my current project. (initially 2D ported to 3D because 1 gridmap has better performance than the 3 tilemaps it replaced in godot3) https://i.imgur.com/Kr9DKkZ.png

Ignoring the fact that they use curves and csg

I'm going to need a source on this, I've put hundreds of hours into trackmania sunrise, canyon, and lagoon and never saw anything close to csg or dynamic curves in its editor. All curved track parts are large pre-made blocks that could be achieved by using a gridmap.

I don't think gridmaps are perfect but they shouldn't be removed.

[TheDuriel]

but the whole point of gridmap is just the optimizations for static meshes that it brings.

It doesn't bring any though. And even then. If you are building a static environment, building it in blender and merging all the tiles at their seams would be drastically more performant.

[dmaz]

sure it does. and just to make sure I just tested 10,000 1x1x1 boxes. instance: 204 fps gridmap: 866 fps and blender is no good for procedural levels

[TheDuriel]

Now consider that a use case where every entry in the GridMap is identical is rather unlikely. And that we also have MultiMesh.

[huttyblue]

Gridmap batches in chunks which is a pain to do manually in blender. Its way faster in practice than spamming mesh instances, even if the gridmap tiles aren't the same. The only thing faster in the same category is Zylann's voxel plugin. (which isn't a direct replacement for all gridmap use-cases, and also isn't built in by default)

[dmaz]

well it was a collection of 3 different mesh blocks with different materials. though I added an (unfair) capsule as a third of all the blocks and gridmap fps dropped to around the same as the instanced fps

[HeadClot]

I do not think grid map should be removed.

[tastesliketriangle]

They've either written a terrain system like zylann or modelled the world.

Gridmap isn't designed for either of those use-cases though.

Gridmap is underused

That may be the case. I would say that's primarily due to the fact that grid maps are missing the polish other parts of the engine has. The editor tool is basic and the API has sparse documentation.

The way I see it Gridmap is best for pre-authored, non-organic levels. Building cities out of blocks and similar.

I Don't think Multimesh is a replacement since you can't set it up in editor. If you want to hand author a level you're back to re-implementing gridsnap and editor tooling

[TheDuriel]

Grid snapping is already implemented. And you can work fairly efficiently "painting" instances with ctrl+d and drag and drop from the file dock. What you don't get, is a fancy preview.

But that brings us back to the proposal itself:

Remove GridMap. It is rarely if ever used and does not have the tooling require to make it useful. Then leave it to those that need it to reimplement it in a better form as a module.

So that when it is desired, it can be a useful tool. And otherwise doesn't take up engine development resources.

[Zireael07]

To me, GridMap is in the same spot Visual Scripting was - poorly usable (as someone mentioned, SimCity-like city builder sounds like a fit... but no you can't do it), with missing features, bugs going unfixed for years (fiddling with octants to get passable performance, having suuucky performance in Bullet physics) and with mesh merging in 3.5, I honestly struggle to see why anyone would use it beyond some testing (but for that, you can use CSG, or just meshes)

Since VS was booted to a module, GridMap should go too.

[smix8]

Short answer: Can it be improved? Yes. Should it be removed? No.

I use GridMap quite extensively for what it is supposed to do. If it is marketed as the equivalent to the 2D TileMap or as a "terrain builder" that is a marketing problem, not a GridMap problem.

The GridMaps main design was to solve the poor update performance of having many individual nodes for MeshInstance visuals or StaticBody collision or Navigation navmeshes cluttering the SceneTree and eating performance and memory just by existing in such large quantity. It does what it was designed for by updating in bulk and using the server api directly / multimesh to keep the SceneTree clean.

Node or script logic was never part of that GridMap design consideration and also merging cells that are set to small for good performance is also not part of the GridMap job (for now, I consider this as one of the first improvments that should be made, especially for navigation). 2D TileMap also does not merge half its stuff for performance but can get away with more stupid before performance becomes a problem because 2D.

All the other stuff is asking for new features (that could be done), go against the current design of keeping the SceneTree clean (adding node logic), or barking self-inflicted project problems due to a lack of knowledge how to optimize 3D games at the wrong tree.

I also had the recent pleasure of spending some time with both TileMap and GridMap codebase to fix navigation bugs in both and I can say that GridMap is in a far better manageable and maintainable state than TileMap and we are not discussing removing TileMap, are we? Removing GridMap from core would mean that it would no longer receive the important changes and fixes automatically to have always a stable base to improve on. I know I would have never fixed navigation in GridMap or added support for the newer navigation features if it would be one of those left-to-die "official addons".

[KoBeWi]

I can say that GridMap is in a far better manageable and maintainable state than TileMap and we are not discussing removing TileMap, are we?

TileMap was completely rewritten in 4.0. The maintainability issues you mention just come from the fact that it's far more complex. Also it has a maintainer and actively gets fixes/enhancements from multiple contributors, while GridMap is basically dead.

[Xananax]

I'd like to first go meta a bit and rant about something that has been bugging me for years.

"I don't use" or "I don't think people use" is not an argument. It's a poo flinging contest.

"feature is incomplete" is similarly not an argument.

I expand on this in discussions to not deviate the conversation here: https://github.com/godotengine/godot-proposals/discussions/5564

---

Since we're here though, and the conversation is reduced to who yells loudest, I'll add my pebble.

I've used gridmap in every single 3D project I've worked on, both personally and as a contractor for professional, ambitious projects.

I completely do intend to use it in every future 3D project too, exclusively.

I also completely do intend to use it in every isometric 2D game that requires multiple levels, because it is:

1. vastly easier to use than multiple 2D tilemaps
2. easier to write shaders to show units behind elements
3. vastly easier than using planes and ctrl-place them

I completely do not intend to use terrain, Blender, or Trenchbroom, because I do not intend to do level design outside of Godot (iterations are too slow).

I also do not intend to build my own system (a waste of time), and gridmaps fulfill precisely all my needs. I see no better way to prototype a level.

---

To be clear about my intent: I do not care overmuch about this feature, in the sense that it being relegated to a plugin is fine. If it stops existing, I will build my own system, that is also fine.

I am attempting to demonstrate the absurdity of "I use it/I don't".

Rather than answer my points, I'd be glad if the absurdity of the premise of this proposal (and others like it) is recognized and it gets closed. There is no discussion to be had here.

Arguments for removing or not gridmaps may exist, but they are not in appeals of authority "I asked the professionalissers people and they agree with me".

I do not pretend my experience is more valid than other people that don't use gridmaps, rather, I claim that all of these arguments are null and comparable to recess squabbles.

There have been 0 arguments made in this issue until now, including mine. Please close it.

If not, then please do not think what I said was a lie. I do completely depend on gridmap and have in every single 3D project I've participated in or initiated.

[TheDuriel]

Argument:

There are 85 open issues that relate to or mention GridMap. Sure, there's probably at most 20 that are actually still relevant and proper issues, but still.

Who is handling these? Nobody? In that case GridMap will not only remain as it is, but actively lose functionality in 4.x as it isn't being updated.

One issue dates back to 2018, with a confirmed problem that was pushed because it didn't make the 3.0 feature cut. Well it didn't make 4.0 either.

[Xananax]

That is a fine argument that can be answered, thank you.

My answer is that no matter the amount of issues, gridmaps are usable for the intended purpose today.

For example, for an RPG I developed for a client, we tried hard to use 2D tilemaps and had to revert to 3D tilemaps after weeks of RnD.

Our use case wouldn't be covered well with meshes, because we require procgen for which tiles are advantageous, and 2D tiles required an enormous overhead in pipelining assets from Blender in multiple angles and configuration (as well as much more weight in the final export, which isn't great for mobile).

There were a few issues, but no more than with other features of Godot, and we worked around them easily. Implementing a 3D grid-based system was a matter of a few hours (to convert our movement from Vector2s to Vector3s).

Performance was also better than with 2D.

What I'm attempting to illustrate is that a feature not working completely doesn't sound like a good enough reason to axe it.

If I need to unscrew a screw and all you give me is a knife, it's drastically less useful than a screwdriver, but infinity better than nothing.

[KoBeWi]

tbh VisualScript was axed, because it was created on a wrong basis, so "fixing" it would require a complete rewrite (and there was no clear idea how it should be rewritten and who would do it). There were also constant complains that it doesn't serve its purpose well (with multiple issues opened about it).

GridMap isn't really in such a bad state. It's usable, it doesn't have major fundamental problems and this proposal so far spawned far more opposition than removal of VisualScript as a whole.

[TheDuriel]

and this proposal so far spawned far more opposition than removal of VisualScript as a whole.

People who do not use a feature, are in my experience, much less likely to speak up about it. It's not on their radar.

Using the number of "I don't use it (because x)" isn't useful. Neither is the opposite. Someone happy with the current state of GridMaps is unlikely to search for issues/proposals regarding them.

So far literally every feature removal request I am aware of has gotten more votes against it than for. That's how these work.

[Xananax]

The removal of visual script was an impossible fiasco of epic proportions. This incredible debacle is precisely why I am speaking this time. I regret not having last time.

The removal of VS generated no opposition because people literally did not know about the feature being axed. Of the people in the visual script room on Discord, exactly none had any wind of this before it happened.

A ton of people who use Visual Script and do complain about it, but still use it and depend on it were literally not consulted, at all.

Read this again: out of all the people who use something, none had the occasion to speak about it.

Instead, the users that were polled were people who use Github or follow Reduz on Twitter. It's like asking a pool of guitar players if they think we should have pianos.

"An enormous failure of due process" fails to describe the immeasurable extent to which that was badly done.

Thinking votes for or against a feature matter in any way is a mistake. Lack of opposition of people who are users and not contributors means nothing else than: you're not asking the right people. Lack of opposition should be seen as a cue that something is wrong. It makes no sense that the removal of any feature, in an engine used by hundreds of thousands, wouldn't generate very strong opposition.

Neither votes for, or against, constitutes any indication of anything useful.

Further: votes against a feature should be counted much less than positive ones. If out of 20 people who use stairs, one is too weak and requires the elevator, then that person's vote should supersede all negative votes.

In other words: the votes of people who don't use a feature cannot be counted. They are null.

Again, I do not care about this particular feature so much. I am luckily good enough to reimplement this feature for my own usage.

I am using this as an example to hopefully stop this train of thinking altogether. It is flawed.

The majority of people who would use this feature are simultaneously:

1. not able to and unlikely to ever hear about this thread
2. unlikely to feel entitled to participate in it
3. unlikely to be able to make a cogent point that would oppose sufficiently the extremely assertive tone of contributors

[Ertain]

I think GridMaps should stay in the engine, as it really comes in handy for laying out 3D objects and quickly building scenes. I've used it in many of my projects, and I would be sad to see it go.

[noidexe]

@fire your issue doesn't comply with the proposal guidelines. You don't explain in what way the existence of GridMaps constitute a problem or limitation to develop v-sekai nor how removing them helps you overcome that.

I think this should be closed. There are other channels for this kind of discussion and in any case "I asked around and no one seems to use it" is just anecdotal, unlike the case with visual scripting where there was a user survey with actual data (edit: and as it was started above, even then and with a much higher N there is a risk of bias)

[fire]

It doesn't affect my project, as I said at the start, my project doesn't use gridmaps.

My peers who are game developers are unable to use GridMap for its stated purposes. Like the people who spoke up here.

GridMap is not essential for them or our project. I mean like literally we can uniliterally remove gridmap from our system at low cost. It's like a 5-10 minute patch to our branch of the engine.

I'm ok to close because I think this nudge has served its purpose, but it doesn't serve Godot Engine's best interests to stop discussion for something that is broken and needs mending.

Secondly, part of my responsibility is to bring to attention diverse opinions of people that have already left Godot Engine because of flaws and won't personally engage directly. (I am taking on personal risk, heat and attention for this.)

Also as @Xananax said the Visual Script removal decision was flawed.

[SilencedPerson]

The only real appeal the GridMaps have to me is the ease of use when placing the nodes but even that is rendered pointless by the uselessness of the rest of the node. I would say, remove the node and keep the GridMap tooling.

[golddotasksquestions]

Gridmaps need to be improved, not removed!

Imho we should strive to have as much workflow and feature parity to TileMaps as possible. I have used them ever since I started using 3D part of Godot. Imho they are a just as important for 3D as TileMaps in 2D and I have been waiting for improvements for years.

[Hiiamwilliam]

People who use other tools to create terrain will also need extra logic on top to properly create a level, why would this be a downside against GridMap? Also, as @huttyblue pointed out, you can set cells in editor in a specific position with specific IDs that you can use as a spawn point for any Node. The visual feedback and ease of use to position objects in 3D shouldn't be dismissed.

I'd like to point out there are recent Pull Requests people have made to improve GridMap, such as this one or this one, but no one reviewed them yet. Removing something wonky that really receives no attention is understandable, but removing something that people have shown the work to make better but there's no one reviewing doesn't seem ideal.

This reminded me of PRs that tried to add a signal that would be fired when a cell was changed. It's the kind of thing that would make GridMaps more powerful and better to use as a level editor, but none were accepted (example). So what I'm saying is that there are people who do use GridMap and do want it improved. If GridMap isn't great it's not for complete lack of trying.

[nion-ne]

I believe there's a very strong case for a simple to use 3D map editor core to Godot, it seems whether GridMaps fulfils that role greatly depends on how complex one's needs are.

Ideally it would provide new and inexperienced users have an easy answer to "how do I construct 3D levels". Without going through a very manual process of dragging and dropping scene files from a list and manipulating meshes in editor. There's value in having a simple and easy "tutorial" answer to these use cases for new users.

But if GridMaps are to stay without being further improved it should be made into something low-maintenance that can be easily extended for additional functionality as a flexible foundation for those interested in an efficient/scalable workflow.

However if they are to be removed I would hope some editor workflow improvements for placing geometry would take its place.

[JohanAR]

Of course GridMaps are useful, and some people depend on them, but that on its own does not justify it remaining a core feature. There are lots of things that would be useful to a lot of people but aren't built into the code Godot engine, for example a height map terrain system (i.e. what Zylann has developed as a plugin) and character controllers (available as many different plugins). Of course it would be best for the end users if everything was included in the engine so nobody had to deal with plugins, but in reality the Godot team has limited resources, and the more features they have to maintain the slower development will be in general.

I have yet to see one compelling argument for why GridMap needs to be a core feature, and would not work equally well as an addon. So far it has only been people saying "I use it", which is just as anecdotal as OP's argument btw. Why couldn't you continue to use it as an addon?

[MoltenCoffee]

I feel like the GridMap feature is not a flaw in itself and I wouldn't even call it a flawed system, just one that has seen few improvements after its conception. Where TileMaps are ubiquitous in 2D development, GridMaps are less so in the 3D space. In part, I believe this is because Godot in general has been known as a 2D engine. With the major improvements in this area with Godot 4, I hope to see more 3D development and assume GridMap will be a safe starting place for newer developers.

Reading the previous comments, I broadly identify two groups:

• experienced developers that don't fear diving deep into low(er) level code, perfectly able to build a grid-like system with lower level systems; They seem to prefer polishing and extending these lower level systems.
• less experienced developers or those more focussed on quick iteration for smaller hobby or indie projects; They seem to prefer easy access to systems that help avoid writing more complicated code just to get something on the screen.

Both groups and their interests are perfectly valid if you ask me, and it shows what I believe Godot has been struggling with for some time: the balance between being a professional and an accessible engine; A balance that I believe Godot generally manages to strike quite well, even though the experienced developers are definitely better represented in the discussions about engine internals. The recent removal of visual scripting was a definite win for the first, but I feel keeping a system like GridMap would be an important factor for the latter.

Of course, it could be an addon, but I feel that argument is a bit of a slippery slope: everything could be. Hiding accessible features for newer developers behind plugins, addons or extensions doesn't help experienced developers at all, but does make it harder for newer developers to get familiar with the systems, improve their skills and grow the community. I feel like that would hurt the community in the long run.

Where exactly the line should be drawn is, of course, up for debate. My opnion here would be to keep this feature in.

[gaudecker]

I think gridmap would be much more usable, if instead of a mesh library you would have a scene library. The gridmap would then find the mesh(es) from the tile scenes and merge them.

Pros:

• Allow logic on the tiles
• Skip the scene-to-meshlib conversion (which I found to be painful and easily broken)

Cons:

• Someone would have to write and maintain it which seems to be the main problem

I really tried to use gridmap, but quickly realised it creates more problems than it solves.

[Mickeon]

I want to note, this Proposal alone has become the most disliked Proposal of this repository, in record time, too.

So far, for how controversial this proposal has been, I wouldn't demote GridMap as an extension, for that sole reason. But, it would be unfair to NOT acknowledge that GridMap is, comparatively, in a poor state right now, and that the overall belief of the users in favour of this proposal is that what GridMap currently achieves can be achieved even better with either a change of thinking, or one or more extensions.

[vpellen]

I think the issue with Gridmaps is twofold: One, they don't solve a common problem, and two, for the problem they do solve, they don't solve it elegantly.

World design in 3D is rarely done through cleanly delineated tiles. For games with static geometry, the most common systems involve heightmaps and just jamming geometry together. For more dynamic and procedural systems, you get into the realm of voxels and marching cubes. There are times when a grid-based "3D Tilemap" system is used, but while the workflow of 2D tilemaps is fairly well established (grids, autotiles, layers, etc), there's no really common 3D equivalent. Gridmaps feel like a naive attempt at solving a poorly defined problem. Do they work? For some people, undoubtedly.

The issue with not wanting to disrupt peoples' existing workflows is that there will always be people who use any given feature in their workflows. You can not remove or sideline something without breaking something for someone.

The question, then, is not "Are gridmaps useful?", but rather "What do we gain from removing them, and is that gain greater than the inconvenience its removal would cause?"

[dodgyville]

Could TileMaps and GridMaps share a code base so that their features and usability are kept in sync? Initially Gridmaps could be removed but extending Tilemaps to 3D could be the roadmap

[Frontrider]

Probably not the best iteration of this, and I also don't wish to self promote here, but I'd like to know how many people can use this instead of a gridmap. Use the master branch instead of the version in the asset lib, it was not accepted yet. https://github.com/Frontrider/Godot-Scene-Browser

Use it together with snappy (addon link included in the readme), then this works with the "use scenes instead of a mesh library" idea.

This solution was not intended to be a replacement for gridmaps. I was building an "assetforge like" workflow, because it was soo easy to use that to make levels. THAT is the underlying problem that gridmaps were trying to solve, or at least that is the problem we tried to solve with gridmaps.

The only optimization this needs, is internal mesh batching, to deprecate multimesh instances.

[wareya]

Extending gridmap to support, basically, mesh library painting, as if it were a more level-designer-friendly multimesh instance, would go a long way to making it more useful, even if you did the bare minimum of just allowing it to place arbitrary meshes from the library at arbitrary points in space, and relied on plugins to do the heavy lifting of integrating it properly with the editor (i.e. even if things like foliage spray tools were plugins that merely told the gridmap what to do). It would stop reflecting its name, but it would become more useful.

[2plus2makes5]

In my opinion a game engine should provide some features no matter how used they are and terrain/level design is one of those features. Godot wouldn't be as beloved if 2d didn't have the tilemap editor, 3d needs morelevel/map editing tools, not less.

[PoisonousGame]

It works as a plugin no problem. Unfortunately godot doesn't have an asset store like unity, where alternative and better functioning plugins can be found. Not everyone is willing to provide plugins for free. So you can only expect others to develop it or develop it yourself or switch to another engine.

[mindinsomnia]

To cite a real world use for 3D tile based design, a recent application of this in the AAA industry was Fallout 4. Bethesda's internal tools used a 3D grid based editor to construct the interior and exterior of most buildings by creating prefab tile sets of buildings and variations of the externals.

One interesting difference was however, in the final game, all those tile based buildings were combined in a final process into 3D models, so they weren't rendered as individual tiles for performance reasons.

[TokageItLab]

Visual Script was straining maintainers who were not working on Visual Script. For example, if you changed the Math class, you were forced to change the Visual Script as well, it was unnecessarily increasing maintenance costs. Therefore, the removal of Visual Script had the clear benefit of reducing maintenance costs.

However, GridMap seems to be quite independent as code, different from Visual Script. It may be a bit of straining maintainers working on lower level api's like Rendering Server, but it still doesn't seem to be as combined with the core as Visual Script.

Current GridMap may not be useful, but it could be left alone until a more advanced alternative GridMap comes along. It may increase the size of the core and the number of issues that are never closed, but it doesn't much strain the maintainers since no one is assigned to that.

[Frontrider]

The more I watch that, the more it looks like the case of the Visual Scripting tool.

[HybridEidolon]

I've seen a lot of discussion around GridMap being a "simple" tool for "prototyping" but I haven't seen anyone mention how it's an effective tool for constructing buildings and interiors rapidly the way you might see in a game like King's Field or Elder Scrolls.

Additionally, considering the node itself isn't reliant and closely coupled on other parts of the engine getting changed like VisualScript, I don't see the value in removing it. "I haven't seen people using it" isn't a useful anecdote; it's better to have a technical justification or real data to back it.

That said, I like the idea of it being maintained as an addon instead of being in core, but I would personally like a proof of concept done before the node would be removed.

[nion-ne]

Additionally, considering the node itself isn't reliant and closely coupled on other parts of the engine getting changed like VisualScript, I don't see the value in removing it. "I haven't seen people using it" isn't a useful anecdote; it's better to have a technical justification or real data to back it.

Agreed, I feel that at the very least there should be some informed survey on usage before a feature like this is just removed. Otherwise the same justification can be used for many of Godot's anecdotally lesser used features (which may even be justified) in the interest of maintainability.

At this stage I think the discussion in its current state has run its course.

[ahmadwehbe-com]

I disagree.

I don't know who the OP has been talking to when claiming:

"Everyone I talk to that's experienced in 3d doesn't use the gridmap tool for 3d maps. They've either written a terrain system like zylann or modelled the world."

I've been using Godot for more than a year now, and since day one I have been using 3D and the Gridmap to make my levels. I don't see any other way to make 3D tile/grid based levels without a lot of hassle.

I admit Gridmap is not perfect, and is missing a lot of functionalities, but the solution is not to remove it. The solution is to invest in it and make it something on par with the TileMap node for 2D games. This would then make Gridmap the ultimate node for literally any 3D game that uses tiles/grids.

Just because someone isn't building their 3D levels using tiles/grids doesn't mean Gridmap is suddenly useless and should be removed from Godot. The argument/logic is weak and could be applied to every other node they're not specifically using for their game.

Imagine if someone who doesn't use the TileMap for their 2D game suggests TileMap should be removed because they are using a custom solution or painted the world in photoshop. OP's argument is no different.