eromancer

Inner Circle Update for August 25 2018!

Added 2018-08-26 06:19:38 +0000 UTC

Hey everyone!

We had a pretty good push this week, and have quite a bit to show off for it :D. There’s also a lot of rigging talk below from TK and I, but here’s the gist of it: on an unexpected and positive note, we’re on the verge of being able to replicate the posing workflow from Daz. This means we can import poses and facial expressions directly to the character rigs, blend between them using a list of sliders, and most importantly we’ll be able to easily customize them per character this time around. We’ll be able to come up with more realistic expressions than we had in Daz, but we still have some problems to solve before we can get to showing off results. Okay, so let’s get right into it!

Ubercharge’s Map Progress

Ubercharge was back on maps this week, and completed nearly the entirety of his revision for the Splicers’ Gate map. This one has given us the opportunity to investigate some more advanced map animation techniques without the use of sprite sheets, and we all discussed how to best implement the tech required. These effects may not make it into the next version, but we’re looking at adding animated steam, animated lighting from the fires, and ripple shaders for the standing water. Here’s a higher resolution look at the full map, as well as a before and after :D.

Now for some boring rigging stuff D:

Ero’s Maya Conversion Progress

I split my week down the middle, finishing up material scripts and then transitioning into posing. I added some new features to my scripts, including a scanner that checks meshes for a material bug that’s been persistently annoying since we started doing maps in Maya for v0.05.

In order to begin working on poses, I had to do a fresh import of Malise from Daz in order to get TK’s newest face rig. There were a couple bumps along the way that AltairPL patched up with some script improvements, but overall the process went pretty smoothly. My material transfer scripts got a trial by fire when I realized the models I had used to create the new materials in Maya for Malise were out of date and didn’t match the latest ones, but they performed perfectly. I was also able to put my material selection script to use to make a solution for hiding body parts >_> without the need for messy rigging/morph/geometry edits. This will keep the body geometry intact between characters (especially ones like Neon who have parts missing), allowing for much simpler material editing.

TK then caught me up on how to setup the new face rig, and I was off! But not really. As eager as I am to begin posing for Battle Test 4, we ran into some shortcomings with our setup for facial expressions that needed immediate attention. The pose manager I’ve customized is great for saving, loading, and blending between poses, but complex poses like hand movements and facial expressions are a more complicated beast. I thought the pose manager on its own would suffice up through Battle Test 4, but I was wrooong.

What we need immediately is functionality to load multiple, co-existing poses onto the rig -- something called additive/subtractive blending – in order to construct complex poses from smaller building blocks. For example, if I had separate poses for “Left hand fist”, “Mouth open”, “Eyes closed”, I could load each of these independently and they wouldn’t undo the other poses – they’d add them together. This is effectively how Daz operates, and as it turns out it’s the path most advanced riggers tend to opt for. I’ve been getting advice from Adeptus Steve, the lead rigger on the game Wild Life, who has far more experience in rigging than we do. He’s taken the time to walk me through the high-level stuff on how his rigs operate, and while this is something pro riggers perfect over the course of years, we need some solutions in very short order to get us off the ground and moving in Maya. Turns out, TK had just the thing for it :D!

TK’s Rigging and Animation Update

I've made a number of upgrades and fixes to the rig; a few more to go. We're at the point where we can actually do progressive work without fear of losing progress on poses we make, which is a good feeling. Naturally, there's issues that Ero mentioned above.

Currently I’m finishing up the ability to import facial expressions directly from Daz so that Ero can use them as a base for improving upon (much faster than creating them from scratch). Altair helped write a special little hack for FBX animations and facial poses to get us started. The problem I'm currently investigating is that the face explodes outward after bringing an animation into Maya. What currently has me stumped is that when I then remove the animation and reset my controls back to zero, they're still halfway exploded, instead of returning to their original positions on the face like I would expect. Hopefully this doesn't take more than a day or two to come to a working solution.

Getting to the point of what Ero mentioned, I pulled an old item out of my todo list. Eromancer was set on using a third-party script to also manage face poses, but it's not a good system for the number of combinatorial face edits one might do in a typical session. The concept of my solution is an old and simple one called Driven Keys. All you do is create a control attribute, and key transforms of other objects to it. After some setup, you have a list of sliders/controls right there on the rig for easy manipulation of all sorts of facial poses at once. In practice, it's what Eromancer is used to using in Daz, but now with the added benefit of having easy to use controls in the viewport to layer on top of these premade poses.

