Blender Feedback Survey Results 2024

Announcements
41

Hi guys,

For me, it’s incredible to remember the entire path that Blender has taken since I started using it (2.3x).

But sometimes I feel that the priorities are a little unbalanced.(my perception as a user, does not mean that it is actually like that)

For example, Principled BSDF V2 has been out for a while now, but we still have some features, which I consider basic, that are still in limbo (nested dielectric, thin sheet mode).
And I know there are complex workarounds to solve it.

Or for example, the fact that it is not possible to simple rotate a texture with box mapping, and there is an issue about this in the workboard for around 10 years. And again there are many weirdo workarounds but we really want to go that way?

I used these two cases just to illustrate the point of view. While we have incredible innovations in very specific areas, we still have some broken or incomplete workflows.
If users report this, this is marked as know issue and goes to limbo which lead to… frustration.

I think that somehow we should try to rebalance development focus so that finishing or polishing open features received more regular attention.

Happy blending to all! :wink:

10 Likes
42

hey, as someone else who’s lurked for not quite as long (2012, so probably 2.47 or so)
in areas like this, the best solution, is to learn to dev and contribute, yourself. It’s often better than paying for development, because it doesn’t cost anything, you learn to dev, and you get the features you need! For example, I was having trouble making my normal and bump maps work, but it turned out it was because of an artifact with the bump terminator smoothing algorithm.
I learned just enough C++ to fix it (or at least do enough to give the devs who knew what they were doing an easy set of corrections to some poor syntax and math simplifications to a working algorithm), and I’m now training more and looking for related issues to solve. That is the reason blender is open source. One person’s needs are usually many people’s needs. If one person who needs it solves it, everyone benefits.

This is the way.

In open source, you can’t quite expect a single person to be able to complete or maintain a community requested module alone. Mantaflow gets some new devs after half a decade, layered textures got stuck in discussion, it happens, but I find the only way to guarantee development when you want it to happen, is to do it yourself, only open source has that option.

Now, as for being able to follow up with a survey to complete or finish stated goals, that’s important, and I do think we need a little more accountability as a community in that respect. That was the impetus behind an idea posed a while back, about bounties, and perhaps that’s what voting with a wallet should be. Most should go to the blender foundation, but some (15%? 20%?) should be set aside to inflate a bounty on a feature. just an idea?

We should probably return to talking about the survey itself, and spin off discussion about funding schemes, and a renewed push for listing and finishing nearly-complete features into their own threads.

8 Likes
43

RE “do it yourself”: my PRs have been mostly rejected as the devs do not want to have to maintain legacy systems (particle hair, dynamic paint, etc) despite the features I need not being planned yet for the replacements. So sometimes even doing it yourself is not going to fix blender. I maintain my own branch at the moment.

(Not that I’m accusing you of this, but in the past when other people have told me to do it myself, what they really meant was to shoo me away and close the conversation by putting the ball in my court, and then they are surprised to find that people actually have tried to help and been turned down.)

As for the survey, what I really want to know is: what’s actually going to be done with the data? E.g., Texturing (texture paint) is one of the top items, yet it has been deprioritized in the 2025 roadmap for the sculpting/painting module. Is this going to change? Is there going to be further info collected on exact pain points in eevee-next? Where will a roadmap/plan be published based on the survey? Etc.

In my circles at least, a lot of the angst around eevee-next is the perception that the devs just kinda do/did their own thing without consideration for the users. I know this is not true, but the perception is there, especially as eevee-next was pushed into 4.2 despite breaking some workflows.

Some sort of traceability from the survey data to actual results reflecting the survey data would go a long way towards repairing that trust. It’s the same issue I have with Right Click Select. I feel like it would be helpful to celebrate in the release notes, loudly, that a certain feature came from RCS or the survey data. Otherwise people aren’t going to take the time to answer if they don’t think the data will be used.

16 Likes
44

This is a very important post.

