MacGruber_Laboratory
patreon
Monthly Report: December
🕑 Added 2022-01-02 11:18:57 +0000 UTCHappy new 2022 everyone! Slightly late monthly report as I wanted to get my Raspberry project at least far enough for a little demo video. So what has been going on last month?
Essentials and LogicBricks
As planned, I did some way overdue maintenance/bugfixing on PowerHandles, SkyMagic and SuperShot, which are all part of my Essentials collection. Especially the fixes for PowerHandles should help anyone working heavily in desktop mode a LOT.
LogicBricks got two new bricks that can be used to have trigger sequences in an easier way. I had something like that in mind for a while, but now someone actually requested a brick like this, I took the opportunity to implement it.
VaM 2.x Plugins
There are/were some discussions going on with Meshed and some other creators how the plugin system of VaM 2.x should work. This has been eating some of my time. I think the concept is promising, but its very early and everything is in flux, so I should not reveal any details at this point. I will leave that to Meshed, once the time is right.
Connect GPIO
As teased in the previous monthly report, looked at my old Connect Audio plugin, which allowed you to control audio-driven E-Stim devices from VaM via triggers. The idea was that a similar plugin could allow you to control GPIO ports on a Raspberry PI. The GPIO ports are essentially pins you can turn on/off to control stuff. This kind of micro computer is often used for homemade "smart home" devices, like watering your plants, etc.
Without any coding, just some soldering/electronics skills, you would be able control all kinds of toys/devices from VaM. At least those where you can access the electronics easily. Could be some vibrator you want to turn on/off or for example, I modded a Suck-o-Mat some ages ago, since that box is just an air pump with two magnetic valves to create positive/negative air pressure inside a fleshlight.
The coding is about 70% done at this point. GPIO pins 17-26 can be set from VaM via triggers. In above video they are hooked to a LED array and controlled from a simple LogicBricks setup I use for testing. I'm gonna need a few more days of work to improve/polish things a bit so it's easier to use and compatible with the old ConnectAudio. Probably should do some documentation and maybe a simple example scene as well.
IdlePoser NEXT
What's next? While I decided to work on the Raspberry PI stuff first, the IdlePoser improvements are not forgotten. In fact, that's what I want to tackle next. I already spend like two days on planning how the new IdlePoser should work. The problem is mostly UI, but I think I got a reasonable concept now.
The current plan, subject to change:
- Introducing Layers: Instead of having multiple IdlePoser instance, you can have layers.
- Introducing SubSets: If you have separate parts of a scene that are unrelated, keep them in subsets, so its easier to maintain.
- Cross-Layer Groups and GroupMasks: Instead of the fixed ABCD... groups, I want to introduce freely namable groups as well as namable group masks. States from different layers can be assigned to the same group. The maximum number of groups will increase from 12 to 64 and you can also assign a custom color to each one for easier debug.
- Introducing a trigger callback once all layers have reached a state in the set GroupMask. A problem with the old IdlePoser is that you only get a trigger callback, if a layer actually had to change to a different state. That means its difficult to handle, if the layer is already in the designated GroupMask.
Hacking this in, like it was done with the AnimationPoser fork, would be "easy", but not maintainable. Doing it properly will be a lot of work, so its gonna take some time. With real life going on, certainly not before end of February. Before releasing I also want to finally spend some time on producing a video tutorial for IdlePoser. One more of those long overdue things. Benefit is that once you try to explain something to someone, you notice all the problems. Gives me the opportunity to fix them before its released, making changes a lot easier.
Cheers, MacGruber
Comments
Agreed w all this, and absolutely love the proposed changes. Layers (like in AnimationPoser) would drastically improve workflow (rather than hunting through numbered IdlePoser plugins), and even the trigger concept is fantastic (e.g. if you trigger all layers to switch to a new state, you need to know when they've all arrived if at different times). While I can get some clever variable behaviors using Timeline, all of my most realistic "life simulations" use IdlePoser, without question. IdlePoser for state/pose management, triggering Timeline animations when needed has been my ultimate combo.
CaseEP
Yeah, I'll second Clayface - idleposer has some revolutionary capabilities - especially the "anchoring" system - that no other VaM animation system has. I understand that your interests are varied, and that you'd rather develop smth radically new than polishing one specific app to perfection - but imo, idleposer has so much promise ...
