Blender 3.x roadmap
code.blender.org
code.blender.org
For 2.8, all the Blender icons were replaced with monochromatic ones. This is a very popular trend and a lot of programs are replacing their icons in this way, so it's obviously fine for most people, and I realize this is probably a niche accessibility need I have.
But, to use the new icons, I find I have to check each one every time to find the one I want. Instant recognition is no longer possible. For me, this extra cognitive load makes it difficult to use Blender for more than a few minutes at a time.
Blender is a fantastic product and one of the best examples of what open-source can be, but I for one will be appreciating it from afar, and remaining on 2.7 until there is a way to get more usable icons.
Blender has always been very keyboard driven, but I don't use it often enough to have most of the shortcuts memorized. Even those seem to have changed, though. I'm sure there is a setting in the preferences to restore the old shortcuts, but it doesn't really feel like an appropriate thing to do with such a complex piece of software.
I know Blender has a "reputation" for being difficult to use. It used to be earned, over a decade ago, and it was indeed an impediment to getting new users. I felt like--as even just a casual user--Blender had hit a good sweet spot of organized, predictable, and powerful. It's just the very nature of 3D modelling to be complex, and it feels like most complaints about its interface these days are just from completely new people who don't understand this.
That seems to be one of the dangers of Free Software. Having no monetary barrier to entry, you get a LOT more first-time users. Without the sunk cost of having spent several thousand dollars on 3DS Max or similar, they don't have an emotional incentive to stick through the learning curve yet.
I've spent so much time watching videos and being confused because the fields they show are not in the same place in the version I'm using. It's one of the reasons I choose to stick to the default preferences as much as possible: I don't use Blender often enough to know exactly what I'm doing all the time, so I want my system to match what other people are presenting.
It's not a niche accessibility need, it's a universal accessibility need that's been commonly understood for decades. Insufficient differentiation is one of the factors that originally drove the increase of colour count (and later, as display hardware allowed it, resolution) in icons 30-ish years ago.
This trend is not driven by universal preference for monochromatic icons but by the cargo cult that UX has become.
Also, Blender is not a grocery list app. While disregarding novice users does result in an application that's impossible to learn and that's obviously bad, it's equally unproductive to optimize an interface for people who see it for the first time. Blender is the kind of application that you spend tens, if not hundreds of hours learning before using it productively (let alone professionally). That's the target audience you're designing for, not people who download it and uninstall it if they get bored in the first thirty seconds.
Plenty of professional tools (Photoshop, Final Cut, Figma) have monochrome icons without it being a usability issue. These are all content creation tools, including Blender. The UI and content should not be fighting for attention. It's clear which of those two should primarily be on display.
I think it's entirely possible that Blender just has poor icons - but it seems demonstrably false that monochrome icons are inherently inaccessible.
My best guess is that Blenders real issue is a lack of structure and clear grouping. Providing the icons are in a logical place, it's easy enough to find the correct one, without them needing to be visually distinct on literally every dimension. But if there's no logic to the placement and the icon you're looking for could be one of thirty, then I agree that's an usability issue - just not that the icons are at fault.
GIMP did this too and it absolutely blows. Thankfully you can revert back to the "legacy" icons.
Oh boy. How I wish so much that other software developers would follow this principle... It seems nearly every software I use and rely on has to change its appearance and interface every 6-12 months, breaking familiarity for no objective reason, and simply because "it looks better" to look at (and not necessarily to use!) to the subjective eyes of someone.
Minor bump 2.7 -> 2.8 = everything breaks, your workflow no longer functions, you have to relearn the API, online resources and documentation no longer relevant for many aspects of the editor
Major bump 2.8/9 -> 3.0 = everything is compatible with 2.8?? Just feels like 2.8/2.9 and what's referenced in the blog post should have been version 3 to me, but maybe they had some technical reason regarding the backend and scripting APIs?
Prior to 3.x, the major version was the .X part and the 2 was somewhat meaningless.
E.g their versioning prior to 3.x is 2.major.minor.patch and will now switch to major.minor.patch
I've rarely seen a program maintain two UIs forever when they feel like refreshing their looks
Not that I mind UI change, but I think the comparison misses the point: if it's good enough, for some people UI breaks just cost more than they gain in the redesign. So it's not about reaching perfection. It's about finding a UI only just solid enough that it can stop breaking.
I don't necessarily agree personally, but I can understand that point of view.
You could alter vim in a way that people who have years of expeirience of computer use and browser use know at least how to quit goddamn thing without googling it. Or maybe even create short text, save it, open it again, move blocks of text around. For an average person vim has 100% less utility than the notepad.
The power of vim doesn't come from obscure keyboard shortcuts. It comes from editing using parametrized commands (as far as I understand). You could make modern editor with the same power as vim where a person can just sit in front of and start working with immediately and gradually learn that things she's doing manually she could do faster using command mode. And those commands might be the same as in vim because once you go beyond area of shared intuition you can do whatever you want.
The problem of vim is that it started in the era where shared intuition didn't cover basic text editing. And this area grew since then but vim refused to acknowledge this.
I do not see it as a problem that Vim doesn't supply the features you're describing, though I do understand where you're coming from. I am affirmed in my view when we remember that vim runs in a terminal emulator, and the features you're describing are non-trivial to implement in that environment.
I don't mean to sound pedantic, but I don't see this as a problem at all. As it relates to Vim, or many other tools and domains. If Vim was incentivized to increase the size its user-base, I may agree, but this is not the case.
If any of vim great ideas ever enters shared intuition about computers it won't be due to development of vim.
Ability to gradually transition between beginner user towards power user is natural way all modern software is written. That's why you have menus and can point things with mouse and often drag stuff around, and have a cursor and a text box where cursor keys and home and end and delete and backspace and shift works. And you have hints and indications of keyboard shortcuts. Plenty of stuff is discoverable.
You start with shared understanding and build upon that.
Some legacy UIs like Blender evolve and adapt to broadening shared intuition others like vim fail to.
I run blender headless in a docker container on google cloud run. When needed I invoke it with an image and have a blender script "engrave" that image on the jewelry and output an STL file.
It is incredibly flexible to script in python, although its not very "pythonic". The UI is quite stateful (edit mode, object mode, which items are selected, etc) and you have to keep track of that state in your program. But once you get around those issues you can do quite a lot, and its all a free program!
I know rendering can be quite heavy on a CPU, but it sounds like you're running a series of commands to generate a model instead
And I dont actually do any rendering on this instance, just the STL generation. I use Threejs to display/render the STL once its done.
I don’t do any of it myself, I have a casting partner who can do it for me. You can also find online services like shapeways to do it as well but they charge a lot mire than the real casting houses. Some casting houses I’ve worked with were the back ends to shapeways themselves.
There's a plotline for an episode of CSI crying out to be written here..
And you get to build a database for any state agencies that might be interested in buying (or taking)!
As opposed to building a database for private agencies?
And the metal is actually not 3D printed. How it works is the design is printed in wax first, this wax is then used to make a plaster mould into which the molten metal is cast.
Though there's a bit of an issue going on in that space right now where the company that makes the controller boards for the affordable consumer models has decided to DRM lock their file format and require all of these printers to use their proprietary slicer (Chitubox), locking out the generally better liked open source alternative (Lychee).
If that's an issue for you, you might be able to find an older model that hasn't been updated to recent firmware, but personally I'm waiting on any resin printers until we see how this shakes out. There was some noise about Chitu hearing the community and creating an SDK, but Lychee didn't sound very excited about it.
EDIT - actually it looks like someone has created a lost wax casting filament for FDM printers. Look for "MoldLay". But in terms of printing detail, for small jewelry type projects resin printers are still going to be the better choice.
But I kind of wish they had a "Blender Light", without all the features and config options, and with a less complex UI... I've been using Panzoid to do certain things, but Panzoid can't do rigging on imported object files...
I usually want to make animated videos in support of the music I release on my label, but right now doing so is either expensive or time consuming. I also don't want to put in film-studio effort or money into each music video release, because that is not a good business model, and my time is limited... The costs of being a creator are rising fast, only solid workflows will ensure survival.
Since Blender is open source, it would be possible for some other group to fork Blender and remove parts of the UI for users like you.
I really wish the core team wouldn't focus their effort on this. Blender is a professional tool for professional users. Having to balance between "dumbing down" the UI for first time users and providing a user interface for power users makes it hard to please either one of them, so I'm happy Blender currently focuses on the pro users.
Simplified software is suitable for simple, throwaway needs where the risk of choosing wrong and the cost of changing tools are low: yesterday I had to split a PDF file for the first and presumably last time in my life and I just printed it to a file by page ranges, without bothering to select, install and learn to use a PDF editor like Acrobat.
Mastering general, not "light" software is the only practical foundation for relatively professional "solid workflows" (as opposed to learning the basics of 3D modeling or something else with minimum accidental complexity); there might be a place for very advanced and/or very efficient but very specialized tools (e.g. MagicaVoxel, procedural generators of 3D models, Substance Painter) but only as an addition for equally specialized situations, not as an easy route.
I get what you're talking about, sort of an "iMovie" to Blender's "Final Cut Pro". I think 2.80 actually did a ton of work in that regard, if you've seen it since then. It could definitely be simpler though, and with the UI programming the way it is I suspect it wouldn't take all that much internal change.
Unfortunately, I think a lot of the reason it's as intimidating as it is is because the main aim for buy in for now is studios who favor the power user maximal interfaces of Cinema 4D and Maya and the like
> Being able to configure Blender for personal workflows is a key Blender target, part of the 2.8 project.
> To bring configuring even one step further, .blend files can be used to replace the standard startup file – creating ‘custom versions’ of Blender this way. These templates will allow to completely configure UI layouts, define custom keymaps and enable add-ons to run at startup. A smart Python scripter can design complete new applications this way, using vanilla Blender releases. As prototypes the team will release a couple of simple templates: a video-player review tool and the 100% dumbed down ‘Monkey Blender’.
> A template used this way will be called “Blender Application Template” or just “Blender App”. Planning is to have this working as beta for Blender 3.1, after extensive testing and reviews by contributors and module teams.
I think the bigger issue you're going to run into with "make Blender but simple" is that the subset of features that you want in a simplified blender is a different subset from what other people want. You want to do rigging on imported object files, but for somebody else rigging is a feature that would get cut out completely. They're just trying to model a doughnut and a coffee mug and do a still render of it, or at most animate the camera moving around the scene.
But even older hardware can use blender without even needing a good GPU as render previews have become quite fast. If you create models for real-time rendering, an older PC without some super GPU is quite enough to work with.
Now, these objects can be combined into a higher level organizational container called a collection. These, too, have a position, scale, rotation, etc, and behave much the same way as objects. They can even be combined into parent collections.
Now, what I would love would be to have them gain much of the functionality of objects that they don't currently have, most importantly modifiers.
Say I was building a well. I make a single brick, an object. I can array this brick object to create a wall, and I can add a corner to the wall, and add it all to a collection. Now I have this wall "object," and maybe I want to array it 8x around a center point in order to create an octagonal well. I can't, because I can't place modifiers on collections. For all intents and purposes, it is just another object, and would love to see any push towards allowing it to behave as such.
Say I was building a scene like King's Landing. For each building, I'd like to have a file representing that building, that I can instance around a scene representing, say, a city block. I'll do a linked import of the building, so any changes I do to the building will take effect around the scene, and I'd like to make use of arrays and other modifiers for ad hoc instance changes. Again, my motivations for wanting a non destructive workflow are completely the same, regardless of whether that building is an object or a collection.
Now, as of now, my only option is for it to be an object. However, what if I want to use a collection of other objects in order to build the building? I want a cellar door that I'd like to have instanced. I'd like a ladder outside, and a few barrels on the second story. I want these instanced for all the same reasons. My preference, of course, would be for the building to be a collection of all these things, but if I want to then treat my building as one of these such objects at the next higher level of detail, I can't.
So you're dismissive of my intentions by insisting that the difference is meaningful, whereas I simply see it as a failure of abstraction. Objects and collections are ultimately both worldspace coordinates holding mesh data, the only difference is if they're nested at all. And like I said, collections CAN be nested. That relationship is already established. Collections CAN be instanced, that use case is already established. It's really just the modifiers that are missing. And from a programming perspective, the logic of "get the mesh data from the object I've been assigned to in order to apply this transformation" is the only thing that needs to be tweaked. Rather than going one level deep, it will say "and if this is mesh data, stop, else iterate."
What you want would be less of an issue in a tool that allowed for a more procedural approach where the assembly of complex objects is part of a modifiable construction history that is separate from the final scene graph. In such a context, merging objects is technically destructive, but repeatable. I've written such a modeler once.
So it's not actually about the modifiers being able to be used for what you want in one scenario and not being usable in in a slightly different scenario; the array modifier is not really the tool for the job here at all.
The tool to be used for both of the use cases here is instancing, not the modifiers. Setting up your scene with multiple levels of collections and using proper instancing (which the array modifier is not) certainly is possible, there's just a couple of pieces of the puzzle that you seem to be missing (or unobvious hoops you have to know about, depending how you look at the UX).
Instead of arguing about philosophy and good UX design, I hope you don't mind me elaborating in a more step by step way on how to actually set a scene such as your example up.
You can spawn a collection instance at the location an "empty" type object, by selecting "collection" as the instancing type at the instancing section of object properties. You can have many of these empties and position them manually if you were so inclined.
The other thing is that you can use a mesh to spawn instances of an object at each face of the mesh. So you can create a mesh object, and set up instancing to spawn aforementioned "empty" object, that in turn spawns the whole collection, at each face of the mesh. (You do this by parenting the empty to the mesh, and setting instancing type to "Face" in the instancing panel).
This mesh would typically be rather simple, for example just a couple of disjointed faces scattered where you want your collections to spawn. Or just a single face, and mesh modifiers applied to it, such as array. So instead of arraying the collection, we array a mesh consisting of a single face, and each face of the arrayed mesh spawns an empty that spawns the collection, but the end result is the same. (No idea why each face can't be set to spawn the collection directly and we need an intermediate "empty").
You can also set instances to appear from particle systems etc, for example if you want your houses to just be randomly scattered on a surface of an object (like mesh in shape of the city or so)
The point is, the fact that you can do instancing through the workarounds means that there isn't a technical barrier to doing any of this. You say that it would introduce footguns to the UX, but I consider the workarounds to be footguns.
But yes, I do see the use case for collection level modifier stacks, I just don't think implementing those is exactly as trivial as you figure it out to be. Not impossible either of course (for example by doing some sort of copy-on-write thing if the geometry is modified), but it'd be introducting a different kind of copying mechanism with significant performance differences, which smells a bit footgunny to me
Improvements across the board. Is there even a subsystem that doesn't have big plans? Apart from physics, and that seems to be subsumed into Everything Nodes.
I was wondering how you might apply a Blender GUI layer to GIMP (I tolerate GIMP, but I love Blender). I imagine the issues run deeper than just the surface level UI? It would be a great experiment though!
The bonus of this approach is apple needed to directly sponsor+support blender to make it happen.
Awesome!
https://blenderartists.org/t/geometry-sketcher-constraint-so...
Can't wait for it to get even better.
I wandered around the website provided in the link above, but didn't find a simple explanation as to what Blender is about.
Perhaps adding such an explanation to the website can be useful.
- Render Engine
- Modeling, Sculpt, UV
- VFX
- Animation & Rigging
- Story Art, Drawing 2D in 3D
How much more clear could they make it?
"Modeling, Sculpt, UV Blender’s comprehensive array of modeling tools make creating, transforming and editing your models a breeze.
· Full N-Gon support · Edge slide, inset, grid and bridge fill, and more · Advanced sculpting tools and brushes · Multi-resolution and Dynamic subdivision · 3D painting with textured brushes and masking · Python scripting for custom tools and add-ons"
not sure what else they could need, it does exactly what you're asking for.
It turns out all those types use it (but I believe it started out for digital animators primarily).
In this case, a simple click on the Blender icon goes to their homepage, which explains it's 3D modelling software.