UI feedback and suggestions for potential solutions

[NathanLovato]

Hey, I'm Nathan from GDQuest. This follows up on our short exchange on your channel.

For convenience, I went ahead and compiled all the notes in a single post. That way, you can review quickly and filter desired changes before opening too many unwanted issues in the tracker.

I kept the feedback focused on what the add-on is currently at, it seems to be what you desired.

Please don't hesitate to take and leave what you want, ask for more details and whatnot. I'm happy to help wherever you'd like help, and happy to not touch or bother you with areas you'd rather keep full control of.

Initial question

I was wondering if you tried leveraging built-in nodes, such as MeshInstance, and if you faced specific limitations that prevented you from using them?

I'm asking because you need to re-implement features Godot provides for them such as simple and box selection, focus, etc. And this choice will affect future UX improvements the Godot developers bring to the 3D editor.

Toolbar

Observations:

1. Firstly, the Godot toolbar isn't too great right now, and this is not your fault at all, but it limits the clarity of the user interface you can provide due to offering only a horizontal layout and getting visually cluttered quickly.
   • It limits the ability to use descriptive text labels, hurting accessibility
   • The toolbar doesn't make it clear what are your add-on's tools
   • Usability gets worse as multiple add-ons add widgets to the toolbar
   • Modeling tools aren't available until you select a specific node, which also limits accessibility and discoverability (as opposed to having some UI piece that's always present)
2. Tools aren't very quick to select as you have to use the mouse to reach them
3. Tools aren't the easiest to spot and distinguish at a glance
4. Grid snapping and display dropdown aren't descriptive

Proposal:

1. There is no very satisfying solution for this, it's a general issue in Godot, and a well-known one. This point is mostly to open discussion.
   • The most Godot-like thing for pretty powerful editor interfaces is using the bottom panel (examples: tilemap, animation, animation tree, shader graph...).
   • It gives you a lot more control over the UI design and allows you to have your own toolbar, completely separate from Godot's main toolbar (see animation and tilemap panels for examples)
   • Your tools can always be visible, allowing the user to start modeling anytime.
2. Shortcuts! At least for the most important tools I'd register custom shortcuts
3. Several suggestions:
   • Add an icon for each tool with a color code
     • Green to add, blue to select, for consistency with Godot tools.
   • Visually group and separate selection tools (vertex, edge, face) from modeling tools.
   • Use editor styles for consistency with built-in tools.
   • Block tool falls into two categories currently, but what I'd consider is giving vertex/edge/face the features of the block selection. If you click on a deselected block, it gets selected and vertices appear. Shift click can select other blocks or vertices...
     • I can write a dedicated proposal for that if that's desired because there are many details to outline.
     • The short pitch is I'd consider separating the selection and modeling tools for clarity. I'd add a block selection tool for selecting, moving, and deleting entire blocks.
   • If sticking to the Godot toolbar, I'd have just icons with tooltips similar to what Godot does. Again, not ideal at all, it's a limitation of the toolbar design and not something I find particularly great. But that'd make the add-on more accessible to users with small displays (e.g. 13" laptop), and the UX more consistent with Godot.
   • If going to a bottom panel, I'd definitely have icons + labels for tools, and similarly some grouping.
4. There again there's a difference if you stick to the toolbar or not.
   • If sticking to the toolbar, I'd consider either adding an icon to each dropdown and units for the grid snapping (little gray "m" as seen in the Inspector). Or I'd offload options to a vertical "..." menu that would open a modal window

Materials dock

Observations:

1. Without docs the UI has limited discoverability
   • You have to figure out that you must drag and drop specific resources onto the dock's look and feel is quite different from the rest of the Godot interface
2. Materials can't be removed individually, it seems, it's all or nothing
3. Remove All instantly removes materials and cannot be undone. It's a sensitive operation

Proposal:

1. Have an "Add materials" button that pops up a file browser alongside the Remove All button
2. Reuse the look and feel of the file system dock in gallery mode
   • Give material entries a fixed width
   • Use the string API to trim long text
   • Have a panel with darker background for the area containing the materials
   • Use editor styles for the materials so the look matches user theme and adapts to light themes automatically
3. It's not an essential operation, but it'd probably be nice to be able to select and remove a material? Multiple materials? I'm not 100% sure without testing extensively.
4. Add a confirmation popup or if possible, undo redo support

Other suggestions:

• There are few materials in the demo scene, but back when I worked as a 3D game artist (worked in UDK so with similar modeling tools), we used larger numbers of materials. It may be useful to have a filter bar at the top of the dock, similar to Godot's file filter.