I’ve been pretty vocal about, and support a lot of these points in the past as well. And just to make sure: Blender has improved tremendously on many of these points over the last four years. Like - a lot lot. You can see that in the wide industry acceptance as well, I think.
BUT they are still very important points to make and be aware of.
From my personal perspective that “being heard” factor from the userbase is still one of the most important aspects for any production software. Yes, of course it also has to align with company goals, available programmers and budget etc. I don’t want to state the obvious in a lengthy post again :sweat_smile:

It’s just that it’s important to keep that in mind.
As such I also welcome the improvements for future surveys and the discussion of the 2024 results. It’s great to read all about it and how it’s planned to improve in the future. But RCS as a bit of a feedback/idea grave still remains somewhat of a painpoint for me as well in all of that.

2 Likes
45

Yeah I’m thinking that a much better integrated “request” system (compared to RCS) would be much beneficial. That, or an accepted workflow to submit “issues” that are not literally bugs. This is me talking as a blender contributor actually: it is a bit sad that when someone hits a literal bug, there’s a good workflow (file an issue; these are triaged, teams/modules pick it up, fix it), but when it comes to “anything that is not a bug”, there’s either the RCS graveyard, or trying to create a viral thread on social media / viral video on youtube so that someone starts to pay attention. Sounds like much less than ideal workflow.

33 Likes
46

The survey asked which Blender interface language they used, but I think that should pair with asking their primary language (the “language they use at home”). We need both to know if we are meeting their needs for translation. In many cases their language can be guessed from region, but not always - India, Belgium, Canada, etc.

1 Like
47

Thats not conclusive.
I use English UI and i highly encourage anyone who speaks at least a little English to use English as UI language over their native language, because of offtopic reasons.
If You wanna ask about wanting translation improvements, then just ask straight.

48

Thats not conclusive.

We can do both. But I’d still like the data.

In my own country of Canada it would be quite telling if any native French speakers didn’t use the French translation. We don’t properly support right-to-left languages like Arabic or Hebrew, so knowing how many of them there are can help steer time and resources. Many of our translations are quite incomplete so it would be nice to correlate with that as well.

2 Likes
49

In our studio we call them “Workflow design issues”.
Handling them require a workflow designer, it is hard to find them.
Extremely hard wok, that require lots knowledge of the entire periodic table of existing interaction systems, their purposes and history (the industry demands/attempts/flaws), different implementations, experience in using them as a result implies being subject to the Dunning-Kruger effect.

It is much easier/profitable to became a professional in some specific area (where you have to learn how to do some specific stuff) than to became a wide range workflow designer (where you have to learn all the possible ways of doing stuff)

1 Like
50

Also nobody sayes that unresolvable workflow design issues does not exist.

For example, one of the reason I abaddoned Autodesk camp at the peak of its popularity and even started support Blender development because it successfully resolved lots of industry level workflow design issues that was originally considered as unresolvable.
I am trying to evolve in that direction for a couple of decades, but as a workflow designer I am not even close to system design power and intuition of Ton.

(he often try to convince me that I overestimate him and it was more like a coincidence, but when I tried to resolve similar problems by myself I totally failed, so I find it physically hard to believe in such kind of coincidences)

1 Like
51

Thanks everyone for the feedback! I’ll keep following the thread for a bit more and then wrap things up. Will open another thread before starting the next survey.

10 Likes
52

Will there be any discussion on how the survey data will be used?

I am particularly curious how “Texturing” as the highest rated pain point in the survey data will be handled when it is currently deprioritized in the 2025 roadmap: Sign in - Blender ID - blender.org

3 Likes
53

Users are binded to the software through workflows, enhancing texturing workflows could be profitable in terms of encapsulation (which assumes using software separately from the others), however such kind of task is rather deep, and might require resources that are not available at the moment.

Speaking of a survey, I found interesting the amount of users that came from AutoCAD.
At the concept level Blender shares a lot with it (semantically it behaves like if 3dsmax was made on AutoCAD-like chassis, which originally was expected from Autodesk), so such an amount, gained even against the marketing, suddenly fits expectations…

54

