/3/ — >no, you can't save your animation, you have to mark those k

File: 9403 - burger eating food kazami_yuuka phantasmagoria_of_flower_view.png (22 KB, 549x473)

Blender is first and foremost a program made by programmers for programmers and thus the workflow makes sense if you are a programmer, because you are expected to program in the features that you want in case they don't exist. If you want a program in which the workflow makes sense for a normal user who doesn't have the liberty of modifying the program to suit their needs, you can try out Maya

Yeah I would use 3DS Max for animation, fuck Blender. I know for a fact you can save all your keyframes and poses and shit because I've done it.

>>1028585 (OP)
I mean, you only have to do that if you wanna keep unused actions

>>1028586
This.

I dont even understand. You cant save in blender without checking a box first?

>>1028619
You gotta click save, it's a bit too unintuitive for Maya users who have a save button labeled "honk if you like fat asses"

Op is right and this is gay. Had to buy an addon called Animation Layers to get things to make sense when key framing. Enables you to rarely need to open NLA. Also why the fuck do I need to do four captchas to post. AI data harvesting faggot site.

Blender is one of the most astroturfed pieces of shit on the internet. Yeah, its a great program for 3D modelling but for rigging and animation it is one great big pile of stinky doodoo.
The problem is blendlets mindlessly shill it without trying out other 3D software, so they have zero clue what a proper workflow looks like. They have no idea what they are missing. They couldn't even fathom.
Sure, Autodesk has its problems but don't fucking act like you are offering a viable alternative when you aren't.

>>1028627
Nah man the rigging's spectacular

>>1028622
So no real answer? Wtf is the problem described in the op?

>>1028585 (OP)
It's the 3D equivalent of making a circle in Gentoo. Freetards think autistically hypermodular software with poor UX is a good thing because there's no reason GUI software shouldn't adhere to the Unix philosophy of "ls | grep | awk | cat >&2"

File: 1769131145141864.png (55 KB, 185x200)

>>1028683
>Gentoo
GIMP*

Semi-Freudian slip

>>1028585 (OP)
There's an addon fo that https://www.blenderkit.com/addons/e1c19457-113b-4f5d-b1f2-317318942cb7/

>>1028683
In fairness though Blender's regular 3D modelling workflow is fantastic, 10/10. It's when it comes to animation that it becomes a clunky unintuitive nightmare. I hope some day Blender is as good for animation as it is for modelling.

>>1028663
In Blender, when animating, there is a box you need to check "fake user" which will allow an animation to be saved. If you don't check the box, the animation isn't saved, even if you save the file before closing the program.
I don't know why, but I check the box because that's what works.
The OP has described this in his green text, and the accompanying gigachad going insane laughing .gif and disparaging rhetorical question imply that he doesn't like this.

>>1028777
>I don't know why
Because data in blender is reference counted.

As you might know, data in blender - whether it's mesh data, animation data, image data, material data, and so on - isn't married to its container, it just exists.
You can spawn a new monkey head and a new cube, then select the cube and set it to use the monkey head mesh data. And then this object will retain the original cube's modifier stack, object transforms, and other object data, but its mesh data will now be shared with the monkey head object. If you edit the monkey head object, the changes will be visible on both objects, as the monkey head mesh will be used by both. You can then clone the currently used mesh data on an object to create a new mesh data copy you can work on without new changes appearing elsewhere.

This is flexible, but creates a problem: deleting a container (like an object is for mesh data) doesn't actually do anything to free the memory used by the mesh data, as mesh data exists independently. Deleting an object only removes the object with its object data - modifiers, custom properties, transforms, etc.

So all data is reference counted. Any object that uses the data adds a 1 to this data's reference count. And removing a user subtracts a 1. That way if the object is used anywhere, the reference count is guaranteed to be above 0. And if it's unused, it'll be 0.
This count is used by the garbage collection system to determine if the data should really be deleted from memory for good, or not. The scan typically kicks in when you reload the file.

Yet that may be problematic for data you wish to store, but don't want to use right at this moment. Like animations.
This is why the "fake user" button exists. While toggled, it adds a 1 to the data's ref count, meaning the data's ref count will not be 0, and thus will not be deleted even if it's unused.

>>1028794
>Because data in blender is reference counted.
Why'd the supposed computer nerds making blender take one of the worst things in programming and bring it to animation?

>>1028885
Because referencing data makes the software perform better would be my guess. You don't want to store and process unused or copies of data