UV dock

Observations:

UV transform options feel like inspector properties but are put in a separate dock with a pretty different user experience.

Proposal:

Use the inspector plugin API to integrate the UV controls and future block-level properties into the inspector. On top of offering a feel similar to the rest of the inspector, it could be extended with interactive widgets or modal windows if needed.

Making this work with probably involve using the scene API to select Block nodes in the scene dock when using the Block tool.

Note that selecting individual block nodes in the scene dock with your Block tool would allow you to leverage the Focus command in Godot (F key), allowing the user to recenter the camera just like when they select regular 3D meshes.

---

I hope that some of the above is useful. You are welcome to take or leave anything, of course. I'm happy to participate in further discussion or help tackle some issues if desired.

[blackears]

Hi Nathan,

You have quite a lot of ideas here. I like some of them, and some of them will be made obsolete by future changes I'm planning.

The addon is using MsehInstance3Ds to render the shapes. But they do not appear in the scene and cannot be manipulated directly. The CyclopsBlocks node adds them as children and makes sure they're up to date during the _process() loop. The main reason I'm not using the raw components is that I need to manage mesh and collision as a single unit.

One of the big changes I'd like to make is to allow blocks to exist individually in the scene and not have to be children of the CyclopsBlocks node. If I can do this, it should be easier to use Godot default tools.

One limitation of Godot plugins is that they are sensitive to the object currently selected in the toolbar. So if I want receive input events, one of the Cyclops* objects must be selected in the outliner. So the toolbar in the editor functions partly to alert the user that Cyclops is active. It would not be possible to draw blocks or prisms otherwise. Like the idea of having a separate docks for more complex tools, but I feel retain in the toolbar for quick access and to alert the user still makes sense.

Shortcuts are a good idea. I still need to look into how to do this.

Icons are a good idea, but someone would need to design these. Maybe I could grab a few open source ones. Unfortunately, Inkscape is not the easiest tool to use.

I think you ideas for the material editor make sense. I've worked with styles a bit, but not editor styles specifically. How do you access those?

The UV Editor dock is not something that can be easily integrated into the inspector since it depends on the current object and face selection and can also edit multiple faces at the same time. It has very basic functionality at the moment. Eventually I'd like to replace it with a projection tool that operates in the viewport.

Anyhow, for now it might be best to work on small UI fixes if you're interested. If you could get the UI components to use the 'editor styles' you mentioned, that would be helpful.

[NathanLovato]

So as a contribution you'd accept help with accessing and using the editor styles, but anything else you'd rather handle yourself? To know if I should PR something next. I can also cover how to access the editor styles in a quick video for future reference.

[blackears]

I think you're being too formal about this. Issues work best when they're small and focused. If you look at the issues Calinou submitted to the issue tracker, you can get an idea of a good way to format them. An issue is best when it's focused on one specific problem that can be easily tested for. What you've submitted here is more of a general design document. While I do think there are some good ideas here, it's too sweeping for me to just approve the whole thing. If you could instead submit issues for individual things that need fixing, I could do a better job of addressing them.

[NathanLovato]

Nobody asked to approve the full thing, as written above, you just take and leave what you want.

The reason for one page is to avoid having to submit the form 10 times and open 10 tabs to review. You can quickly say e.g. "material - 1 2, yes, 3 4 no".

Also, Github issues let you one-click turn individual bullet points into new issues instantly and then close the larger issue or keep it open as a tracker.

Anyway I'll submit individual tickets moving forward, no problem, starting with the tasks you seem to want from this.

---

An issue is best when it's focused on one specific problem that can be easily tested for

Like Hugo (Calinou), I've been working professionally in open-source for a long time, thing is different maintainers want different things. Some do want bigger help, others want to code important things themselves.

As a contributor, the only way you know is when the project owner tells you. You can make them explicit in your README, e.g. "Contributing - open small issues. PRs are welcome but for small fixes only."

[blackears]

I didn't know you could click bullet points to turn them into subissues. Nothing's happening when I try that above, but maybe that only works in the issue tracker?

I saw you submitted a lot of individual issues - thanks. I've not had a chance to review them yet. If any of them are small fixes that are only a few lines long you can go ahead and submit a PR for them. For now I'm not looking for anything that would majorly change the direction of the project or add a huge new feature, but that may change as the project evolves. I'm still figuring things out.

[NathanLovato]

Yes, this only works from issues. Though I saw that now the bullet lists have to be converted to task lists first, e.g.

I'll try to find small things to help with then!