Inner Circle Update for June 25 2018! (Patreon)
Content
Police Enemy Materials Conversion
Another week, another character (nearly) converted to Redshift! I still have the skin and some fixes on his arms/helmet left to do – right now reflections on the arms are kind of messed up. Like last time, this guy’s helmet was a real pain due to the asset being broken up into an obscene number of parts. I’m also strongly considering swapping his boots and knee guards, which I hate, for something more interesting that should match his helmet. I haven’t gotten to test out the asset I have in mind quite yet.
Building these huge networks manually and simply matching instead of creating is monotonous as hell, so I’m really glad this is the last character that needs converting for a bit.
On that note, I did take a few days and switched gears to help Mr. Kittyhawk with props. Well, guns actually >_>
GUNS GUNS GUNS
I decided that one of the maps we were planning is unnecessary, and the story event I was thinking about for it could take place on another map. I figured a more valuable use of our time is to actually create an interior to Onyx’s weapon shop. I have my reasons, but I won’t go into it :D.
Suffice to say, we need a lot of props. Mr Kittyhawk has started work on display cases and the like, and I’ve been hunting down gun assets and converting them to Redshift. I scored some great finds—good enough that it’s likely that the Splicers and other enemies will be able to use some of the weapons I’m converting. They are all really modular, and I made sure to convert them in such a way so that creating lots of variations is no problem.
Here’s a set of renders I made from the ones I’ve converted so far.
Since there was lots of gun design talk going on, Ubercharge got the itch and painted up a concept rifle we may make for one of the characters. He also got to put a lot of work into his map this week, but he still needs another day of work or so before it’s ready to show off.
AltairPL’s URGE Engine Progress
I was hoping to get the error handling done by now, but... just kidding - this time around it is done :D. I still had some really convoluted things to get through at the beginning of the week, but after that, the rest of the processing was refreshingly smooth. And good riddance, since I was really growing tired of some related crap I had to deal with. It's not the end of the error handling in the grand scheme of things, but the remaining stuff will be completely overhauled sooner rather than later or will receive some more love somewhere along the line. One of the examples of the latter is moving error logging from Ruby to C, which should be less hacky and more solid, but since the Ruby version of logging is working just fine, I can leave it for much later and concentrate on more important things.
During this leg of error handling improvement/implementation I've found a few places that needed fixes and improvements as well. I fixed what I could on the spot, but one weird thing is a bit similar to one of the required things from my TODO list, so at least I didn't have to think twice about what to tackle next.
That thing from my list is "[REQUIRED] design/implement creation of encrypted archive(s);". Have been thinking about it a lot lately and I had some ideas about it I've jotted down in the meantime, but before I could start designing it in depth, I needed to experiment a bit to see what is possible and feasible and what is not. Thankfully, my favorite option seems to be working just fine in the test case, so I'll probably design the encrypted archive around it. It will require a lot of thinking, planning, experimenting, etc. but I think it has a great chance of success and with a bit of luck, I should be able to implement it in a timely fashion. I hope to have it ready for monthly update, but I'm not holding my breath.
TK’s Rigging Progress
Whatcha think of TK’s masterpiece? Lucky for us he’s not doing the actual posing :D. Check out his progress report:
So here's the finished result of my working face rig in animation form! My last post concluded with me with another new-and-revised Eyeball <> Eyelid interaction that also didn't work. I've since fixed that and you can see it in action in the first half where the eyes are moving. Now the eyelids are properly driven by the rotation of the eyes automatically, while the sets of override controls (in red) able to layer their own movements on top.
A frustrating thing that I kept running across and still don't understand, is why I can't "chain" constraints in Maya. Say I have two objects, a parent and a hierarchal child. I can attach a constraint to the child, and freely rotate the parent manually and both work. But when I add a constraint to the parent for rotation, only the parents rotation works, the child can no longer rotate from its constraint. Or instead if I pipe rotation values to the parent directly from a controller with no constraint then everything works, except that I don't have the offset that the constraint nodes provide. So I found a good in-between solution of using so called "driven keys" which are small animation curves to link objects together. This lets me keep my offsets, works with a child constraint while also acting like a damper where I need- The eyelids don't rotate at the full values the eyeballs do. Annoying, but at least it works.
So now after some tweaks and fine tuning, I'm back on the main part of the character setup. Just a few small changes (i hope) to how object naming gets corrected from the FBX imports and building the UI and its functionality.