Sub-resource editing RFP (Request for Proposals).

[reduz]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

Sub resource editing was introduced in Godot 3.1 It's useful and improves workflow, but it's also confusing because it's not very clear where sub-resource ends or which properties belong to which sub-resource. This can be visible in the image below. There is a thin line around each, but that's about it.

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

I have no idea how to overcome it, so asking community for ideas on how it can this limit be made more visible without sacrificing usability (as an example, can't make sub-resources thinner because then things don't fit).

If you have ideas, feel free to post mock-ups in this issue!

[alexfreyre]

1. could be an empty sub-panel in the inspector that only shows the sub-resource options
2. could be a pop-up window

[aaronfranke]

Off the top of my head, two ideas:

1. Increase the indentation to make it obvious. This would also require us to increase the inspector's default width.

2. Allow popping out the sub-resource as if it was a resource, somehow.

[ChaosWitchNikol]

Definitely increase the indentation (as @aaronfranke proposed in 1. )

The indentation can be color coded - similar to this VS Code plugin (https://github.com/oderwat/vscode-indent-rainbow)

Increasing the width of the inspector might not be necessary in case all properties are placed on "two" lines like the rotation

[sketchyfun]

Either a pop-up (since I assume this is for 4.0) which would mean width wouldn't be an issue

or maybe the inspector panel changes to just show the sub-resource details when it's clicked on, like when you click on a Material in the inspector

[Janglee123]

A pop up window like color picker.

[jcostello]

@sketchyfun what about sliding child panels instead of popups?

[theraot]

Put a border around the sub-resource that has input focus.

Simple, does not mess with width, does not require popups.

I have arrays of sub-resources, I don't want a lot of popups to edit per item. I also care about width.

Addendum: What I meant was something like https://github.com/godotengine/godot-proposals/issues/2230#issuecomment-771970438 (below).

[YuriSizov]

Guys, to keep the discussion in a more constructive state, maybe instead of throwing around ideas we can produce actual mock-ups of how it would look and act in our particular case, in the Godot editor's dock? I'm afraid it may turn into a flood of random comments about various details otherwise.

Let's work towards higher quality proposals. And don't forget, that if you support an idea, just put a 👍 next to it.

[vagrantG]

To save space from indentation and clicking to go to popups that cannot be quickly compared when switching between entities i'd try to create a horizontal separator that is drawn at the end of a (sub)section and it's coded with the level of identation or type of section (ex. here ends a sub-resource, here is a list of secondary properties). For example it could be an horizontal line with small vertical ones in the center, one more each level. Instead of vertical lines they could be small arrows pointing up. Possible variations with coded colors or other more complex patterns. The separator could also used as a quick info tool. For example one click on the separator could flash the parent item in the list to understand which ground ends there or print the corresponding variable path in the output panel of the editor to copy paste into code to use it, or show a tooltip with the resource type/name. Other options can be adding a separator to the start of the group too or do it in the upper/lower corners of the properties to save space.

A border to circle around the sub-resource is also interesting, outside the classic thick margin with different color i'd try some pixel pattern or inset effect. The separators suggested could be used inside the list of properties in the sub-resource.

[mykelas]

changing the previous/next edited object in histor using back/forward mouse button.

[eon-s]

apart from what @aaronfranke proposed, the color/outline should make it very clear that we are dealing with Resources, because those may be shared (also probably something extra that shows if it is a Resource file)

[LucyLavend]

Highlighting the top most resource could help quite a bit with readability:

[barbaros83]

thicker and brighter lines around it, i also like the idea of having it pop to a seperate tab, with an arrow button that lets you get back to the main panel. or have it as tabs inside the inspector, where the tabs are just under the inspector label

[Jummit]

thicker and brighter lines around it, i also like the idea of having it pop to a seperate tab, with an arrow button that lets you get back to the main panel. or have it as tabs inside the inspector, where the tabs are just under the inspector label

and

what about sliding child panels instead of popups?

Isn't this already the case?

[0stam]

I would say that from all suggestions above the thicker and bolder line marking the sub-resource looks like the best option. Both new window and side panel add one more click to the work-flow and the indentation makes it take way more horizontal space (especially when working with nested resources).

At the same time I'm not a graphic and I don't know if it would work, but what if instead of just making the border more visible the colour of the whole sub-resource section would change? It could be e.g. the theme colour growing in intensity with more resources being nested.

[werdnahull]

What about simply dimming the areas outside of the sub-resource until you click out of it?

[Calinou]

What about simply dimming the areas outside of the sub-resource until you click out of it?

The issue with dimming is that you may still be interested in modifying parts outside the subresource, or even move the mouse to other parts of the editor to do something unrelated. Dimming implies that anything outside is locked.

Also, dimming messes up with things like picking colors using the ColorPicker node. We want to move away from it for Godot 4.0.

[MrDudeIII]

Please don't increase the minimum indentation. Us poor people with small resolutions can hardly see as it is. Would it work to edit subresources as partial popout similar to color selector?

[RPicster]

Maybe it's a bit too much, but using color to group always works, even if it isn't as fancy as some other things. Maybe additionally?

I made another iteration.

changes:

• bigger left line to make the color grouping clearer
• added a small padding and horizontal color border to the bottom of the opened "property group" (don't know the name)
• made background and headline of openen "property group" brighter and changed the arrow to downward pointing

[werdnahull]

What about simply dimming the areas outside of the sub-resource until you click out of it?

The issue with dimming is that you may still be interested in modifying parts outside the subresource, or even move the mouse to other parts of the editor to do something unrelated. Dimming implies that anything outside is locked.

Also, dimming messes up with things like picking colors using the ColorPicker node. We want to move away from it for Godot 4.0.

I should clarify: I did not mean necessarily to dim the entire editor, but rather only dim the Inspector panel.

[jocamar]

I think color coding the nested resource fields will already do a good job making them more clear. Maybe not these exact colors, but something like this. In addition to this you can indent them more without losing space if you stop indenting them on both sides and just do indentation on the left. The space stays the same but they get pushed a bit more to the right, which makes it clearer IMO.

[clownshoes]

Mostly small ideas:

• Thick borders on the left side that are connected to the name of the resource
• Add some padding on the top and left sides of sub-resources to separate them a bit
• Highlight the border and name of the resource that's currently being edited, rather than the whole ownership hierarchy (Sky is being edited in the example)
  • The background could potentially also be highlighted (not shown in example)

[OrigamiDev-Pete]

My idea is pretty similar to those before.

[vrid]

You can isolate sub-resources as seen above and then back with the arrow - then even detatch the inspector to be floating (then put in viewport close to your edited object for example).

Keep in mind that godot is an editor. Not in-game UI or mobile app. It doesn't need fancy animations(sorry, horizontal sliding - @jcostello . It changes too much for such a small thing IMO).

The engine is growing very fast so be careful to not bloat it or make inconsistent before it gets out of hands. :pray:

@LucyLavend 's or @clownshoes 's solutions are simple yet work is done. :+1:

[jcostello]

@vrid Maybe it is time to modernize the editor in order to have better UX since its a mayor version update

[vrid]

@jcostello I think why not but it needs well prepared proposal with huge analysis 'what, where any why'. Every element should play with the other. In this case I just disagree with horizontal sliding covering up the view of parent. It's totally impractical.

Look at giants like Unreal, Unity (or not an game engine but called as industry standard for a good reason 'Substance' software). Simple UI, no animations, highly customizable layout. That's well working solution for enormous amount of options in the software.

Talking of changes maybe something similar to blender would work - little rounded edges to make it 'modern' or I would rather say 'currently fashionable?'.

Still usability and consistency comes first what godot in it's current state serves well.

[jcostello]

@vrid Im not familiar with the UI of Unity or Unreal. In web, specially in mobile, its common to use that to change the focus and have a light interface to the user. I don't se a problem hiding the parent if you want to focus into the child. You can still highlight that the panel is child of X.

I agree with you that maybe a modernization requires a deep analysis.

The main issue that I see with the interface right now its that there are a lot of hidden options that are not intuitive to reveal, like the sky options once you create a sky. In that case those options should be displayed always.

@reduz how big is the scope of the change for the UI? if the solution should be simple @LucyLavend 's or @clownshoes 's solutions are ok.

But a modernization of the UI should be planned nearly.

[mrjustaguy]

To me, https://github.com/godotengine/godot-proposals/issues/2230#issuecomment-771970438 and https://github.com/godotengine/godot-proposals/issues/2230#issuecomment-772027154 look like the best solutions, as it's quite clear that they are different sub-resources..

However, on that note (a little bit off the exact topic of this proposal but still related), There could be an improvement in the workflow to add like a Resource Hierarchy that would look similar to the node hierarchy.. Here's what I mean (Numbers are how far something is away from a root in the tree) :

0 - It's the root of the Resource Hierarchy as it's a node that is edited 1 - A node Property 2 - The Hierarchy of the Resource of a given Property 3 - A Sub-resource of the Resource 4 - A Sub-resource of the Sub-resource before it ([4,+inf> are this)

Example: (Format is Root Distance.Property.Sub-resource level 1.Sub-resource level 2.etc...))

0 - MeshInstance is selected 1.1 - Material = StandardMaterial3D 2.1 - Albedo (because it is set and not default) 3.1.1 - Color (Has color Assigned that isn't default) 3.1.2 - Noise Texture 4.1.2.1 - Noise

What does the tree mean? On the selected MeshInstance, Only Property set That has Sub-resources is A Material. The StandardMaterial3D Only differs from Default with it's Albedo, hence it being in the Hierarchy. It's settings/sub-resources are Color that isn't default, and Noise Texture, which has a sub-resource - the noise itself.

This is the General Idea that would improve Resource Manipulation as a whole with clearer navigation. Please Note that it Already sort-of exists, as you can go in to the Node Hierarchy and right click and go Sub-resources.. However I feel like having the ability to have something like that as an inspector addition, so that the Hierarchy is constantly visible (if it's turned on in the settings) would make a leap forward with Usability, as you would be able to easily switch between various layers of resources you are using without extra navigation, and would always have the hierarchy in mind and sight if you so desire.

[HaSa1002]

@jcostello The problem with your proposal is that sub resources very well belong to their parent. Their properties do make sense to be edited at same time as other properties of their parent. One reason why they are sub-resources is that you can share similar settings one multiple nodes. That being said, perhaps we could show better whether the sub-resource is unique and specifically set for its parent or it is shared. Additionally, some options are context dependent to reduce clutter in the UI and I think that is a good thing for workflow speed, even though it might not be intuitive.

[KoBeWi]

How about, instead of increasing indent and limiting horizontal space, we expand outside the inspector?

[mrjustaguy]

https://github.com/godotengine/godot-proposals/issues/2230#issuecomment-772483126 Bad Idea. On Lower Res monitors and/or small Screens where every ounce of space is important, having docs with inconsistent size requirements is a nightmare (in general too, for customization for example), furthermore the transitions are somewhat distracting.. When not taking the Out of Inspector stuff into account while reading, it looks like Sky Material is Highlighted, and the Process Mode to resource later, which is not a big issue when it's as small a window as it is here, but when you've got a whole screen of those.. it would be a nightmare to keep track what is where, making the current situation possibly a tad bit worse.

[rick551a]

I think the issue is mainly with lack of visual anchor points. As one scrolls past many sub menus they all blend together, and one has to READ each label to find the correct option. A small representative icon next to each sub menu would solve this. The icon also serves as a demaracation point.

Quick mockup image : https://pasteboard.co/JMGBhai.png

[Riteo]

Quick mockup image

I don't know whether it's an issue on my side or not, but I can't see the image.

Edit: Formatting because I'm dumb

[theraot]

@Riteo

This is the image from @rick551a

[Calinou]

Having subtle icons in the section headers is a good idea, but we'd have to spend a lot of time creating icons for each section. We could reuse some of the icons we already have, but we'd probably still have to create dozens more icons to fit all nodes.

[HaSa1002]

But that would benefit other areas, too. You could use those as well in the file explorer when you saved sub resources. Would be interesting too count how many icons we would need.

[Jakob-PB]

I made another iteration.

I think the outlining for this one is the easiest to distinguish out of what has been posted here so far, but it has a couple of issues: 1) Doesn't help as much for those with color blindness unless colors are chosen carefully. 2) Potentially doesn't mesh naturally with many custom editor themes.

Probably the more ideal approach will involve some means of spatial grouping. This idea with indentation has a lot of promise:

Indention and other spatial tricks don't suffer the issues involved with relying on color. Something similar to this indent mock-up could be combined with a subtler and theme-integrated outline hint (like automatic color value shifting some amount for every level).

[Riteo]

1. Doesn't help as much for those with color blindness unless colors are chosen carefully.

Well, remember that to colorblind people the outlines would still be visible, so we could work on that.

I agree with other posts saying that indentation may fill up too much space. IMO that could also make the inspector size weird and everchanging, since there can be theoretically infinite amounts of subresources, thus of indentation.

[RPicster]

1. Doesn't help as much for those with color blindness unless colors are chosen carefully.
2. Potentially doesn't mesh naturally with many custom editor themes.

Both of those points are easily solvable using either the editor theme or e.g. a colorblind option. Usability should always be above style. You also only need two colors that you just flip for every level of depth.

Indentation is absolutely no option in my opinion. I use the SmartShape2D plugin and there are sometimes at least 6+ levels of depth in resources. How much wasted ui space would that be with indentation?

[mrjustaguy]

The Colors could be edited, so Colorblind people could go into settings and change the colors, and a Colorblind mode could be added to the editor theme probably.

[Jummit]

I checked the image with a color blindness simulator, and they are still clearly distinguishable.

For editor themes, the colors could be blended with the base color so it looks right with all themes.

[Ansraer]

I personally prefer clownshoes proposal of borders on the left side. I would however suggest we remove said border from the topmost element (Environment in his example). That should make it fairly obvious what exactly the sub properites are and how they are grouped.

[YuriSizov]

Regarding editor theme colors, keep in mind that we only expose 2 colors to users, plus a contrast setting, and interpolate everything else from that (or, in some cases, we hardcode colors).

There is only so much we can get out of the accent color and its interpolations with the base color. It would be a bit weird though to introduce specific color options for this particular part of the UI. Maybe we need more than one accent color now...

And even if colors are themselves distinct enough to not cause problems with color-impaired people, we would most likely need to create gradients of intermediate colors and some people are bad at distinguishing slight gamma changes. And some displays are bad at it too.

[RPicster]

Regarding editor theme colors, keep in mind that we only expose 2 colors to users, plus a contrast setting, and interpolate everything else from that (or, in some cases, we hardcode colors).

There is only so much we get get out of the accent color and its interpolations with the base color. It would be a bit weird though to introduce specific color options for this particular part of the UI. Maybe we need more than one accent color now...

I guess you can easily generate a color by either inverting hue (adding 180° or however you like to put it) of the accent color and use those two or take colors that are already there from the "default" colors.

[YuriSizov]

Like I've said, this only gives us limited amount of distinguishable options. The inspector panel itself, if you include the actual individual property editors, already uses like 5 or 6 variations of the base color interpolated with black or white. "Inverting" may be an easy option to give us a couple more colors, but I'm not sure how good it would look in an actual random user theme.

I still think a secondary accent color may be a better option. Gives more direct control to the user and gives us a bit more room of colors to play with. Because the mockup with distinct colors and borders looks the best so far.

[Zireael07]

+1 on secondary accent color being specifiable in theme.

[Calinou]

I'd prefer using hue rotation several times rather than having to deal with a secondary accent color. Managing the editor theme generation is a lot of work on our end already (think of me).

[YuriSizov]

I'd prefer using hue rotation several times rather than having to deal with a secondary accent color. Managing the editor theme generation is a lot of work on our end already.

But think what it leaves the user. Very limited input using just two colors which are, out of their control, adjusted for a multitude of situations. It would make it even harder to pick a color that would work everywhere. In this case it would be better to hardcode two sets of colors for the resource editor (generated with hue rotations or manually) for both dark and light themes instead of relying on the accent color.

[jcostello]

Beside the UI position and color, this should fix the issue with hidden options. For example when you create a environemnt or sky, you have to click the dropdown to reveal the options for it. It is not very intuitive to do so. We should come up with a better way to display or hide nested options

[0stam]

Beside the UI position and color, this should fix the issue with hidden options. For example when you create a environemnt or sky, you have to click the dropdown to reveal the options for it. It is not very intuitive to do so. We should come up with a better way to display or hide nested options

In the 3.2.4 RC 1 all freshly created subresources are opened by default.