Will it be allowed to create folders in the Scene Painter so that we can manage the panel and keep it tidy and clean and logical?

Will it be allowed to create folders in the Scene Painter so that we can manage the panel and keep it tidy and clean and logical?

This wasn't in my plan, but I'll add it.

Should the grid step be included in the folders so that each folder can have its own grid step or a single grid step setup?

Should the grid step be included in the folders so that each folder can have its own grid step or a single grid step setup?

I think it's better to set it for each scene that are listed in the painter

What about 3D?

What about 3D?

It is currently being developed for 2D, it remains to be seen whether it has the desired result or not, later a new proposal for 3D should be presented, the way this is implemented is only for 2D and for 3D something new needs to be developed.

Hi @groud, could you check it so far? I would appreciate your feedback.

I think you can add a preview that follows the cursor so as to help users to accurately know how and where the scene will be painted.

I'm not strongly against this feature (with all respect to DexterFstone work, really) but...
At the moment don't see any reason why it should exist in core and not as addon. Such fancy and nice to have stuff is 100 % addons territory.

Hi @groud, could you check it so far? I would appreciate your feedback.

Oh sorry, I didn't check that earlier. I didn't expect you would do it that fast!

I had a thought about the feature btw. I am thinking that, instead of using a dedicated panel at the bottom, why not reuse the filesystem dock ? One simple solution would be to check when the selection changes then, if a scene is selected, use it as the scene to paint. That would simplify things a lot IMO, as you would not have to manage yet another set of scenes in the bottom panel, save the list, etc... (we could still keep the controls in the bottom panel though, I think that's fine). Also, if go that route, maybe we can add a lock next to "selected scene" field notifying which scene is being painted. And if you toggle the lock on, selecting a scene won't change the painted scene anymore (in case you have something to do in the filesystem dock at the same time)

Aside from that it looks pretty nice from the videos already. Good job!

I'm not strongly against this feature (with all respect to DexterFstone work, really) but... At the moment don't see any reason why it should exist in core and not as addon. Such fancy and nice to have stuff is 100 % addons territory.

No, instantiating many scenes in a 2D world is a hassle. Like, if you want to paint an organic forest such a tool is a real blessing. So it being core makes quite a lot of sense to me, especially if we manage to add it without too much code.

But that being said, the primary reason I want this feature is that people keep asking about being able to modify the properties of scenes instantiated by a TileMapLayer, which is not possible without a significant amount of code in an area that's already bloated, and with a performance cost that could end up hidden to the users. Instead, this solution simply brings the quite nice usability of TileMap to scene instantiation. It's simpler, less code, and a lot easier to maintain, while leveraging all the capabilities of the inspector, 2D editor and so on.

No, instantiating many scenes in a 2D world is a hassle. Like, if you want to paint an organic forest such a tool is a real blessing. So it being core makes quite a lot of sense to me, especially if we manage to add it without too much code.

That's why plugins exist. https://github.com/dalexeev/godot-node-brush-plugin for example. Related proposal - godotengine/godot-proposals#5553.

But that being said, the primary reason I want this feature is that people keep asking about being able to modify the properties of scenes instantiated by a TileMapLayer, which is not possible without a significant amount of code in an area that's already bloated, and with a performance cost that could end up hidden to the users. Instead, this solution simply brings the quite nice usability of TileMap to scene instantiation. It's simpler, less code, and a lot easier to maintain, while leveraging all the capabilities of the inspector, 2D editor and so on.

Unfortunately it sounds like even more bloat - "we have problem X in entity Y, so let's add new entity Z with the same functionality but with some changes".

But again, I'm not insisting on anything and I respect the work DexterFstone has done (what he has implemented definitely looks great).
I just said what I thought, and I'm not going to insist on it any further.

Unfortunately it sounds like even more bloat - "we have problem X in entity Y, so let's add new entity Z with the same functionality but with some changes".

No, that's quite the opposite. If problem X is better and more simply solved by a new, different solution Z, that's perfectly fine. Trying to make a generic solution that fixes everything is usually bad, as it makes code more difficult to maintain. See https://docs.godotengine.org/en/stable/contributing/development/best_practices_for_engine_contributors.html#to-each-problem-its-own-solution

But to make it clear, the goal of the TileMap and scene instantiation are quite different. TileMap aims to quite performance-focused, scene instantiation is more about flexibility. It's a bit like the MultiMeshInstance node for example.

I had a thought about the feature btw. I am thinking that, instead of using a dedicated panel at the bottom, why not reuse the filesystem dock ? One simple solution would be to check when the selection changes then, if a scene is selected, use it as the scene to paint. That would simplify things a lot IMO, as you would not have to manage yet another set of scenes in the bottom panel, save the list, etc... (we could still keep the controls in the bottom panel though, I think that's fine). Also, if go that route, maybe we can add a lock next to "selected scene" field notifying which scene is being painted. And if you toggle the lock on, selecting a scene won't change the painted scene anymore (in case you have something to do in the filesystem dock at the same time)

One solution I can think of is the Picker tool, which allows you to pick a scene from FileSystem, SceneTree, or CanvasItem without the need to add the scene to the ScenePalette

Scene paint preview and edit scene properties are added

So I gave this a test. Aside from the missing undo/redo:

• The palette needs an explicit default folder. Right now the default folder has no item in the list, so you need to deselect everything to see it. It's non-intuitive and won't work once you have many folders (deselecting will be difficult).
• Grid snapping does not work.
• Picking needs to be improved. To pick a node from viewport, you need to click it's position exactly. It should work like selecting instances. Also, maybe I misunderstand the purpose of this tool, but I wouldn't expect it to add the picked scene to the palette. At least not from the viewport/scene tree (why is picking from FileSystem even a thing?).
• Too many Resources. Palette folder does not need to be a Resource, and SceneData also doesn't need to either. You can serialize them similar to TileData in TileSet.
• All actions in ScenePaint panel are missing shortcuts. Especially pressing Delete will delete the currently selected node in scene.
• Why is grid snapping stored per scene?
• There is no way to open a scene palette other than clicking the Open button. If you create new palette by accident (which is surprisingly easy), you can't just open the palette file from FileSystem.
• The ScenePaint editor should utilize save_external_data() to save the palette. Although adding undo/redo might make this unnecessary.
• It could be useful to pin a parent node for painting. It's easy to select different node by accident and add nodes to wrong parent.
• Picking a node from viewport/scene should probably automatically copy it's properties. Right now there is no easy way to create "presets" of scenes, e.g. spikes rotated to different angles. You have to set it every time you select the scene.
• When scene from palette is edited in the inspector, it's treated like foreign node. If you e.g. add a shader, you can't edit it. Though that might be unrelated editor bug.

@groud any news, update or feedback?

@groud any news, update or feedback?

Sorry it's taking me a bit of time to review:

• The "Pin node" button's tooltip should show the name of the currently pinned node. Otherwise it's not possible to know which node is pinned.
• The "show grid" toggle is not needed. The grid is already visible or not according to the View settings.
• For better comprehension, I think I would rename the "snap to cell" snapping mode to "Snap to grid cell center". Otherwise it's not super clear it uses the same grid parameters.
• The "Allow overlapping" option should be disabled if the "Free paint" mode is selected.

The "Edit properties" button is quite a bad idea IMO. If you batch-paint a modified scene, it means many changes will end up duplicated in the scene's tscn. So Instead, users should be encouraged to create a dedicated scene with the given changes. Basically you have two situations:

• You need the same properties in many painted scenes => you should create a dedicated inheriting scene.
• You only need to modify the property in a handful of scenes => you can do it via selecting in the scene tree and edit with the normal workflow.

So well, I would remove it completely. It encourages bad practices and is also a bit confusing. TBH I had to check the code to understand what the button was doing).

As a last point, I would suggest maybe using a snap icon instead of the three-dots menu. See what the TileSet editor's polygon editor does, we can probably do the same here:

Aside from those points, the usability is getting quite good. Good job!

So well, I would remove it completely. It encourages bad practices and is also a bit confusing. TBH I had to check the code to understand what the button was doing).

