You must be registered to see the links
I've worked on static renders all week, powering through some canon and branched scenes. Among others, I've worked on Josy, Maya, DIKs, and the Pink Rose.
It's going well, and I will mostly work on static renders next week as well.
I updated one of my PC slaves to Windows 11 this week, but I had to revert it to Windows 10 after experiencing black screen-to-restart crashes when rendering with DAZ. I thought the issue was driver-related, but it persisted after multiple attempts to update everything conceivable. I decided to keep it on Windows 10 until I replace it altogether in the future. While doing this, I thought about a topic that affects me weekly, but I don't often discuss - time thieves.
I want to share some behind-the-scenes insights on how these time thieves impact development and how I work around them. The three time thieves I've dealt with recently are Windows 11 upgrades, DAZ alpha bugs, and render queue depletion.
Windows 11
The Windows 11 upgrades are necessary, but they often come with unexpected issues, such as the one I described above. Currently, I have three PC slaves still running Windows 10, two of which I plan to replace with new PCs soon. The rest of my PCs are rocking Windows 11 without issues.
While I couldn't create a game without PCs, PC maintenance can steal quite a bit of time when everything isn't going smoothly. The systems must be nearly identical in all aspects that affect DAZ for slave rendering to function properly.
DAZ alpha bugs
The DAZ alpha build is being updated almost weekly now, and since there are plenty of quirks and bugs with it, I'm very keen on updating it regularly on my end to see if bugs are fixed.
This week, I upgraded to the latest version, and a new bug was introduced that caused several assets not to load at all and even crashed DAZ altogether. Those bugs steal time, but the biggest DAZ alpha bug at the moment - the time thief - is something I call the "DAZ alpha undo bug".
There's a tool in DAZ called the Translate tool, which you use to move objects around in the viewport, such as characters, items, and so on.
View attachment 5197428
For reasons I haven't quite figured out yet, DAZ can decide to undo many of the steps you've made in your current work if you use the translate tool in a certain way. And not only that, DAZ can also continue to move things around that you didn't move at all, causing the entire scene to be wasted. And to make matters worse, you can't redo anything that DAZ undid, so you lose your work the moment the bug kicks in. I have to restart DAZ whenever it happens. It's a really annoying bug that improved somewhat with the previous update, but it didn't disappear altogether. To combat it, I save my work frequently before using the translation tool - it has become a reflex. That way, I can restart the software and continue fast if the bug happens. DAZ has become faster when loading files, so not a lot of time is wasted, but I wish the bug would be fixed soon.
Render queue depletion
When I speak of a render queue, I mean a folder of .duf files (one .duf file is equivalent to an image or animation file before it is rendered) that are specified in DAZ so that they should be rendered.
View attachment 5197429
As PC slaves complete their current queue, I add more .duf files to them and specify them in DAZ. I try my best to spread the work out evenly among my systems, and always have a pool of files waiting for PCs that finish their work.
When a PC finishes its render queue, I supply it with new files. Every second between the PC completing its queue and me adding more files to it is wasted time. I try to plan around this by calculating when the PCs complete their work, but it happens that a PC is done in the middle of the night or at a time when I'm busy working. I wish there were a way to add files to the render queue while the PCs are rendering, but at the moment it's not possible, and I will have to live with this time thief during development.
We're talking about 1-8 hours of wasted time per PC when this happens, depending on how fast I can spot it happening. One way I combat this is by having large render queues per PC. Let's say a queue on one PC takes 1-2 months to complete rendering; then 1-8 hours of wasted time is small in comparison.
Time thieves aren't anything new to me; they have occurred throughout my years as a developer in various ways, and they are a pesky part of development. What's important is to find ways forward and to minimize the time they steal.
I hope none of this made you worry in any way; it wasn't my intention. Development is progressing smoothly, and PCs are producing animations and static renders at a steady pace.
Have a nice weekend
Dr PinkCake
).