So, once I can get this face explosion problem fixed, then we can move on to a mass import of face poses from Daz Studio. As time permits, I'll probably write a special UI to house all these presets with a search and orgnization feature. Maya’s default UI for this, the channel box, is convenient, but doesn’t have any tools for organization – meaning it’s not so great when you have a lot of things in it.

Limbo’s Colorized Concept Art

Limbo took the week off from working on new characters, and instead colorized all the concept artwork he's done up until now. He's broken every color up into it's own layer so it's very easy for us to go in and start experimenting :D. Limbo apparently has absolutely no fear when choosing colors, but keep in mind none of these are final!

Splicer Mask Variations

Early this week Ubercharge banged out some great materials for his Splicer mask models. I don’t have full quality male textures set up in Maya yet, so I set up a scene with some placeholder skin materials to get some final-ish quality renders, and am more than happy with the results :D. Check out how badass these guys look!

Mr. Kittyhawk’s Splicer Jacket WIP

Mr. Kittyhawk has been on a mission to show how effective his Marvelous > ZBrush workflow has become by pushing out a fully detailed clothing asset in short order. This week he’s been working on the first jacket for the Splicers, which he hopes to have finished by the monthly update.

Here’s a set of preview images of his work in progress, as well as a viewport snapshot with the mask!

AltairPL’s URGE Progress Update

Another week, another batch of distractions from versioning stuff.

I finally made some progress on version handling implementation, but then, when I started preparing ground for its archive part, I noticed a limit I'd hard-coded earlier into the archives to save at least a bit of my sanity.

Every time I needed some kind of data container with dynamic size, I had to code one from scratch, since C doesn't have one and it's a bit complicated considering how strict C is on data types usage. C++ and pretty much all higher-level languages have various versions of dynamically sized containers, called vectors, lists, or simply (dynamic) arrays. After working with Ruby for so long, I really missed such functionality, and considering how useful it is, I finally decided to try to implement one in C. My first prototype was a bit clunky, but it changed when Ero pointed me to something I should have figured out by myself, since I did something similar earlier. Updating my prototype with new (re)found knowledge wasn't very hard at least, and I had a working version pretty quickly. From this point it was only a matter of adding all the necessary functionality.

There's a lot of already implemented stuff that could use switching to this new container type, not to mention I had to drop or delay some other functionality to save time and my sanity, but most of them will wait for later still.

I started the switch with something I know well and use all the time, which is the rendering queue. I found a lot of minor issues during the conversion, but managed to process it pretty quickly and in the process, I was able to optimize the queues a lot and get rid of a lot of complicated looking code. With the rendering queue converted, and making sure that everything is working as intended, I did the same to everything archive-related that could use it as well. This allowed me to get rid of the aforementioned hard-limit and optimize archive processing a bit, which will make implementing patch archives processing much easier. I actually made some preparations for it, but since it's dependent on versioning system, it will have to wait a wee bit longer.

When converting archives, I've also stumbled upon another thing that started bothering me and I thought it could use optimization, but I needed to make some tests first. Long story short, I managed to improve archive-related performance, resulting in both faster archive creation and archive contents access/reading times, which is always a good thing.

Around this time, TK and Ero asked me for another fbx-processing script, similar to the morph cleaning one I did for them earlier. It was a relatively quick job, since new script was pretty similar to the previous one, but it was a nice change of pace.

With that out of the way, I pushed through the last absolutely necessary part of version/archive stuff. There's still a lot to do, like implement processing of patch archives, adding some checks, and other stuff, but they're more like additions, and I don't expect many changes to the core of both systems. I need a break from this stuff, so I'll probably start adding said functionality somewhere along the line.

I'm now working on making custom implementation of something, for which we needed a library till now... a bit clunky and cumbersome library, which I wanted to get rid of for a long time, but I had no other choice till recently. After that, I'll probably take a short break to distance myself from all the stuff still needed, and then I'll try to make a decision what should I tackle next... and there's still plenty to do.