[Scene Editor] UI Customization Expansion

[rzkid]

For?

S&Box

What can't you do?

With the current plan to port Hammer into C# (Mesh Editor), the general idea is that everything is moddable, movable around, and you can make any layout and buttons you want ever. If something is not good, it gets feedbacked, and then fixed. If something doesn't get feedbacked, it get's naked king'd, and not fixed. This is the feedback.

Technically, as the plan is to have "moddable open source hammer", anyone could implement this as the sources become available, but the following suggestions are related to the base experience most users will benefit from, as they get the editor closer to the highly desired "hammer parity", and additionally have more options for customizing their experience, as the current state of tools is very lumped together, disallowing most of the customization.

How would you like it to work?

This is a reference mockup of what the potential version of that could look like, with comments below:

1. Inspector & Tool Properties

In hammer, the object properties (Scene Editor - "Inspector" Window) contain the properties of the selected object (duh), and only that. Texture settings of a face, for example, appear in the same window, removing access to the object properties you had before - making it a problem if you need both at the same time for one reason or another, or just prefer having them separate, "the hammer way". Useful for UI customization.

2, 3, 4. Various toolbars

Currently, most of the scene editor tools (mesh/object manipulation, navmesh, terrain) are cramped within one very tiny HeaderBar/QWidget (widget debugger names). instead of being thick healthy buttons you can see from a mile away. Instead of being the weird QWidget, they should be the same as the valve tool buttons that already exist within the toolbar (hammer, modeldoc, material editor, etc - those buttons), and separated by the type of the function the tool does, like Mesh Editing (2), Manipulation Modes (3), Extra Tooling like the Navmesh buttons (4), etc.

5. Good Example for previous point

This toolbar is a good example of customizability - it can be moved anywhere , it can be horizontal, it can be vertical, you can add more tools to it, you can remove tools from it, you can resize it, you can kinda break it by moving it to the edge of the screen, anything you could ever want, this toolbar is able to do. The other toolbars mentioned previously, should follow this example.

6. Material select & preview window

Self explanatory. It is nice to have a huge preview for the selected material, and being able to switch it out fast and cool thanks to the niceness of S&Box Editor, while not being constrained to the tiny line in the Inspector window, which might not be even open, or whatever else. Also allows to have the cool right click options.

7. The viewport toolbar niceties

The viewport tools are fine, but they could be better with minor rearrangements, since most of the stuff around it moved away, freeing the space (there is a potential for more, since all of the above is a mere suggestion). Also grid size and snapping options.

What have you tried?

Nothing, as explained in the first section.

Additional context

Here's a clear mockup without the numbers, for all the math haters out there:

[garrynewman]

I think you're right that the tool properties should be separate from the inspector. We did have them in the scene view itself, but maybe we do need to think about a completely separate dock for the tools, leaving the inspector distinctly for objects. The counter-argument is that the inspector should be context aware, so if you're selecting vertexes, it's about the vertexes, if you're selecting faces, it's faces, if you're selecting objects, it's objects.

Toolbars - I want to avoid having a bunch of toolbars. We don't want it it turn out like Hammer's toolbar. We can re-jig the header toolbar to have bigger, more informative buttons, but I don't think we should split it.

Material Select - I think what's obvious with the scene system is that the asset browser isn't fit for purpose. We probably want a special selector, specialized for models and one specialized for materials. These should show something like a history. That said, I don't like having a big panel for the "current" material. I feel like this should be context aware, you don't need a 300x200 space always showing the current material.

[aylaylay]

I've always hated in hammer that there's a whole dock dedicated for just the current material

[johncosfm]

Could maybe potentially be useful to have a grid of 'active' materials, so you could load it up with all the materials that are relevant for whatever sort of area you are making and have easy access to all your floors and walls and ceilings without needing to find some existing bit of geo to lift the material from each time.

[DoctorGurke]

Hammer had a "used in map" section in the asset browser, maybe "used in scene" could work as well in asset browser

[LVJohnFreeman]

I feel like this direction/yesterday change doesn't solve the issue of adapting your space, while having better readability/comfort. I know Garry said he doesn't want Hammer toolbar thing, but at the same time why can you do this with the separate tools toolbar, why do I want to do it with that and not with my workspace tools env? I would rather change where my workspace tools are, which I would be using in the scene, while the separate tools can always be static instead IMO.

