a l m o n d j o y

Excuse the click-baity title.

I’ve been following tutorials, reading some forum posts, and found lots of really fragile, long-winded solutions to the issue of FK-to-IK matching:

This usually happens when taking the naive approach of taking the target object’s world-space position, and tacking it onto the IK control. It doesn’t account well for frozen transforms, root-control translations/rotations, etc. 

Most resources I’ve come across use several strategies, all of which have their disadvantages.

adding/removing a point constraint 

adding extra locators to mark the “default” position and use some math to derive the new target translate values

try and derive it from the world-space + local-space rotation pivot position

The issue with all of these is that they’re not following a clean path from query to result. Adding constraints can create DAG cycles (fragile), extra locators muddy up the hierarchy and are another piece that can fall out of alignment (fragile, hard-to-maintain), and deriving it from world-space + local-space pivots doesn’t account for root transforms, and the code itself will be extremely long-winded (fragile).

These all require roughly 3-5+ lines of code for each control too, which really sucks. But I found one method that uses 2 for each control, and seems like the optimal path from query -> result, with no verbose math or weird derivations:

xform -worldspace -query -rotatePivot move -worldSpace -absolute -rotatePivotRelative

To get the world space position of an object, from its pivot point, most guides correctly point to the above xform command arguments. But xform doesn’t support plugging the pivot position directly into the translate field on objects with frozen transforms, hence all the other solutions. BUT, move has the wonderful rotatePivotRelative flag, which is for this very purpose. It essentially lets you “move” an object, taking into account local pivot offsets from any frozen transformations or manual pivot position changes.

The great thing is that this works (so far for me) in all circumstances of controls, and takes root transforms into account.

Low poly’d the model and textured it in substance. No rigging, and the fbx isn’t setup for game use, but just wanted to see what it’d look like after being cut down. Went from ~2m to ~100k polys with ZRemesher, bet it could be cut down to like ~20k polys with manual retopo (or am I naively optimistic). 

Last thing I plan to do is ID map everything so I can pack it down to a few texture sets and see what it looks like in unreal. Right now its 142 individual textures (´・ω・｀)

If I already knew how, it’d also be fun to rig it up, put some blend shapes on the face, and throw mocap animation on it.

Been working on this model for my ZBrush class and wanted to pose it and play with the new NPR filters. Kind of fiddly but really fun. Posed geometry is terrible and I just unioned everything together. Had random floating bits too but can’t see it after the render, so  ¯\_(ツ)_/¯

Material/polypainting and posing def feel like just a for-fun thing. Think the efficient way would be to do overpaint in photoshop, and then just bring it into substance once the model is ready.

lol, not sure what it is but trying to work on my hard surface skills in Modo. Still intending to execute my plan for ZBrush, but its taken a bit of a back seat since I signed up for a ZBrush course, and Modo + Hard surface has been a bit of an elephant in the room.

Trying to increase the complexity of designs in ZBrush and keep it fast. Had some normal bake errors on the hands/finger things, but I’m not gonna get hung up on that. Rendered in Substance Painter. 

Gonna start using these posts as brain dumps, so I can reflect on what I just did and to continue working at it with very deliberate processes.