eromancer
patreon
Inner Circle Update for August 25 2018!
🕑 Added 2018-08-26 06:19:38 +0000 UTCHey 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.
Comments
Sorry I just saw this :( -- yeah there will be. See the last section of the monthly update for our progress towards that :D (we're farther along now, but that's the most recent update I gave on it)
will there be a battle test 4 in some way?
Cereliona
That concept is kind of reminiscent of the Facehuggers from Alien, where they latch on and insert. Gotta admit, I really like that idea.
MangoFishSocks
Oh that works greatly. It was unclear to me in Splicers_3.jpg 'cause there were no folds or separated limbs or pieces of skin. I forgot about that image, you showed it off a couple weeks ago.
I'm planning for the tentacle appendage to have multiple stages. For example it may start out like the uppermost one and then elongate like the lower one: <a href="https://cdn.discordapp.com/attachments/418449471760891904/474453689718013963/Masked_Splicers_Full.png" rel="nofollow noopener" target="_blank">https://cdn.discordapp.com/attachments/418449471760891904/474453689718013963/Masked_Splicers_Full.png</a>
AltairPL
Thanks! Most high-level languages, like Ruby, have a lot of functionality, but at the performance cost. C may not have as much functionality, relatively speaking, but damn, it's fast. I wouldn't want to code most of the game in C, but having our own engine, we can use it for smaller parts that require highest performance or or low resource usage in general. I think Ruby and C complement each other pretty well, and a lot can be accomplished using this combo. I had my doubts about URGE in the past, but as the time goes, I'm more and more optimistic.
Perhaps they can elongate more than the picture suggested?
thanks for liking the map, put lots of hours into it, might also sculpt tentacles a bit differently than concept shows
MangoFishSocks
The map looks excellent. I adore the mix of high tech architecture and the unkempt, dark alley ghetto look. Bright, corporate lights on straight, neat buildings bordering barbed wire fencing, plain wooden pallets and unkempt wiring. Real gritty. Futuristic Batman. Say, the old school Splicer in Splicers_3.jpg, which of those tentancles are you planning on having to do the 'heavy lifting'? The bottom one is longer, but I think it'd be really hot if the middle one went hard in the paint. That way the other ones can clamp and grab all around. Could you make the middle one longer, larger and maybe a bit meaner? Perhaps bring the bottom one a bit more in too?
Venus
Looking good, regarding the splicer masks. Never hurts to draw from previous familiarity to help an audience relate. Nightmare on elm street references are never a bad thing :) Again its lookin great.
Cammay
The map looks fantastic! I really love the lighting and color composition - great job!! It's incredibly atmospheric :) Everything else sounds great as well! Oh and Altair: I feel with you - having to work with languages with less features than state-of-the-art languages can be painful -.- But I'm sure you'll rule nevertheless ;)
dudman
Loving the new look! And can't wait to see Exarch Nine to be in full 3D and to see her get hentai-ed, also I can't wait to see the new Ven, I love that character and should be fun to see her get used up multiple times
