Blender 3.2.2 Released
blender.org
blender.org
It started off with great features, but really difficult to use (for non artists), yet has gotten much better over time.
The number of features grows faster than I can think of uses for them, but it is nice to know they are there.
Edit: It does have recent commits though, maybe it's better maintained than I gave it credit for.
Blender 3.2 - https://news.ycombinator.com/item?id=31668274 - June 2022 (89 comments)
Blender 3.1 - https://news.ycombinator.com/item?id=30617723 - March 2022 (128 comments)
Blender 3.0 - https://news.ycombinator.com/item?id=29430498 - Dec 2021 (248 comments)
https://docs.blender.org/manual/en/latest/editors/preference...
https://docs.blender.org/manual/en/latest/editors/preference...
-- Why would anybody zoom elsewhere than to the mouse position?
I have done a lot of interactive application design over the years. Not "games", but the underlying tech is very similar. Combining mouse and keyboard input is almost always a mistake for anything but the most basic, narrowly-scoped, get-this-done-now kinds of indie first-person-shooter games.
If you ever want to develop a system that is maximally accessible to different input modalities, you have to treat the mouse and keyboard as completely different devices that aren't related.
Because, for a large number of people, they really aren't.
It leads to bizarre, and almost unplayable, keyboard mapping schemes for what should otherwise be good games.
The most recent example that comes to mind is Moonlighter: https://steamcommunity.com/app/606150/discussions/0/30438595...
Unfortunately with that example, the dev's doubled down and didn't address the problem, rendering it pretty much a useless port. :(
It's not just indie games, though. The Final Fantasy 7 remake has a gamepad-first/keyboard-shoehorned-in input scheme. It makes the game nearly unplayable.
Say you offer a config option. Now the program has the "wrong" (unintended) behaviour in some cases and you insist the config option should be changed, but now it has "wrong" behaviour in other cases. It's infuriating, why doesn't it just work?
OK, let's fix it to work one way. Now if we obviously intended the other thing, it never works and there's no way to change that, still infuriating.
OK, let's offer both with separate keypresses. Now the user feels like you're saddling them with the problem instead of "just" solving it. This stupid program has two zoom buttons, and whichever one you use it's always the wrong one.
(Unless they are in an environment where they regularly need to interact with other people's machines. Which can be solved; when I worked in an animation studio we had a standard set of key shortcuts for things that Flash didn't assign keys to out of the box so that a director could hop onto anyone's computer to edit a scene and be confident that, for instance, slamming numpad-0 would get them the very frequently used Free Transform tool.)
(The user may also have to think about it again when a new release comes up with an exciting new way to be "wrong"; if a prefs switch was not provided along with this new behavior then the result will be a new top-voted bug on the public bug/feature tracker, and people reverting to the previous version until the .1 release that grudgingly adds a switch. Or swearing a lot and deciding it's time to have a look at the competition if rolling back to the previous release isn't an option.)
The other behaviour is also wrong. That's the whole point.
I used the window focus example assuming people know what I'm talking about but maybe that's now too obscure (which makes me feel old) so I'll explain it more carefully.
The correct window focus behaviour is called "Focus follows brain". Here's how it works, it's pretty simple: When you press a key, the window you were intending the keypress for reacts to that keypress and no other windows. That's all.
This isn't achievable because it involves mind reading, some sophisticated realtime brain scanning might be tried, but chances are this will reveal what you were looking at, and we know sometimes people do not intend the focus to be what they were looking at so that technology is too primitive, we need mind reading.
The most common focus behaviour today is called "Click to focus". This lands the onus on the user, whichever window you last clicked on has focus. Sometimes you will realise you "forgot to click" but that's really a symptom of the bad focus.
An alternative is "Focus follows mouse" in which the window focus goes wherever the mouse cursor is. This can feel better, since you're not clicking on stuff just to give it focus, but it will still get tripped up (and it's even more confusing for people who've learned "Click to focus") in many cases or various "Lazy focus" rules which make exceptions for windows that can't do keyboard input and so logically wouldn't ever be your intended focus. In each case you will sometimes be disappointed even if you are "smart" enough to blame yourself for this happening.
None of these deliver what users want, which is "Focus follows brain". We do not have any way to achieve this.
Zoom behavior in art programs, for instance, is what started this thread: "zoom to cursor", "zoom to selected object", and "zoom to center of screen" are all things I've seen in various art tools, and all of them are "wrong" if they're not what you're used to, and extra-"wrong" if a program suddenly changes what it's doing because "implemented fabulous new zoom behavior" made a nice bullet point on an engineer's employment history.
:-)
It went from a quirky open source app I have been stubbornly using, to an example of how far 3D modeling software had advanced, that I would show to people far from 3D to blow their minds.