I think best path is to give customizability there where it matters, as more and more stuff is put into the scene editor it would be nice to utilize that space in an efficient way, as if I will be touching it, I would do be mainly touching geo and texturing related tools. Not to mention having custom stuff for game related stuff. Perhaps in addition to that the icons should scale on your behalf? So people who need as much visible as possible, they could have that.

To reiterate I understand that the desire is to not just copy Hammer in this regard, but I think it would be beneficial still for your own setup and your comfort, having the ability to setup the scene editor for your work pipeline. Everyone have their own monitor setups, ui setups etc after all. As I understand more and more stuff will be put into the scene editor, add to that users own solutions/tools/subtools and arguably it could end up being more than Hammer used to have. I feel like eventually whatever you do it will start to cramp up space, and there should be more darring solutions there, and one could argue there could still be SOME parity with Hammer, but that's not necessarily the main point.

Think there's a good reason software that are heavily bloated with features (say, Blender) have at least some customization for your work space, as it becomes hellish otherwise. Not that I'm impyling Scene editor will be bloated necessarily, but for some users it might feel restrictive in wrong places, and be crammed up with UI elements that are not relevant to them.

Say there is a team working on a project, say I"m either a person who renders pretty pics/does the trailer for a game (within context that SFM might be introduced within scene edtior) or an env artist, we both work within the context of that same environment, but me or the other guy doesn't need the UI to focus on parts that are of less relevancy to us, say I don't necessarily need my UI to focus on animation layout and some of the toolbar icons cramming up my horizontal space/or vertical (whatever I prefer). Perhaps not the best example, but I feel like there could be many such cases where you would want to do X and be bombared with Y, Z. Would feel like I'm forced into the same basket with everyone and no option to optimize my space, instead of feeling at place and being able to be efficient. I think since we are also clearly moving away from Hammer at this point (I just don't see that we won't tbh), we might as well have a middleground solution for not only parity, but so people like me don't feel pressured and have that "thrown into one basket with stuff I don't need" ordeal.

I just sincerely see this as inevitable, as more and more stuff gets added to Scene Editor. And I would really like my ui workspace to be focused around what I do, what I need to do. Unless i'm jack of all trades, then I could potentially have it all, but that's also not always the case, if not rare also.

[rzkid]

I feel like there's been some misunderstanding about the goal of this request/proposal, resulting in changes that do not improve on mentioned "issues". As per name of the issue, this proposal is about extending the customizability of the editor tools, allowing the user to make their layout in a way that suits their monitor, their habits, their preference, their project.

That means, that tools, bars, windows, buttons, have to be separated, even if they are not separate by default and will be clumped together by the majority of users anyway. The option of separating things your project doesn't need, is still there, even if the default position isn't separated.

