Inner Circle Update for July 17 2018! (Patreon)

This week has gone better than the last I think, but there have still been obstacles. TK has been running up against some new issues as he prepares to send the characters over to Maya, and I’ve been helping him debug stuff there. We’re pretty sure we’re out of the woods, but these issues complicate automation and would be nice to know more about. Save for a day or two of remaining tasks, I’m pretty much at the point where I need rigged figures to proceed with the remaining tasks for Battle Test 4, so getting TK over the hump is a big priority. APL is up and at it again, and we helped him identify and debug some unexpected issues that came across after he sent us his full URGE test build. 

Uber is back and is working on improving Mr. Kittyhawk’s hard surface designs for Onyx’s shop. Since I can’t quite work on poses yet, I’ve been helping with map stuff a lot the past few days. In the meantime, Mr. Kittyhawk is learning Marvelous Designer (he normally does clothes entirely in ZBrush) and has begun remodeling the Syndicate guys’ outfit for the artwork overhaul. Here’s an early preview of his progress on the coat, which is already a step up from the blob we had before.

Maya Conversion Progress

A lot of the effort here this week was in TK’s ballpark. He’ll go into it more in his section, but a lot of involves unexpected issues with how Daz exports certain morphs. I did however get the police body materials converted, as well as the mats for his big ol’ donger. TK finished up converting his armor to Genesis 3, including the new leg armor, which I did a Daz mock-up of earlier this week. I’ll finalize the materials for that in Maya. The last thing this guy needs are some custom body model corrections to fix errors generated by the Genesis 1 to Genesis 3 conversion process, and then he should be ready for Maya conversion. Neon’s list of fixes for her Daz scene is shorter than expected, so she’s probably only a day’s worth of work away from being ready to go to Maya as well. 

Onyx’s Weapon Shop / Map Progress

This is where most of the visible work went this week :D. Mr. Kittyhawk and I started with some work on the hard surface details around Onyx’s counter. He created a chain link tile set while I did a bunch of kitbashing and made a test scene with Onyx so that I could get some camera framing for story shots. Here are some renders of that: 

• Onyx Shop Test 1
• Onyx Shop Test 2
• Onyx Shop Test 3

I then created the blockout for the map. I’ll leave it to you to figure out what the heck is going on in that scene :D. 

Next, I worked on a shader for holograms (could still use some improvement), which I intend to place throughout the store, maybe with signage or prices hovering in front of display cases / above counters. The plan is to animate them to glitch out every once in a while, to add some animation to the map. This will definitely get used for other maps as well.

Lastly, Uber’s been fleshing out the blockout with hard surface details, and polishing up some of Mr. Kittyhawk’s designs.

Here’s another load of weapon conversions Mr. Kittyhawk did, as well as a custom cyberpunk MP5 design Uber has almost completed:

• Uber’s Custom MP5 (WIP)
• Handgun 1
• Handguns 2 & 3
• Submachine Gun 2
• Hunting Bow

Map Sprite Perspective Change(?)

This has been brought up before, but for the first time I’m strongly considering changing the perspective we use for the map sprites to match that of the game map. Or more accurately, we’d be using two sets of sprites – one for the top-down perspective and keep the current one for side-view. In the retro JRPGs ours is styled after, it’s common to use only a front orthogonal projection for sprites like we’ve been doing, but retro RPGs don’t have the level of detail the new art style allows. What this means is that we’d be severely limiting the extent to which the characters can interact with the environment since their sprites would clash with the map’s perspective. 

Here’s an image to demonstrate what I mean.

In this example, the colored sprites show the perspective at which we currently render them. The other models show what they would look like with the new perspective. Poses like the one Onyx has behind the counter, or the guys in the hallway, wouldn’t be possible with the current sprite perspective, and the same goes for a whole lot of event ideas we have. Beyond opening up a lot of opportunities in this regard, I suspect the sprites will look way more grounded in the world than they currently do. Aside from the simple shadows changing shape, the only other thing this idea breaks is reflections. In the image you’ll notice reflections in the current sprite perspective are exact mirror images, meaning we can render reflections with some simple code. This isn’t the case with the map perspective sprites. They would require their own sprite sheet. This would’ve been very tough to render in Iray, but it isn’t an issue with Redshift since we can turn off shadows and render reflections separate from the character itself.

It’s a bit hard to say without materials on the models, but I think it should look better. What do you think?

AltairPL’s URGE Coding Progress

This month started really badly for me, and real life is still kicking my butt, and will probably continue to do so for the rest of the month.

Not counting finishing game archive notes, I haven't done much in the first week of the July, due to the aforementioned real-life problems.

The situation started improving a bit in a second week and even though I still have a lot of real life crap on my hands, I finally managed to make some progress on the archive stuff. For the most part, creating the encrypted game archives is working as planned, including creating multiple archives when the size of the data is nearing limits for 32-bit applications. I still have some more or less minor things and tweaks to do, but if need be, most of them can wait for later.

If not for the real life, I would probably be long done with the game archive implementation, but unfortunately, it's more like 30-40% done now. I can only hope I'll manage to finish it in the coming week, including brutal internal testing, which usually reveals a problem or two that I can fix before sending it to patrons.

That reminds me - I've also fixed one of my earlier screw-ups related to keyboard input, which reared its ugly head only on selected hardware, so even though I don't remember why I've sent it to the rest of the dev team for testing, I'm glad I did.

TK’s Maya Conversion Rigging Progress

Kudos to APL and Ero for helping me solve some weird stuff with Maya's mel script syntax. There's a common command 'setAttr' for setting an attribute, it's incredibly common to pass variables to this command. Except this one particular case where (i think) if the target attribute is like a sub-target of another attribute, then I can't pass a variable, it just complains. Turned out that the solution was to go from an integer array, to a string array, to a string, then build the whole setAttr command as a big long string, and tell mel to "evaluate" it. What's that saying? If it's stupid and it works, it's still mind-bogglingly stupid?

I took a short break in the middle of all this and the following madness to convert the Police Guy's clothing from the M4/G1 figure to the Genesis 3 Male figure. At least that went smoothly!

I finished almost all of my list of morphs that need to be exported from Daz and hit yet another snag! I'm not even surprised at anything these days, lol. One of the first things I needed to know was whether or not I could suppress certain morphs on export, and I discovered that I could. Except my testing wasn't thorough enough, and I can only suppress morphs in a largely unhelpful way and I can't find any solution. The problem is that if I tell Daz to export a morph for the body, it projects that morph onto all the clothing. Normally this is something that we want while actually using Daz, because it has the smarts to not project say, a foot related morph onto a pair of gloves. However, the FBX exporter doesn't have this logic, so all morphs end up on every piece of clothing.

This ends up being catastrophic once we get to Maya. Even though these bogus morphs are empty, Maya's FBX import needs to make a full duplicate of the geometry and apply the morph vertices to each duplicate, where it can then apply these as actual morphs. Given the huge number of morphs and fairly high poly models, my meager 32 gigs of ram is eaten quickly, so Maya begins working off my page file on C: until that's empty, then crashes the whole system and the import never completes. Not good. But once they are applied as morphs (or blend shapes in Maya terms), we can safely delete the hard copies in the scene and get our precious RAM back.

Since I can't find any reasonable solution, we'll have to export the clothing + a copy of the body in smaller batches to make this manageable, then we're safe to combine everything into a final scene.