>>1028885
It's not that animation is singled out, that's the architecture of the program. Memory management doesn't care if it's removing unused animation data, image data or mesh data. That makes the system more robust because you don't have separate code for separate data types.
Reference counting most data is mostly intuitive because generally if you want to keep some data, you keep it in a scene, even if it's in a hidden layer or scene. It just so happens that the way animation data is often used, like if you were making a game model with an animation library, often forces you to disassociate it from the target armature, which removes said data's only user.

Since blender is a modeling program, it needs to be flexible, so duplicating the same data for every instance of it is not a good approach. And the only approaches to managing shared data reliably are manual "registers" for a given data type, and automatic management like blender does.

Take material data for example. Materials are generally shared by many objects. In 3dsmax, there's a separate register for materials, you manually add and remove materials there, and assign them to objects from there. There's probably some button for autoremoving unused materials from the register somewhere, but the last version of max I used was 9 so I don't remember.
Material data is just data like any other in blender, so it's managed automatically. Any unused materials will be removed automatially after enough save/reload cycles (if you delete an object with a 1 user mesh using a 1 user material, the first cycle will remove the mesh data as it will have lost its sole user - the object, and the second will remove the material as it will have lost its sole user - the mesh).

It's true that this is sometimes jank to the user. But DCC users aren't really the "general public", so intuitiveness takes a backseat to efficiency. But if you were talking about a videogame or a website, user friendliness would be most important.

Oh look! Another Le gay jeet meme spouting faggot!
Aren't we lucky?
He also post A.I. slop in a 3DCG board, smart!
What a great asset for /3/!

>>1028777
I have never once seen this fake user problem. No idea what you're talking about.

>>1028585 (OP)
>we'll GC them out of existence
Group Chat them out of existence?
Game Cube them out of existence.
Seriously what does GC mean in this context?

>>1028794
>>1028888
I would rather run into an issue of accidentally storing too much junk data, than actually not storing important data.
If they automatically created fake users for everything I created, that may end up with a bunch of junk to manually delete later. But at least I won't ever lose anything crucial because I forgot to check the "please don't delete my hard work please" button.

>>1028924
Garbage collection. It's a programming term for this type of automatic memory management, as opposed to manually telling the computer to allocate and return memory from/to "the heap", aka your RAM.

>>1028925
I'm sure you would, but a lot of people working with 3d are programming adjacent and would prefer the behavior they're used to instead. It's a design choice and they went with this. It's an acceptable solution and there's no reason to have a meltdown because they went with tomEYto intstead of tomAHto.
It's irrelevant anyway because you learn this behavior while getting used to this software in general. At the point where you're actually at risk of losing something "important" you'll have become familiar with its quirks. It's not a real world problem. There's plenty of things you could actually criticize blender for, but this isn't it.

>>1028635
No anon, autorig or using 3rd party plugins doesn’t fix the problem for experience riggers who need to customize it on a programming level.

>>1028941
I'm not sure if you know, but you don't actually need plugins for that, drivers are a basic thing in blender and you can easily make a driver that uses the result of any arbitrary custom function you can code in python right in the built in text editor, live preview and all. A better thing to complain about here is that such drivers can have really bad performance if you have a lot of complex ones evaluating at the same time.

File: Ahh.gif (3.62 MB, 600x450)

>>1028942
Also the fact that Python 3 knowledge is required because they followed Python developers idea to create stupid new words.

>>1028943
Well you'd be coding in python, obviously you'd need to know the basics. How is that different from learning at least the basics of any scripting language if you're talking about "programming"?

Another real issue with drivers is that using them can get pretty inconvenient even if you're used to the interface. It's much better in recent versions with the driver editing window you can pop out wherever it's used, it was hella jank in blender versions before around 3, but it's still really rough. It's really hard to quantify and it's a weak argument on its own because it says nothing about just how significant the inconveniences are, but I don't think anyone will agree that doing it just by clicking buttons is in any way good.
Frankly if you need to apply drivers en-masse (for example if you're not using dual quat skinning or b-bones or whatever they're called in blender, and need to mass apply a certain setup to lower and upper arm twist bones for animating skeletons meant for game engines using basic bitch linear skinning) it's often much easier to manually write a script with the correct settings and just reuse that with modifications in future projects than it is to do all that clicking. Especially now since you don't need to read the manual as much for all the arcane blender python API details and get AI to quickly cobble together something usable as a throwaway script.