Focusing on the recent update, the widget toolbar (QWidget Bar? I still don't know the proper name for it), while it addressed the size issue, and almost perfectly so (I still prefer that they would have the same styling as the modeldoc buttons, but this is a personal preference and is not point of the request) it did not in any way addressed the customizability issue, leaving all sections as part of one bar, that moves together, can't be vertical, and with the update, now is context aware, which made it worse.

Worse? Let me explain:

Let's say I am in object mode, there are 3 transform tools. I switch to the block tool, and now the entire bar moves to the right, and after pressing the button, without moving the cursor, I am now hovering over the verts mode, and not the block tool button I just pressed. The old version avoided this by having the transform tools on the left of the whole bar, having space to expand into, without moving and shifting the entire bar, ruining your muscle memory. This is the pitfall of "context adaptive" tools, sometimes the fix for which, is not doing it. However in this case, I could solve the issue myself, if I could move that portion of the toolbar to the left, or even making it vertical and putting it on the left side of the screen, so it never interferes with the other tools.

Toolbars - I want to avoid having a bunch of toolbars. We don't want it it turn out like Hammer's toolbar. We can re-jig the header toolbar to have bigger, more informative buttons, but I don't think we should split it.

There are even more arguments why splitting benefits the customization, I have briefly mentioned it above, but will expand on: My project doesn't need networking. Someone's project won't need the terrain tools. Someone else's - won't need Navmesh. Simple solution to this if the toolbars were separate = just move them where you don't care, or hide them outright. They are permanently part of the single bar, even if my project will never need them, taking space.

The argument about hammer toolbar would make sense if you had 5 billion features you COULD NOT hide, move or sort in any way that suited you, but since this proposal is about that, I don't see how this is an issue at all, since this is exactly about how to not have that and suit all users ever. Can't get worse than CryEngine or 3ds Max toolbar wise.

I think you're right that the tool properties should be separate from the inspector. We did have them in the scene view itself, but maybe we do need to think about a completely separate dock for the tools, leaving the inspector distinctly for objects. The counter-argument is that the inspector should be context aware, so if you're selecting vertexes, it's about the vertexes, if you're selecting faces, it's faces, if you're selecting objects, it's objects.

Context aware is very hard to have good control of and ALSO suit everyone, with how "everything in one place" the editor is (is not bad per se), it might not be the best option here. What if I don't want that? Do I go into editor code, and disable that? I'm an environment artist/cinematic scripter/gameplay designer/janitor, not a programmer, why should I go into the code to disable that. Instead, what you could do is work backwards from that, having two separate windows that you could put as two tabs of the same window, and then your context aware code kicks in and just focuses on the needed tab, but only after I put them together, because I wanted for it to be like that for me locally.

Material Select - I think what's obvious with the scene system is that the asset browser isn't fit for purpose. We probably want a special selector, specialized for models and one specialized for materials. These should show something like a history. That said, I don't like having a big panel for the "current" material. I feel like this should be context aware, you don't need a 300x200 space always showing the current material.

As for the material selector on the bottom left - it's an argument for workflow specific windows - because programmers won't need neither model nor material selector, but an environment artist would need both. In theory, asset browser works fine for that purpose, however in that hammer-like bigass image with button case, it's a specific section of your monitor, where you go to switch your materials, instead of navigating 5 windows to get to your mats. You also see at all times which material you have selected, and if you accidentally selected something else without knowing. If I want to do something else with the materials, like see what other materials are on the map, it's hidden in a menu, behind a single button that is clearly visible, you can't miss it, instead of having a whole material list that will take a good chunk of your screen. Why introduce an overpopulation problem by adding more windows you are trying so hard to avoid (by postponing any work on tool UI because "we don't know what we will have yet"), where it will be harder because you have more tools to sort through than now. It is slightly different for what I am proposing, as I am asking for separation of existing elements for more control, and not new things outright. There is a clear potential for improvement, like you've mentioned adding history could probably work in some way, I am not sure about the model selector, since you can just have asset browser for models and "the new window" for mats.

Think in workflows, not tools.

Improvement is a collaborative effort, and you can't have it without having a conversation. The fact that we are even talking about this is great, even if in the end we will get more drifting toolbars and hopefully more things in the future will be approached similarly.

[garrynewman]

I don't really agree that we should be making everything customizable. I think we should be opinionated on the layout, and people should mostly have the same layout.

[Nolankicks]

I don't really agree that we should be making everything customizable. I think we should be opinionated on the layout, and people should mostly have the same layout.

I think the new change of making the top bigger just better shows the issue of the ui being cluttered.

[LVJohnFreeman]

I think the new change of making the top bigger just better shows the issue of the ui being cluttered.

And that's without a lot of stuff there yet. Like if we can't change the layout and it should be opinionated, does that mean the current changes we can make to the layout and make it useful for my workflow is just gonna be gone even more? If not, how is that different, this isn't great UX imo.

If we disagree here, please explain why.

All I see right now is that layout can already be melded with as is, not too differently compared to how you would do it in other software and in Hammer with docked in windows and so fourth. However, we have cases where one tool bar can be docked in, the other can't be, for instance. Seems super-super inconsistent and makes it not great. I agree that there should be a base layout that is literally the more comfy one, but the previous issues are still relevant.

It was pointed out that SFM is very likely to be a part of Scene editor eventually, so I as a person who does Hammer have to deal with that in my way. And considering Hammer stuff needs to exist in Scene, like it will clutter. I can see why people who are used to different workflows, won't like how I would like it, and vice versa. This can be quickly improved with just being more consistent with some of the tropes the UI already going with.

I think it's a completely fair concern that if it can't happen, in the long run we have SFM, HAMMER, whatever else, and then user made tools/subtools, all in one package just completely mess it all up and makes it very cluttered. One could argue that's why you would have them as separate tools to begin with, but since we want to just get it in one package, we might as well have a good middleground solution for those who want their workplace environment to be efficient for their needs/and what the team for that X project could expect from them. Especially as I said previously it's what the tool pretty much does anyways, just very inconsistently. That doesn't mean I disagree with standardizing the workplane environment, so out of the box it was already decent enough to work with, but when we have so much in one place, I think it should be a valid feature for people to have.

[garrynewman]

Lets wait until these things are actual problems and deal with them. We have enough real problems right now without inventing hypothetical future problems, too.