So you have been grinding and grinding and have lost all interest and passion in your project that began as a great idea?
Take a break until Saturday morning and without even opening Blender, ask yourself:
“Is this worth my time?”
If the answer is no, archive the project and put it away.
If the answer is yes, but you don’t feel like it, take another week off.
If the answer is yes and you feel like it, it’s not time to give up.
Archiving the project can turn into a long and much needed break.
If you don’t get back to it, no harm done.
If you get excited once more after three months, having the project archived is important.
Else If:
Blender burnout in general and it’s not paying your bills or getting you a diploma, you might want to take a long break and do something else for a while.
Frankly even if you use Blender professionally and are approaching burnout, you should probably take a sick day or two. Burnout is no joke and will kill your productivity - that has bigger consequences for a job than a hobby.
Sometimes there are specific situations where you can’t take a needed break, or feel that you can’t, due to a company’s “crunch time,” but really mental health is just as important as physical health, and if you were throwing up they probably couldn’t ask you work that day. So weigh the risks and benefits.
I think that mostly burnout is a mental state rather than based on body.
It goes without saying that you have proper eat-sleep-exercice habbits. After that everything is in the mind. If you become eager it results making you anxious and stressed. Then you become perfectionist, then you become procrastinator, you get demotivated etc.
The trick is to do only what you can do and then you close the PC and do something entirely different. See a movie or take a walk. And more or less you repeat the same process for the rest of the 365 days. Perhaps at some point you really want to stop using Blender for a week and install Skyrim or something.
The idea is that you can be flexible, once you feel down just stop everything. However your intended ratio should be about 80% work 20% doing nothing. Perhaps even 50%-50% might work but since you work half the time, things would take twice longer.
Part of my day-job is being a “software project management consultant,” which means that I often encounter professional software teams that have fallen into “failure mode.” One of the things that I consistently see is that the teams are effectively unmanaged, even though they have a person who is officially in that role. They are “swatting at trouble tickets” as though they were badminton birdies, while churning out resumes at night. None of them have a clear picture of what they’re facing, which would allow them to strategize, as a team, on how to tackle it. They don’t have a schedule – they don’t have a plan – they are just reacting. There is no light at the end of their tunnel, and that’s part of what I’m tasked to bring. I guess I’m a candle-bearer.
Maybe I’m giving professional secrets away here, but a very big part of “project management” is “project planning,” and the most important part of “project planning” is simply that you have some kind of plan and that you then follow it, measuring your daily progress against it. Yes, these ideas still apply, even when “it’s just you.”
One of the world’s biggest mistakes – and I see it all the time – is “pantsing.” As in: “doing it by the seat of yours.” You can’t get “a major project” done that way … ever. Yes, even if you’re the only one doing it.
If you’ve got a plan and you’re following it, you’ve also got a way to manage exceptions. The white-rabbits that pop up out of nowhere and invite you to go chasing after them until you are utterly lost in the woods. You catch the little devils, put 'em on the chart, then chase them when you’re ready.
While I’m on the subject, one of the best books that I have yet read is “Hollywood Secrets of Project Management Success,” part of Microsoft’s immortal “Best Practices” series. Author Dr. James Persse noticed that Hollywood is consistently able to turn out very large, very labor-and-capital intensive projects – TV shows and movies – on a predictable schedule and budget, and to make money from most of them most of the time. He wondered what they must be doing right, so he started asking questions and interviewing people in the industry. Even if “it’s just you,” there are a lot of really good ideas there.
I have read a book about Scrum by Jeff Sutherland (the person who invented scrum), and it was very eye opening for me. Not that it was some type of innovative or cutting edge knowledge, but is based on a core idea is that it talks about most obvious thing that everybody has forgotten.
That you have to create something that works in a reasonable amount of time and then see how to improve it.
However everybody will dismiss this idea immediately because it sounds too simple. It looks almost like a joke, if you buy a book for 50$ that says how to become good at drawing and once you open it you see only one page saying you have to keep drawing once picture every day. You would definitely feel like cheated and return the book, and look for something more complicated. Or if you pay for 50.000$ going on a 3D animation school and then your teacher say just drop keyframes for 10 hours per day for an entire semester and then show me what you created, you will definitely arrange a lawsuit against the school for not teaching you anything at all.
In other terms, you can take this example: How can I run 1km without getting tired? What books should I read? Any good Youtube videos? Or if I keep repeating everyday a matra “I am good at running I am good at running…” would it would work?
The answer is that in order to run 1km, as you guessed right, it means that you need to run for a couple of meters daily, and gradually increase the distance, and stay on schedule for the rest of the 365 days.
Another good book is “Mastery by Robert Greene” that says that learning is only a matter of your neural networks. This means that is an 100% chemical-mechanical process, psychology only holds you back.
I will definitely look at that “Hollywood Secrets” book, thanks for the recommendation.
These are some great points. It’s not just in software, but pretty much any industry on the planet.
My expertise is logistics. Most businesses in that field are operating the same way as in 2005. Except for the few big ones who are 3-5 years from implementing science fiction tech. Mismanagement and failure to evolve in time, is setting the world up for an avalanche of bankruptcies, layoffs and monopolies.
“…a very big part of “project management” is “project planning.” - THIS! Is a neglected art form. I’m super privileged when it comes to working alone on complex projects, as the core idea “presents” itself out of thin air very vividly and the tiny steps required to get it done, keep popping up as I work, typically very fast. I call project planning the “loading method.” With every step detailed on beforehand, yet allowing for improvised updates in the moment, as well as resources and equipment being lined up beforehand, those responsible for the actual tasks go from burned out to inspired. It’s a matter of loading up the assets before we press the play button.
Another overlooked key aspect is to explain what to do and not how to do it. Except for things that must be consistent through out the entire project. Macro trust will defeat micro management every single time. I bet that lack of trust starts at the top of the pyramid and leaks down through every layer of management until as you say: “They are “swatting at trouble tickets” as though they were badminton birdies, while churning out resumes at night.”
EDIT: The two most important and often neglected areas in any workplace are the kitchen and the bathroom. If the value chain fails to deliver proper coffee and a great place to relief yourself, you bet there are other problems piling up in the shadows.
Have you found this logistics experience to translate well into the 3D creation workflows? Have you got something to recommend, a good book or resources?
Generally, the scrum technique I described earlier is based on “iterative development”, which means that you start with some basic thing and you keep iterating it continuously. However this technique does not translate well into the 3D workflows. Perhaps it would be ok for some other parts, but not in terms of the production steps.
Since for example you can’t have a 3D movie with half of the characters and the other half to be cardboard props. Once you have to shoot the final scene everything must be on set according to schedule.
While for example in software development is quite common if you want to do something simple, such as moving an object like this x += 1.0 and call it 100% working. At some other point in the future you can apply a physics algorithm if needed, since software is flexible it can be changed at any given moment.
FYI: “Scrum,” if you strip it of its “ceremonies” and focus upon its essential ideas, does have a few ideas that are actually worth keeping. The most important of these is: “don’t keep any juggler-balls hanging up in the air for more than [two weeks] at a time.”
In other words – no matter how many “juggler balls” you might be facing, periodically select a subset of them to work on “in the next [two weeks].” Such that, at the conclusion of “the next [two weeks],” you will have completed something. Whether or not it is a “publishable result.”
Functionally speaking, this strategy attempts to minimize uncertainty. Because, the more juggle-balls are up there, and the longer time any one of them is up there, the faster the “uncertainty” eats your lunch. With this strategy, you build-in a very regularly occurring “control point” – end of “sprint” – at which you methodically remove all of those “badmiton birdies” from the air and re-evaluate the next game.
Also: the number of “uncontrolled variables” – “birdies” – isn’t [usually] allowed to grow. You don’t immediately chase the rabbit. Instead, you can choose to defer it. Formal project management practices give you a structure(!) by which to make such decisions. “Even if it’s ‘just you.’”
Yes. I’m working on a visualization for a mechanical design concept around timber pallets.
The standard European 1/1 size pallet has 2 different scales of blocks and 3 different scales of boards. These are then positioned in a certain way.
My project requires a pallet assembled and also each part by itself.
The spreadsheet has these five basic parts defined by scale and a function to calculate the their positions based on scale and the pallet total dimensions.
For a total of twenty timber elements, I simply had to choose from a five item drop down for each of these twenty building blocks.
The spreadsheet then outputs a csv friendly file for scale and positions.
I feed that into Unreal Engine and with a for each loop for adding meshes, the pallet is created without any manual work required.
Sort of like Excel meets geometry nodes.
EDIT: I haven’t found a CAD way of doing the same in Blender for modeling the actual parts as of yet.
EDIT: Formatting and bullet points.
Very cool project. You can have a python script that acts as a generator, that it reads the CSV file and generates all cubes needed and scales them and puts them in place.
If you preferrably choose geometry nodes, it will be the same idea, however you would have the benefits of procedural workflow, to change the design at any point.
However still you would read the CSV with Python, but you would change only the input variables of the node tree.
In the most simple case you can start from a chair, to see how to transform pieces around, then with these nodes in mind, would adapt the design into a palette.
The “blockout then polish” approach lends itself well to iterative development. I’ve definitely seen artists use iteration in their creative process, but I don’t have any specific tutorials on the methodology (iteration will mean different things to different artists, and work differently for different aspects of 3D work).
Architectural modeling is probably the most obvious area where iterative development can be implemented, same with texturing and shaders. Basemesh re-use leaves lots of opportunities for iterative work for character stuff as well.
It is in the works and requires tons of time to set up. Once I have the workflow up and running consistently, I can link to a new topic from this discussion here.
Bottom line: A great way to avoid burnout, is to create something you are super passionate about. After 14 days, I am still on square one, setting up a pipeline to automatically create parts for timber pallets, and very close to the finish line. 14 days, 5 hours a day on average to make 20 cubes with some bevelling and subdivisions == 70 hours of learning modelling, python, geometry nodes, procedural shaders and many other things. For 20 meshes