>>1028935
>It's an acceptable solution and there's no reason to have a meltdown
Well most users coming into Blender actually aren't programming Adjacent. They're visual artists who are trying out 3D as a means to make cool looking shit in 3D. And then one day, because no one told them about this memory handling behavior, they lose hours of hard work at seemingly random. And then have to search for why it happens, and that's how they learn about it. So no wonder why every time the topic comes up, the person is having a melty.

>>1028945
If you somehow get to the point where you're making something beyond your first walk cycle following your first ever blender tutorial and still somehow don't understand when blender actually removes data and how to prevent it, I don't know what to tell you. Again, it's not a real world problem that could happen in practice. A hypothetical where it might happen against all odds is concievable, but highly unlikely.

This interaction isn't a special edge case for animation meant to piss people off, it's the case for all things you work with in the software. You add a new material you intend to use and then temporarily swap it for another, and on file reload you discover that the first one's gone. A normal person would start trying to work out why instead of shitting and pissing on the spot. You work with images and often find that they disappear when you swap them often, you find out why. You just work with any mesh object and see the top field of its main properties and see what that shit's about, click it and suddenly see the dozen cubes you spawned and deleted ten minutes ago on the list, you find out why and what happens if you choose one of them. You work with instancing and see what is it that makes instancing work in the first place (it's the same single unit of data assigned to several containers).

The real reason people are commonly having "melties" over blender "jank" is just to find an easy excuse to bandwagon against it. Again, blender has its issues, but so does literally anything else and just metaphorically throwing poop at popular thing to feel like you belong to the superior social faction isn't constructive behavior.

>>1028947
>If you somehow get
It's not "somehow". It's a common experience for a ton of users. Learning this weird memory quick is not intuitive, so how would people learn it? they would have to happen across the information somehow. And how would that happen? What opportunity would they have to come across this information, like not in passing as just a piece of the UI splayed on their screen. But an actual moment where the function of the button is brought to their attention as something important. What moment would they have to experience that?

>This interaction isn't a special edge case for animation meant to piss people off, it's the case for all things you work with in the software
And in all things, people have lost important work. As many people get into blender for many different purposes. They encounter this problem in regards to many things in the program.

>You work with images and often find that they disappear when you swap them often
That's an example of why someone would be mad. Imagine working on an image like hard core. You spend all this time and energy on the image, and then it's just... gone. That's rightfully going to make people upset.

Every other program under the sun, when you attempt to close it, it prevents you and goes "hey, you have unsaved work, do you want to save before quitting?" Blender is the only fucking program in the world that just goes "eh... they know the deal" and closes without asking. Well many users do not in fact know the deal.

>>1028948
What I'm trying to communicate is that you won't realistically be "working" on anything worth preserving before becoming familiar with how blender works at its core. How is this so hard to understand? Nobody just opens blender for the first time and makes their first masterpiece. Even a pro migrating from other software doesn't immediately integrate it into his no doubt very high value creative "pipeline", he tests the waters and sees how things work there before commiting to spending hours on something worth preserving.

>how would people learn it
I just outlined several of the countless situations how even a first time user can stumble upon this not-at-all hidden system.

The fact is even going the other way of making all data have the "fake user" toggled by default would have issues, likely more than otherwise. Some clueless poor sod desperately trying to make a titty mod for the latest game could end up making zillions of duplicated data for the high poly model he's trying to edit and suddenly his toaster runs out of memory, things start literally crashing and he starts another thread on 4chan about how blender is shit. Is that a good alternative? As I said, the default behavior is largely intuitive even if you don't fully understand it. You delete an object and its data will be gone eventually. You want to keep some data and you keep it associated to an object in a scene. Animation just tends to require frequent swapping from its container armature for working on separate sequences so you'd need to manually flag them to prevent deletion.

>>1028949
>What I'm trying to communicate is that you won't realistically be "working" on anything worth preserving before becoming familiar with how blender works at its core
We value what we lost, despite what you think.

>I just outlined several of the countless situations
Your situation examplified how work gets lost.

>things start literally crashing and he starts another thread on 4chan about how blender is shit
1, He would be far less likely to bitch about it, if his work was actually preserved.

2, Even if he still bitched about it, you could remind him that his work is preserved, and that he doesn't have a real reason to bitch. But the fact that his work was lost, gives him a justification to bitch.

>>1028950
So you are unironically suggesting that the first material you ever make and lose this way will be anything more than just testing how shit works? That's just being dishonest. Yeah, it's a "bummer" that the test material you spawned just to play with nodes or the image you made to test out just how shitty texture painting really is in blender (now THAT is actually very shitty in blender) is now forever lost in the ether. Big whoop. Anything you make in any software for the first few attempts will be just test stuff. And all of your test stuff will have bigger problems than just being lost. I don't think there's a single person who ever tried 3d modeling alive whose first mesh they worked on wasn't FULL of needlessly duplicated vertices, retarded normal smoothing artifacts due to random breaks in geo, hilarious attempts at subdividing 10+ edge poles and massive ngons, separate materials for every single color they wanted to lay down and so on. Making mistakes is how you learn 3d. This is no different.

>He would be far less likely to bitch about it, if his work was actually preserved
In that case the odds of his final "strokes" being preserved would actually be lower, as the software will have crashed before he could have a chance to write it to disk. Fortunately blender autosaves temporary snapshots of even temporary files you never "saved for real" every like 10 minutes by default or something. Although you could imagine a RAM-devouring file would be quite a few gigabytes big alone, and blender keeps some number of previous snapshots to boot, so not only would this collection of jiggabyte .blend files would suddenly eat several dozen gigabytes of disk space, every time the autosave kicked in blender would stop to write a fresh new copy of the monstrosity to disk, which could take big chunks of time. I think an average person would complain way more rather than losing the 2 keyframe test animation they did to see how they could import it into a game.

>>1028947
Umm no, you see i did The Oddly Satisfying Render Challenge, using only Maxon software. Guess what happened, there’s almost no tutorial on newer versions. It’s not like Maya or Blender where you can understand certain buttons by googling it. No, Maxon decided to recreate everything, the UI, names of features, how Cinema 4D operates, etc. Thus when people say they didn’t know stuff about Blender. I am absolutely certain the developers were at fault for not making things aware. My Cinema 4D project for the challenge is not good enough because of so many missing information that isn’t available and i cheap out on being satisfying due to lack of tutorials.

>>1028952
You claim that people who are barely beyond their first test animation would be savvy enough to press the fake user button every time without fail, but then you turn around and suggest that people who are approaching full project completion will lose work, because they're too incompetent to delete unused data. That doesn't make any sense. Someone who is creating such a large project that it's in threat of crashing would also be better at memory management.

>>1029230
>people who are approaching full project completion
That's not what was being said. The example was about a clueless tard using blender for the first time and thrashing his memory by reimporting a high poly models made by OTHER PEOPLE twenty milion times so he could graft the titties from some MMD model onto the latest overwatch roster addition. This is _not_ an experienced user.

You do not have to be beyond beginner level to fill your memory with junk. A beginner is likely to do that than otherwise. A _beginner_ is likely to start sculpting by remeshing a cube into literally 20 million vertices in one button press and then attempt to repeatedly boolean several deep copies of that abomination with some other bullshit.

This whole discussion is retarded because it is a non-issue. No matter how the system was designed, anyone realistically making anything worth preserving would already have been made aware of the workings long before being at risk of losing anything to ignorance. You can type out word vomit paragraphs over how it's imperfect and yadda, but IT IS NOT A REAL WORLD ISSUE.
It's like shitting on walking just because it's not obvious that you need to transfer your weight to the supporting leg while you move the other forward, in order not to fall. Ok, fine, so you will fall. Maybe even get a boo-boo. It will NOT ruin your olympic competition because it's not realistically possible to be this ignorant at that point.

>>1029256
>The example was about a clueless tard using blender for the first time and thrashing his memory by reimporting a high poly models made by OTHER PEOPLE twenty milion times so he could graft the titties from some MMD model onto the latest overwatch roster addition.
So ok, by your logic, because the user's work is so lowly, if he happens to cause a crash and lose his work, then nothing of value was lost. By your logic, he would have that one bad experience, immediately learn about the memory issue, and avoid it from then on. So then why set up a system where memory is automatically cleared? Instead of pressing the "please don't delete this" button, he can just not create the memory issue in the first place.

>>1028683
ill agree with this GIMP is retarded but it's well known that author of GIMP is menially retarded.

>>1028945
>>1028947
>>1028948
>>1028949
>>1028950
>>1028952
>>1029230
>>1029256
>>1029263
damn niggers I was just expressing my annoyance at an unintuitive workflow/ui, you don't need to hold a college debate over it

>>1029348
FOSStards are more concerned with defending their software then being productive