In regards to painting and texturing it is not specifically stated in the survey. My assumption would be that many users in animation/visualization but especially games are still looking for an alternative to Substance Designer and Painter. The competition is still very much lacking in this area and especially in high quality OpenSource. From the questioning in the survey a lot of this might be muddled into the bigger block of “texture and materials” even though that could also mean a few other directions.

Especially big topic blocks always include the caveat that a participant might have a very specific case in mind because it fits their own current needs but the survey was meant to go in a very different direction under the same overaching theme. I’ve had that a few times myself when a blogpost announced work in an area and I got all excited but very soon relaized that the specific work in this block was on an entirely different end than what I expected.

6 Likes
55

On one hand, I agree that it could cover a lot of ground, but to me the most obvious answer is that texturing refers to texture paint mode, which has been plagued with performance issues for a very long time and is infamous for such. Put another way, I’ve never met an artist who didn’t have issues with Blender’s built in Texture Paint mode. It’s well known to be a pain point. I think it’s reasonable to assume that’s what people would like to see improve.

There are dozens and dozens of feature requests for it on RCS. Debates about multi-texture paint features crop up regularly. Bug reports about texture paint slowing down and freezing blender on large textures are common and are usually closed as known issues/duplicates. Reliable texture painting is the most likely interpretation for the survey results for me; it is clearly a need that blender does not meet and to see it de-prioritized again is disappointing.

Figuring out potential alternate explanations for what survey respondents meant by “texturing” could be useful, but I really want to know what is going to be the next steps from the devs with this info in hand.

Are they going to refine the survey to find out why so many people responded with texturing as their biggest workflow issue? Are they going to adjust priorities? Are they going to ignore it for another year?

1 Like
56

I completely agree.
I believe the most outdated part of Blender is the painting system.
3D brushes are only available in Sculpt Mode, and the performance of image painting in particular is quite poor.
There have been ambitious plans for a dedicated Paint Mode for several years now, which I was excited about — but development doesn’t even seem to have started.
This is especially puzzling because Blender has the unique advantage of blending 2D and 3D workflows, making it popular for a wide range of stylized work.
So I can’t understand why this area has been neglected for so long.

57

This is where I’m coming into blender dev from. I use it professionally, as a side-gig, but I have a rebellious streak a mile wide and when something doesn’t work, or could be better in a way I don’t see anyone else noticing, I get this fiendish little urge to rally the troops for it, or at the very least poke around to see how I could do it (usually ineffectively).

for example, the baking workflow needs some serious love, but while that’s happening, editing datablocks directly would both make it far easier, and offer more pathways to do it… and would also lead to an internal media browser, which is an idea I’ve had since I tried comparing the NLE and viewports to davinci, premiere, godot, and unreal… they all have a panel just to browse imported data. I’m mentally exploring it as I work on other, smaller issues.

I use Blender for 3D printing! I have setups that allow me to use it like CAD software with booleans, but modeling software for the basic blocking, and animation software for mechanics! There’s a lot of potential once rigging nodes becomes more robust!

exactly this. ArmorPaint was looking promising, until the developer abandoned it to work on their game engine instead (still salty about that…) this is why dedicated “layered materials” was such a hotly requested feature, even though it’s technically already possible with just some mix nodes. I am also a proponent of bringing back texture nodes, though mixing with or angling it toward the painting, UV, and baking workflows

yeah, my OG idea for bringing back the texture node system was as a dedicated, optimized system to generate procedural noises as assets, that could be used for painting on UV’s applying to volumes, or using as fields for attributes and physics to react with… but right now, I do think something like substance painter would be best. Blender has a fantastic toolset for making materials procedural, but its system for simulating texture data (dynamic paint) has an odd combination of intended uses and vertex paint features.

if texture nodes comes back, doing things like simulating liquids collecting in pockets and gaps to make rust, then baking the result, or letting the simulation run actively during the scene, for timelapses or stains, or even soaking fabric. It could also be implemented as a set of geometry nodes that produces a texture output, though I would like if it wrote to texture data, not geometry data. It would be like the ever-present “pointiness or AO for procedural materials” workflow, but far more useful and controllable, because fidelity would be based on texel density, not geometry, and physics could give the material more lifelike aging

2 Likes