Add a scene painter tool - #109360
Add a scene painter tool#109360
Conversation
53d7c0a to
d5f2afc
Compare
|
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 |
d5f2afc to
f07efdd
Compare
I think it's better to set it for each scene that are listed in the painter |
|
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. |
f07efdd to
a656919
Compare
|
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... |
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!
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. |
That's why plugins exist. https://github.com/dalexeev/godot-node-brush-plugin for example. Related proposal - godotengine/godot-proposals#5553.
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). |
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. |
One solution I can think of is the |
a656919 to
4b6edcb
Compare
Closes godotengine/godot-proposals#12945
2025-09-15.02-51-09.mp4