#I'm looking to get a laptop anyway so once I can move that software over I'll be free to do w/e with my desktop

[black-plumbob]

My game might be toast (again). I made it through all 3 base game hoods, and I have posts queued past Christmas. Hopefully I'll be in a position to switch to Linux before my queue runs out

[lupucs]

Do you have any recommendations for character modeling in blender?

Ooh boy I never know how to respond to questions like that, but I'm gonna try my best and list some stuff which helped me personally, so hopefully this will be helpful to you guys too.

A lot of what im gonna say is probably gonna sound really generic but generally speaking just watching one tutorial series and calling it a day isn't gonna cut it.

Something that helped me a whole lot was having a clear goal in mind (like I remember the first thing I wanted to do was translate my OCs in 3D). Picking something I was invested in is what pushed me to do my own research (and now its Deltarune fan animations lol). Knowing how to maintain motivation and going in with the right mindset is the most important thing imo.

I use Blender for my 3D work, which is free and open source. I personally prefer it over paid software like Maya or 3dsMax, especially for modeling and sculpting (I remember I had to use Max and Maya for a while but overall it was a pretty agonizing experience to be honest, so I switched back to Blender, which just feels a whole lot easier to use for me personally lol, but really at the end of the day just pick the software you want. This is just my personal preference). If you have a potato laptop like me, I definitely advise you to use Blender tho as it is very lightweight compared to other 3D programs, plus it can do the same things and then some. Not to mention there are way more free resources on Blender stuff so it's easier to get access to the info you need. Anyways Blender-simping over, moving on!

Tutorials are always a great idea, but you're also gonna have to learn how to do problem-solving. 3D can be a really technical and rigid medium, so being patient and knowing how to do independent learning is very important. Take a look at box-modeling, sculpting, texturing and procedural shading. Unfortunately that's gonna involve a lot of annoying situations and moments of immeasurable pain, but once you're more familiar with how things work, it's super fun and rewarding!

Don't forget to have fun and experiment! It's easy to get lost and overwhelmed by the technical aspects of 3D but it's important to just let go and make silly things. Also talking to other 3d artists with similar interests helps a ton, especially more experienced ones but I am aware not everyone has access to that (plus not everyone might want that, esp when you're an introvert like me haha!)

If you gotta sell your soul to a corporation then focusing on one particular subset is gonna be useful for animation jobs, as this is what most studios want. Some artists might like specializing into just one area, and that's totally fine but for me who prefers to be a generalist, it just kinda ruins my joy for 3D to restrict myself to just one part of it. Plus if you enjoy doing what you do, you tend to learn a lot faster anyway.

This might be a bit of an uncommon take, but one of the most stifling pieces of advice I have received from industry 3D artists is to only focus on one thing (as in, only skill up your UV-unwrapping, or only do rigging, only do hard-surface modeling, only do organic environment modeling and so on). NUH-UH! Just do what you want fam. Make the spoingle-boingles pet cats. Focus on the things you like. Make barney the dinosaur destroy the whole set. Model, rig and animate them if you want. Really, just have fun. Obviously you gotta do some self-checks and see where you need to improve, and where your strengths and weaknesses are, and focusing on those areas can be very helpful. Just make sure you're having a good time doing it, and don't be too harsh on yourself. Definitely take a break if you're overwhelmed.

You don't have to be able to draw to be good at character modeling but making turnaround sketches helps me a whole lot whenever I make 3D characters. Knowing how to draw will also benefit your sense of design and shapes, as you can use your drawing skills for texturing and adding your own flair to your models.

