I am writing this post with a concept that maybe can be considered for implementation in future improvements in Blender and it’s about general UI breakdown. Though may be a tough bite if code isn’t structured all that well . The impact I’m going for is mainly increased acceptance in professional circles, simplification of single user projects and flatter learning curve. While these things are somewhat possible to achieve in blender as-is, there are some other considerations as well, for instance good old fashioned convenience.
- To retain all current functionalities
- Simplification of workspace(s)
- Multi user co-working on same projects at the same time (parallelization of project developments)
- Speeding up work process
Method of achieving these objectives:
Simply put, split up work environments for particular tasks within the same package called Blender. Let’s call them “Studios” for some odd reason. Usual work process (simplified) consists of steps that include modelling, texturing, lighting, rendering, compositing,… So why are all these steps (each of which is complex by itself) always crammed all into one screen?
There is virtually no need for user to see texture editors while modeling. There is no need for user setting up lights to see texture editors (and vice versa of course).
So imagine something in terms of how FreeCAD approached the problem. For whatever job you need to do, you have a separate, isolated workbench where you can do only things that are specific to that workbench:
But here is where it gets interesting. In all the workbenches, you are working on one and the same thing (let’s say same body for simplification reasons).
So here’s where Blender could really profit from this idea. When someone is working on models, they need only tools, shortcuts, models,… for models and virtually nothing else. Someone doing bones rigging need to see the model, but don’t need to influence it in a sculpting sense. When a person does textures, they don’t care about bones and meshes, they need UV wrapping etc. So you may have a “Modelling studio”, “Lighting studio”, “Rigging studio”,… Just for that purpose and all of them toggle-able with a most simple dropdown. Nothing more, nothing less.
Of course that is not 100% true because users do need to see what they are working on and need to see the effects that other people or other activities make of course but it can be limited and tailored to that segment.
So let’s say user does textures. They need to see the model for sure and could toggle between the model itself for the speed of rendering benefit and whole screen to compare the look&feel of the textures applied. They may need to perhaps alter the model in a destructive manner to see inside some nooks and crannies how the texture fits but should in no way impact the mesh itself in a permanent manner. Reversible with a simple button click. What you have now is work environment specific for the job at hand and furthermore could be customizable and portable so users could load their “profiles” to have their buttons set up just the way they like them. But for exactly that particular workspace, no impact on the rest of the “team” or workspaces.
User that sets lights can do so when the basic scene is set up even without textures being in place yet.
And all of them can collaborate on a project and iterate and refine the final outcome much like cycles refines the image
So this is the UI part of the equation but you can also go a step further and allow for small companies and bigger type businesses to have a central server in their building, create a project, assign users and their access rights to that project and thus allow them to “push-commit” their work to a joint project at the very same time that other users are working on the project. Massive parallelization options. Very little network traffic.
Basic requirements to complete the concept proposal:
- Ability for multi user environments so users should be introduced but can be contained locally inside a company as well as their potential system of rights - should we get nit-picking or just have one global user.
- Division and re-design of workspaces/workbenches with some cross linking of non impact functionalities so they can do some needed things outside their scope but not for production output.
Additional possibly beneficial aspect (outside the scope of UI):
Since many people have a lot of spare metal lying around, an integrated option for network rendering would be most welcome. This should come by default so that when kids are asleep, their top gaming metal parts can do some constructive work as well
Alright this took too long to write :). To recap in a nutshell what I’d love to see is a simple dropdown or two where user can go from one task/job/step in the creation process to another and really focus only on the job at hand. No other button in sight apart from those which are needed to do that specific task. Big space to edit flow diagrams for effects or composition, nice 4 spaces to see all 4 views when modelling, nice texture tools high and wide so you can focus on the pixels etc. A whole lot can be imagined in this sense of separate “Studios”.
That would be my personal want-to-see-in-the-future recommendation because I think Blender is an awesome tool but UI is always too much to enjoy. I rather have a gazillion tools for just the task at hand then seven gazillion tools for everything at any time because I am not doing everything all the time.
Alright, that’s it.
There are two other proposals it seems where users proposed hiding properties and sculpt workspace separation but I think each of them have simple issues that hinder overall benefits.
If you take one step out of the whole equation, you neglect the concept of the workflow and that should not be.
If you simply filter out properties and “redundancies” in the sense of what you’re doing, you are inadvertently exposing the UI to be either over/under filtered and also the changes are destructive to the project in case of misaligned filtering.
My proposal consists of full “physical” separation of workspaces so that no mistake can impact the whole big picture as well as allows revision traces back to the user(s) that commited them as well as collaborative work and finally room to grow from the concept onward because there are other new possibilities with it as well that can be explored in terms of development and interaction. So I wouldn’t classify my post as possible duplicate due to nature of implementation and the scope of changes and possible benefits.