The way it's implemented now could resolve godotengine/godot-proposals#7249. If a user wants scenes with many changes then I don't see why it should be not allowed. Removing the feature would make this workflow impossible.

The way it's implemented now could resolve godotengine/godot-proposals#7249. If a user wants scenes with many changes then I don't see why it should be not allowed. Removing the feature would make this workflow impossible.

It's not impossible, it's just discouraged for performance/scene weight reasons. People could still modify the properties in the inspector if they absolutely need to (or create an inheriting scene, that's perfectly fine too).

Yo mean modify after placing? What if someone has a Spikes scene and wants to place them in different directions? If they wanted to use inherited scene, they'd need one for each direction.

Yes, this can be misused, but when used correctly it's can be immensely helpful. In most cases you have to alter 1 or 2 properties, if people only wanted to place scenes as is then scene tiles would be enough for that.

Yo mean modify after placing?

Yes

What if someone has a Spikes scene and wants to place them in different directions? If they wanted to use inherited scene, they'd need one for each direction.

Well, having a scene for each direction in that case makes sense to me. That's the best approach performance and weight-wise.

Yes, this can be misused, but when used correctly it's can be immensely helpful. In most cases you have to alter 1 or 2 properties, if people only wanted to place scenes as is then scene tiles would be enough for that.

Alright, If this this something absolutely needed, then it should be in a dropdown menu, or something like that. It needs a text explaining this will store the property locally, and that it can have a significant impact on the stored scene size. Or maybe as a better solution, if we want to keep the button instead, then the inspector could display a warning at the top ? In any case we can't accept UX-wise to let users shooting themselves in the foot if we didn't clearly explain the drawbacks of such a feature.

If we can't have this warning, then I'd prefer we merge the PR without the feature and open a proposal for community feedback first.

Now it should be better

Now it should be better

The warning at the top is quite good. It does not disappear when you uncheck the "edit properties" mode.
I'll just suggest some changes to the wording too.

The snapping icon is not ok. It should change depending on the selected mode. And each mode should have an icon, like on the polygon editor screenshot I shared.

The change to "Allow Overlapping" is good! Thanks.

@groud any news, update or feedback?

Tested it again:

• the warning does not disappear when toggling off the "Edit properties" button.
• clicking should trigger an update of the viewport. From time to time when I click once, the scene indicator does not appear right away.

• the warning does not disappear when toggling off the "Edit properties" button.

Which one? You mean Editing instance properties?

• clicking should trigger an update of the viewport. From time to time when I click once, the scene indicator does not appear right away.

Viewport always updating from _gui_input_viewport.

@groud fixed

Which one? You mean Editing instance properties?

Yes. The warning at the top does not disappear.

Viewport always updating from _gui_input_viewport.

Well, no I tested it and it does not. Sometimes it works, often it does not:

You should call CanvasItemEditor::update_viewport manually.

Alright, at a quick glance it seems the code is good enough. I dislike the fact it's in another file though, and uses a plugin. For consistency I would have preferred it stayed in canvas_item_editor_plugin.cpp like all other tools. It forces us to expose many things that were not really supposed to. But anyway, it will probably be fairly easy to move it out of a plugin if needed.

I'll personally approve the current code as it's probably a good base we can iterate on.

@groud can I work on ScenePaintEditor3D? is there any proposal?

@groud can I work on ScenePaintEditor3D? is there any proposal?

I don't know, I don't really maintain the 3D part. But I assume it could be useful.

Thanks!

@DexterFstone And now I'm waiting for a 3D equivalent hint hint

This is getting off topic, but for a 3d variant it could be good to make use of rendering device or gpu particle shader instead of MultiMesh so we can have proper culling and lods support

Does this also close godotengine/godot-proposals#6886?