Another thing I would do is look at other people's 3D models and study the topology and the way they model things. This also helps a lot with motivation. Obviously you don't wanna copy, just study the way other people model things and see what other talented artists come up with! There are a bunch of free Blender rigs you can download and study on your own, not to mention useful videos and streams on YouTube. The Rain and Snow rigs are pretty awesome. Some of this stuff is behind a paywall but I recommend checking out the free resources of the "Settlers" project for highly cartoony modeling and rigging (this playlist is very useful, I didn't watch all of it but some parts have been pretty inspirational to me). Also just following 3D artists you like and looking at their art for inspiration will help you stay motivated.

Hope this is useful!

[mentalisttraceur-software]

Huge histdir-in-Emacs UX responsiveness optimization yesterday.

I was hoping I could kick this can down the road a while longer, but soon as I stopped fiddling with Emacs and got back to other work, my CLI history ballooned within a few days from ~500 unique entries to a couple thousand, with many of them having tens of calls (repetitive build commands, vi invocations, etc).

This meant that on a high-end Android phone, Emacs in Termux would freeze for a few seconds loading history. On every new shell or REPL instance.

(I'm pretty sure this is Android's fault. I don't know how or why, but a modern high-end ARMv8 CPU on a modern Linux kernel, with modern fast busses for I/O with disk and memory.... shouldn't be having these significant of delays. I have very little empirical evidence for this slander, besides just the fact that it doesn't happen on my laptops and I've seen Android introduce perceptible delayes in some cases with its safeties, but I am over-confidently asserting it anyway.)

I could probably have done a quick hack to get each new instance of the same shell/REPL instance to share already-loaded history, but for a couple reasons, I wasn't super motivated to tackle that by itself.

Plus, initial startup time matters to me a lot too. Several seconds waiting for Emacs to become responsive just wasn't really my kind of thing - especially not if those seconds were added by just a few days of serious work on a couple software projects.

(Oh, I also added deduplication support into the "histdir add" command of my minimal viable histdir shell script, so that would've cleaned up the most repetitive commands passively in the background.)

Anyway, I wasn't ready to make it a priority - but then I realized Emacs has cooperative multitasking, and I could yield before every file read and before the initial directory read. Boom. That alone brought the responsiveness up a LOT. Time to... let's say "first paint" (of the Eshell buffer, which I have start as my default buffer at the end of my Emacs init) went from several seconds to basically instant.

(Funny story: Emacs calls its cooperative multitasking primitive which has to explicitly yield... threads.)

But it was still annoyingly slow to load. Yeah I could now move my cursor around with only minor lags as it loaded. I could do other things. Even run commands in the shell as it loaded its history. But it was still a few seconds before I had my shell history ready to use.

So I finally brought in that dlist and ordered hash table stuff. I coded it for exactly this after all. But I had just left it sitting once I had it for a bit. Lack of time, wasn't a priority, and... more on the problems in the next paragraph. But now the priority was higher because history loads were rapidly getting slower and I was encouraged by the success with yielding to the rest of Emacs' event loop between all the histdir loading blocking I/O (really, Emacs, why do you still not ship with a way to dispatch async file reads to an event loop in some pool of OS worker threads? If I didn't know how thoroughly I search, I would have to believe I just missed it. Just... just basic FS read+write. Why not? What possible reason... anyway).

So there were two main problems with bringing in the dlist and ordered table stuff:

One - the "full" switch would involve an extensive refactor of Eshell history (I'd have to basically replace Eshell's history mechanism from the outside, whereas I currently get by with minimal monkeypatching - 20 or so lines, most just fixing a couple bugs in Eshell's history mechanism, not the stuff to pave over history read/write with histdir) and my wrap-any-REPL stuff. And it wasn't immediately obvious how all the details needed to look. I needed to just let that cook in my brain, and maybe build up the willpower/motive/stamina for the frustration with the inadequacies I could see I'd have to work around.

Two - the minimal change would be to just use the ordered hash table in the history load - it would purely optimize the deduplication. Instead of loading directly into a ring, with it's O(n) search and O(n) delete on every entry to throw away duplicates - I could use my ordered hash table, getting amortized O(1) duplicate checks and removals. Yay. Then copy history into a ring for interoperability with all the existing code which uses rings. Well, I tried that right after writing the dlist-based ordered hash table. It didn't seem to make anything perceptibly faster, so I put it aside. In retrospect, my history didn't have enough duplicates, and the blocking I/O was masking the benefit.

But now I was encouraged. After all, just yielding to the Emacs event loop at every opportunity got me so much closer to a great experience again. And sure enough, with the blocking I/O out of the way, just switching to my ordered hash table made a huge difference.

Back to a UI that even on the phone is fairly acceptably responsive and fast to load history. Not perfect, there's a bit of perceptible latency, but unless I've queued up muscle memory or a pre-computed finger movement plan it doesn't get in my way. It still would only scale linearly with histdir size, which won't be good enough as my history grows, but it's definitely back to good enough for ongoing use right now.