by William Reynish
The dust has now fully settled after the major UI changes that happened in Blender 2.80, this gives us a vantage point to look at planning Blender’s forthcoming next UI-related work. For this reason, a few Blender developers met at the Blender HQ in Amsterdam for a two-day workshop and planning-session. Among the group of developers were Ton Roosendaal, Dalai Felinto, Brecht van Lommel, Julian Eisel, Bastien Montagne, Pablo Vazquez and William Reynish.
Rather than going over every little detail that could be improved, we chose to focus on the major areas that will affect the user experience. Here is a summary of the meetings and sessions we had.
Asset Manager
Update: A refined version of the decisions concerning the asset manager design is here: https://code.blender.org/2020/03/asset-manager/.
What is an asset?
While the asset manager sounds simple, as you dig down into it, you start to realize that it deeply affects many areas of Blender. Questions like ‘what is an asset’ is not even necessarily straightforward to answer, nor are details such as exactly how are they stored and referenced.
We think of assets as an ID-type (Collection, Object, Mesh, Material, Texture, Node Group, etc) with a special ‘asset’ tag. With the asset, we can also store additional information, like a set of additional metadata tags, the author, rating and so on.
Library and Projects
We discussed the issue of assets by talking about several main use-cases:
- Library: There’s the use-case of using a central repository of assets for use as a starting point. This can either be built-in assets or a user-created asset library.
- Project: The second main use-case is for projects, such as movie. Here you typically link assets between blender files.
The two use-cases share some solutions but also have differences.
For the Library use-case, we had to decide how assets are stored, since we want to present users with something that looks like a library of assets. We think the best solution is to store 1 asset per blend file [edit: this is not correct, see the refined design], since then you can more easily share and delete assets from the file system. However, we would need to create a database cache so that browsing assets is fast and doesn’t require Blender to open each asset .blend to read the contents before you can see it in the browser.
For the Project use-case, we have the core issue that currently Blender has no real concept of a project to begin with. If you use the example of an open movie, you would want to link assets together within each project, but not between projects. And when you open Project A, you would want to automatically be presented with relevant Project A assets – not things that are meant for Project B. For this reason (and others) the first step is to add the concept of a project as a core concept in Blender. This is meant for any time you want to create something that spans multiple blend-files. This concept was also discussed with the Grease Pencil team for the storyboard/VSE project that is planned for the future.
UI Layout and Polish
The UI layer and front end to the asset manager is in many ways the easiest part to design (although not necessarily the easiest to code). We simply want to present users with a great browsing experience that is fast, searchable, and fun to use. Throwing on a wood material onto your model should be slick, interactive and feel tactile. Dragging furniture into a room should stick to the floor and not just float somewhere random in space. We agreed that we’d like to support these kinds of things, even though technically some of those are perhaps not necessarily strictly only for things coming from the asset browser in particular.
Brushes
A big part of the UI workshop was centred around the brush system. Brushes are currently a pain to deal in Blender because they are stored inside each individual .blend file. This means that after users have spent lots of time setting up a nice set of custom brushes, they will be lost when you open a different .blend file, and the user must manually append the relevant brushes every time. That is the equivalent of having to load your brushes every time you would open a new image in an image editing or painting app – it’s not ideal.
Instead, we would like to treat brushes more like we treat Material Preview HDRI’s – as global permanent items that live in your Blender library, and which can be used on any project. This sounds simple, but in practice it opens many questions. HDRI’s can’t be edited and also are very self-contained. Brushes can of course be edited at any time by the user, and can make use of things like textures that live in the scene. Making sense of this is actually potentially a bit complicated, but we think we have an idea of how it should work.
Brushes will be automatically loaded from the main Blender library. Any changes to them will stay local in the current Blender file. However, we would like to add a way to copy or override the brush for re-use later.
For more on assets, see https://developer.blender.org/T73366
Everything Nodes
One of the other big forthcoming changes this year will be the start of the conversion of Blender to become fully node-based. This not only has implications for Blender’s internals, but also the user interface. In particular, for this workshop, we focused on some concrete problems, as listed below.
Node Flow Types
Currently, in the Compositor and with Shader nodes, everything users see is what we call ‘data-flow’ nodes. Each node passes some data to the next node from left to right until we end up in a Compositor or Material Output node. At a conceptual level this is fairly easy to follow.
Because particle nodes is really more a logic-based node system than something like compositing or shading, the challenge for Everything Nodes and in particular the Particle Nodes system, is that we also are introducing two other types of connections that don’t represent data-flow at all: Control-Flow and Effectors.
- Data-flow Nodes
The nodes you already use in shaders and in the Compositor all represent a flow of data. Particle nodes will also include data-flow nodes. - Control-flow Nodes
These don’t represent data being passed from left to right at all. You can think of them is being a ‘condition gate’, and can essentially be read from right to left. - List Nodes
Not a flow, but simply a list. We use these for effectors like emitters, forces and events. They are essentially to be read as a list from top to bottom.
The challenge is to communicate the difference between these node types, their connections and sockets. We brainstormed many different kinds of solutions:
Inputs & Outputs
The other issue that the new node trees expose is the much heavier use of group nodes as a core concept. This is important, especially in tandem with the asset manager, because it means users will be able to more easily re-use node groups, and also that we will ship lots of node group presets for higher level functionality. Group nodes allows us to get a layered interface, where we encapsulate complexity, but these can always be opened and modified if users desire to go a level deeper.
The apparent issue we have here, is how to better handle inputs and outputs from group nodes. Currently they look just like normal nodes, but really they are a very different category. We can think of these as coming from a different dimension in the node tree.
Multi-item Properties
Making it easier to edit and view properties across multiple selected items, has been a long standing desire to address. For this workshop, we wanted to look at this in detail to make sure the proposed design was acceptable.
We already had a design for this, but we decided that we would rather do this the more proper way, rather than try and solve it as a quick hack. Doing this well has many implications for how to treat selections vs active items, and which panels and properties can even be visible when multiple items are selected.
Read here for details: https://developer.blender.org/T54862
The items above are not a comprehensive list of all UI improvements to be done, nor all the work being contributed by the community, but it gives a peek into what some of the core developers are planning over the next period to focus on to further advance Blender’s user experience.
William Reynish
Blender UI Team
Oh man i have been waiting for a proper projects management in Blender, i am so glad it’s on the list…now my next hope is for better rigging & animation tools with the everything nodes project…You guys have seen what people can do with the Animation nodes, now imagine that power poured into rigging powerful & fast rigs, Blender would become the Best of Best 3D Software ever created for mankind.
I am a long time blender user when it comes to shading in blender, the UI of the node has to be improved. (ex: the value adjustment inside the node) when working on the node interface for many hours and that makes your Eye got strain( maybe nor everyone but maybe 50% people) so my suggestion was other than connecting nodes, the value, and adjustment are shown in Side panel (example: Nuke and Fusion.) It will be help full. Thank you.
this is answering to a lot of thoughts I had reading the article about asset manager.
Hello,
I’m a product designer and for my concept modeling, animating and rendering I use cinema 4D. So this writing is a very biased towards cinema 4d.
In my opinion Blender has a lot of features already. And as of 2.8 the UI looks absolutely beautiful. What Blender is lacking is good UX – user experience(the system of how things work). The two are different and I think you already know this because I found this chart somewhere in the Blender artist forum that was supposedly made by a Blender developer.
https://blenderartists.org/uploads/default/original/4X/2/0/e/20e6a640bf1732a5faf7be6bcea00acf7e40b5d6.png
I have tried to migrate over to Blender 4 times now. First three were during 2.7 release cycle. The fourth try was with 2.80. That release was a huge jump forwards, it is now much more welcoming and approachable. I even managed to render out a few basic turntable product animations using Eevee renderer(without tearing all my hair out while doing it :) ) which is just a super killer feature(this makes 3D animations super doable with only one or two machines). Every other big render engine developer is hard at work on their versions of real time rendering solutions :) so keep up the good work !
But as a cinema 4D user I guess I’m kind of spoiled, because as much 2.8 offers by features alone compared to native Cinema 4D studio version the switch would be a COMPLETE no-brainer. To get all that functionality in cinema 4D I would have to invest extra money on many separate plugins. But as of writing this I still prefer Cinema 4D over Blender.
To quickly give two examples of poor usability.
In the outliner you have small eye icons that toggle the visibility of objects. Now, for example, if you have some mesh objects nested inside a cube object and you toggle the eye icon of the cube, then only the cube will turn invisible and the objects nested under the cube will be visible. Why is that? Usually in other software the cube eye icon would hide the cube and everything inside it. Take for example Photoshop(I’m sure people who use 3D have used Photoshop at some point in time) or Illustrator or Affinity software or various CAD software. Now I know that when you hold down shift and then click on the eye icon it will hide everything. But why this hidden modifier key for such a basic action that works differently in many other software?
Second is again about the outliner. Objects are still forced to sort by alphabetical order? Why is that? Again, many other software will let you place objects/layers what have you, the way the user would like them to be.
These things may be small compared to the features Blender is offering, but comparing the benefit they will have vs the development time needed to implement(I’m no developer so this is a wild guess :) ) maybe would be something to consider? I will write a more extensive user feedback in the forum.
Now coming back to the chart where Blender is compared with other similar software. In my opinion Blender is in a very interesting position at the moment. I kind of see Blender standing near a big red button and at the other end are the other software titles. The button has UX-Designer printed on it. It would be very amusing to see Autodesk and other companies reactions when Blender would become easier to use than for example Cinema 4D. Or even dare to aim at Sketchup ease of usage. Then Blender would become the de facto software for 3D.
I also get that Blender is and wants to be unique and that it does stuff differently than other software(does not want to copy others). It is ok as long as it will not get in the way of getting fast results( and by fast, I do not mean you have to learn all the shortcuts, but with a few clicks as possible). Get a great general result fast out of the box, but have all the tweaking power present in the menus.
Blender now has substantial funding behind it. My suggestion is that you hire at least one or two UX Designers who have never used Blender and are new to the 3D world in general. Don’t get me wrong, just hiring people will not solve this problem, but it would be a start. Great result in UX are very hard and painful to achieve, but I’m sure it can be done.
If I had to describe Blender in one word, it would be ARCANE. At least at the moment :)
All the best,
Ragnar Plinkner
NOt sure of the Burshes are in the part of assets or not. According to this article they are not, https://code.blender.org/2020/03/asset-manager/
Is the idea of the main blender library like have them inside the preset folder. THat would make sense. Would be nice if we get folder folders materials, textures, brushes, hdri’s. A user could start building his/hes “asset” library or tool library, asset is perhaps misleading here in conjuction with the other article. So perhaps library is a better word choice here. It would also make file much smaller, since data is linked. If that woud be the case.
1- Change tabs order by click and drop.
2- drag and drop objects in tall outliner.
AWESOME SAUCE! Really excited for the asset manager (it’s gunna be yuge!), and particle nodes (already pooping myself). So glad to see a strong design/UX approach to developing these features, blender has come so far, keep it up!
Also, making toast is a HORRIBLE idea, why would you ruin bread by burning it when it’s already been perfectly baked in the oven, does NOT make sense IMO (just say’n :D).
How about making so everything is possible.
If you want to store them all in one file. Or individual files.
My only concern is that files will be unnecesarily big for the data in them.
How about if its just a material. The file will not have anything but the binaries of the material and maybe some metadata. But it will not a full blend file. Maybe a .bmat file or somethin
I’m curious why a conditional should require right->left visual flow? If you have some condition required for an outcome, it has a cause-effect relationship. Something like:
if(cause) {
effect
}
If that’s so, then couldn’t you have a condition that leads to an outcome in a left->right fashion? The effect would simply be an Observer of the condition’s output.
Have the blender team had a look at the Tyflow interface?
There are some interesting node like interface solutions that could help/inspire and solve some of the everything nodes design issues.
You should consider looking into Bitwig’s (digital audio workstation) user interface for their new node-based/modular synth “Poly Grid”.
Two images:
https://imgur.com/a/341rDB9
Nodes are great.
Creating meshes and changing the modeling and other transformations with meshes will also be on the nodes over time, like in Houdini or Maya?
Regarding nodes / node groups:
It would also be really useful to be able to control node properties via group inputs, and perhaps even to have “callbacks” (nodes that implement a particular interface) as group inputs :D
For example, right now it’s impossible to make a reusable parallax mapping node group, since it needs to sample a texture multiple times.
For Everything Nodes, PLEASE make it a goal to make the system as visual as possible, with graphical controls for different parameters.
One good example is how you can see interpolation in Animation Nodes, but it needs to go a step beyond and allow numbers to be controlled by manipulating points on the graph.
Artists like me get so easily lost in our own node setup, redialing individual parameters to figure out what was set up for what. All effort to make the whole experience as visual as possible would be very much appreciated, and I would assume make things far more efficient.
Even if internally an asset is a .blend file isn’t there merit giving it a new file extension? It’s more clear to the user what the file is and it gives you the freedom to change it in ways that would break a .blend file otherwise. For example, removing unnecessary parts of a .blend like UI setup (I understand that can be an Asset) or add features that are irrelevant to a .blend but are vital to an asset. I understand that by naming an Asset the same as a .blend they share the same code base and is thus simpler to develop, I’m not saying that shouldn’t be the case, just that the name should be different.
We considered using something like `.asset.blend`. The sole reason would be as an indicator for users, I don’t see technical benefits. It’s something we can easily do.
A blend file is like a “project” file, binding all asset files together. Essentially you can think of current IDs as “always packed” asset files. I think a custom file type per asset type might even be interesting as a solution. This way you could store thumbnails etc in the file itself and it would be self-explanatory and easy to load. More code for the loaders unfortunately but it’s code that you can share.
And yes, as Pablo writes above it’s common for other editors to load asset databases at startup. It takes some time but not that much (maybe a few seconds for a few hundred thousand files) and if you thread the system it won’t even block the UI either.
Multi-item is very good. also an option to copy paste transform values.
Great stuff, you guys rock!
In term of nodes UI, I think that a scary part for beginners is to confront the huge list of available nodes when trying to add a few and construct a node tree. The listing UI in the modifiers system is a great solution to that: Icons everywhere. They look insignificent, but they are extremely helpful as a visual clue for the purpose of the Icons in the modifers list and icons after you added them. Also, when hovering over each and every modifier, a simple and short explanation pops up.
I know that its really unreasonable to expect a unique icon for each and every node, but maybe for each node category there would be a unique icon in the list and on the node itself after being added. And as with modifiers, a simple explanation for each node would help immensely.
And again, thanks for developing stuff with dedication and passion for us each and everyday. Thank you!
I also think that needing two ways to read a node tree: from left to right and now also from right to left will be confusing.
“Cause –> effect”, (or “If X, then Y”) from left to right seems logical. There are some visual programming languages out there, like in Unreal, I believe most also go from left to right.
Great writeup though! Can’t wait for a functioning asset system.
IMHO having control flow nodes read right-to-left is a horrible idea. That’s completely counter-intuitive to how we usually read and to how things happen, as the example illustrates: “Kill particles <— Execute on birth" is completely backwards to how we as humans would interpret the chain of events occuring.
"When X then Y" sounds more easier to follow to me. Also, consider big, complex graphs: To understand the data flow we would have to read it left-to-right and to understand the control flow you have to read it backwards. Many times, data and control flow are related to one another. That's really confusing and inconsistent design. Please reconsider this choice!
Overall, I would recommend looking at how Unreal Engine implemented it's node-based system called Blueprints. In my opinion it's very well designed and done. For example, if a node has control-flow pins they are always listed first in the node as a general convention.
There has been a great deal of discussion on Devtalk with Jacques and the proposed system with control flow nodes going right to left is well thought-out. It takes figuring out but then it does make a lot of sense.
The direction things are read varies from culture to culture, the most obvious example is Japanese being read from right to left. It seems to me that working with any software, specifically node-based, requires a bit of rewiring of how you may naturally expect something to work.
Lots of things in complicated applications don’t immediately seem intuitive, it takes a bit of time to learn and get used to how an app works. Thus the importance of the UX/UI, so that the way it does work is clearly communicated to the user, and thus more easily learned and remembered.
For me, it’s not so much about right to left flow. It’s about the idea of having a singular flow direction vs multiple flow directions. If you look at classic programming flow charts, there are benefits to having conditional gates flowing the other way. There are pros and cons to either flow paradigms. Multiple flow directions adds more power/customization, but adds more complexity. Singular flow has less power, but is simpler. It’s sort of subjective which design philosophy you favor.
Edit:
I suppose there is a compromise where you use condition gate’s output to maintain a single flow paradigm at the input and output connections, but would make it somewhat difficult to visualize a loop back to previous nodes in the chain.
I agree strongly. I’ve personally fallen in love with Unreal Engine 4’s node based visual programming system. They use one-directional flows and it works perfectly fine for even the most complex program flows.
Also, allowing bi-directional flows will add unnecessary potential for confusion for users. Especially new ones.
Here is an online repository of a couple Unreal Engine 4 scripts made public for reference.
https://blueprintue.com/blueprint/3pt3b1kt/
I think the best option to display node flow were the one with arrows right at the node connection. This will be useful for stranded unconnected nodes or when nodes are far apart from each other.
For the list nodes, maybe take some inspiration from the classic layering system in other graphics apps? Lists are easier to manage in a layer system. Since they are top to bottom you can just stack them in one window. Each ‘layer’ will have a corresponding node connection. I think this design would also be consistent with a future texture/painting layering system in a node system since that is also top to bottom (or bottom to top). Having a list in one window (node) will be less confusing in terms of flow paradigm.
Regarding one asset per file, that’s not a requirement and not an essential part of the design.
If you have a .blend file in your asset folder that contains multiple assets, they would all load just fine. If you’re manually creating and saving those .blend files it makes sense to bundle them together as well.
Where it would create one asset per .blend is if you want to quickly save e.g. a nice material or mesh for later reuse, by dragging it into the asset browser. At that point it’s simplest to just save that to its own .blend file, because where else would you put it by default? Putting everything together in one big .blend would be inefficient.
But if it turns out there is a big need for it, it’s compatible with the design to offer the option of saving it in a specific .blend file or have tools to easily merge such asset .blend files. The idea though is that you don’t necessarily even have to think about where and how library assets are stored.
For project assets, on the other hand, we’d leave full control of file and folder organization to the user.
More technical specifics about the asset manager design are here: https://developer.blender.org/T73366
I would look to Daz Productions and Daz|Studio as inspiration of how to handle tons of dedicated library content, but definitely not how to organize said content. (The artists each have their own organization structure, and the whole thing gets mashed wherever and however they want.) Having a search feature would be crucial.
Seeing as Blender is community driven, it would be neat if someone devised a manner to offer a distributed repository to the masses, but I think that’s an enormous security risk. We don’t want Blender to become a virus transmitter on the levels of Limewire and Kazaa.
Don’t forget about rigs &animations, anim clips, Rig poses, shots..etc not everything is a static mesh :)
Great ideas.
with everything node, we may want a visual indication on what part of the node is stored as cache and don’t need to be re-calculated on every updates
Bests
Mmmm I agree, one file per asset could mean having a folder with 3 million files… that could go horribly wrong :P
* Assets live in the asset browser. You wouldn’t even see these files unless you go look for them in your file browser (like other softwares do).
* Naming is automatic of course and not always relevant (e.g. you’d see the material name not the .blend file name).
* Versioning: Having assets as individual files is good for versioning, so you can share/commit/update/revert assets individually.
* Team work: If someone is working on that file, it could be locked to prevent multiple people working on the same copy, if multiple assets are in the same .blend file then they all get locked.
* Faster: If I want just 1 material from a .blend file that also has textures or actions and other stuff I don’t need, it can be slow.
Ooo and also collections as an asset! Super neat!
I can have multiple trusty rock/limb/kitbash/whatever multi-object collections waiting :D
Thanks for explaining that, I was on the fence about this, but now it is totally clear that individual items per file is the way to go.
I’m still on the fence about this.
For “Team Work” the USD model/format is perhaps better and more forward looking? I would consider having 1 asset/blend a workaround more so than a positive :)
Also, if .blends are going to be used behind the scenes, than they _really_ really need to shrink in size. 550k for a single cube is not very nice…
This seems to make sense from the point of view of the asset engine, but how would it work from an asset creation/editing point of view? If I’m working on a file with a number of things in it, could I save an object as an asset, and it splits off into its own file at that point?
In other words, is the single file concept ever something the user has to deal with, or is it purely an internal concept?
one file one asset is definitively the way to go. Imagine having to sync a library over the cloud with hundreds of gb in size only because you decided to change an asset name. Having the library split into multiple assets avoids that and gives security if by some reason a file gets corrupted, is better to loose just one asset and not the whole library
> one file per asset could mean having a folder with 3 million files…
Necessity to read a humongous file with 3 million models inside instead of one required is also not a really prosperous option.
one file one asset is definitively the way to go. Imagine having to sync a library over the cloud with hundreds of gb in size only because you decided to change an asset name. Having the library split into multiple assets avoids that and gives security if by some reason a file gets corrupted, is better to loose just one asset and not the whole library
One asset per file sounds horribly clunky. Who’s going to name all those files? What about relationships between assets. Like let’s say you have a tileset for a game, and some tiles only fit with some other tiles? Or a character rig that is only meant to work with some character models and not others? How are you going to make these relationships obvious if you can’t just put the assets together, or assemble them in 3d space?
And there’s really nothing to be gained from interacting with the assets on a filesystem level, that’s just asking for trouble. Someone’s going to make a mistake, delete the wrong thing and lose hours of work. You have to be able to inspect the asset, in 3d, view the metadata, and then decide if you want to do something with it. Windows Explorer is just not suitable for this purpose, and that’s why we need the asset manager in the first place.
I don’t really care about naming it as long as you can automate that in your studio pipeline and write python scripts (and create add-ons) that will take care of that.
Ans you still can have a scene file including multiple assets, right?
I agree, one asset per file is not always desirable. While I can see situations where it may be advantageous, enforcing it is very limiting, and may be detrimental for certain workflows.
I’m thinking mostly asset families like a furniture set of matching objects, a collection of related game assets, kit bashing sets, modular game tiles, among others, where related assets are often created/managed together.
Forcing one per file will definitely add some maintenance work separating them, materials and common parts cannot be easily shared between assets, with a growing library it will eventually add up file system overhead.
What about variations? Would these still be in the same file?
IDK, many currently existing Blender add-ons for asset managment using exactly the same approach with the previews and it works just fine. Only issue is that those files are small and it can be a bit longer to load all of them from the slow HDD.
I suspect there is likely a misunderstanding in here. A “single Asset” per file does not necessarily mean a single object. A tileset is a good example of what could be a single asset consisting of multiple sub-components.
I do think the one asset per file solution makes sense. It seems people are struggling to see it with the current mindset. Having one asset per tile in the tile set example is actually more problematic than one asset per file in the future system. When you start thinking of assets as procedural generators rather than predefined objects, things get much more powerful. You could have a customizable tile set generator asset that solves all those edge cases. Having one asset per file/tying it into the file system is also a good way to go. It could be more easily integrated with existing version control/asset manager toolchains.
If you haven’t already, please check the revised notes for the decisions concerning the Asset Manager project. It was posted a few days afterwards, but it corrects that statement and clear other points: https://code.blender.org/2020/03/asset-manager
In order to prevent spam, comments are closed 7 days after the post is published. Feel free to continue the conversation on the forums.