May Progress Update!

Hey guys!

Finally, a monthly update on the 1st!  

We’ve made some good progress this month, but there’s not quite enough implemented to merit a battle test release this time around. I’m kind of holding out to see how smoothly Malise’s armor damage implementation goes. We’re off to a good start though, as just yesterday TK hit the first major milestone in getting things working for that. 

Some of the big accomplishments include a working and automated portrait lighting system, a functioning (but still work-in-progress) double-teaming system, and major progress on Ven and the Splicers’ overhauls. 

Unfortunately, Ubercharge has had to be on limited availability most of the month after receiving a lot of pressure from his college to get moving on his project for his masters’ degree, and will likely be in the same boat for a while longer. What time he has will be devoted to critical issues and helping TK with Malise’s armor damage, which is the most difficult thing we’ve got going on tech-wise. The good news however is we have yet another new artist warming up :D. Mr. Kittyhawk is a 3D generalist with experience in Substance / Zbrush / and Maya, so he’s a good fit for our pipeline. He’s currently working on improving some of Onyx’s clothing assets and will then likely move on to some map assets and clothing for the Syndicate characters. Currently he’ll be helping out part time, until sometime in June when he will start with us full-time.

One more thing! Some people had asked about including spoiler warnings / etc. for our posts, which makes a lot of sense to me. I’m therefore adding warning tags and censors to the fun images that are in plain view, so make sure to click through the links for the uncensored stuff. 

I think that’s it for the overview stuff, so here’s the contents for this month’s post :D.

• Malise Armor Damage Concept
• Light Mixer System
• Malise Lust Stage 3 Preview
• Texture-based Liquids
• Render Optimization
• AltairPL’s Programming Report
• Hard Drive Requirement Estimator
• Splicer Clothing Progress
• Ven Overhaul Preview
• To Do List

Malise Armor Damage Concept

Here are the full uncensored versions of our first Malise armor damage concept!

Malise Armor Damage Concept (Zipped)

Malise Armor Damage Concept (Open Suit)

Malise Armor damage Concept (Wide Open Suit)

It’s important to note the word ‘concept’!  This is a hand-painted composite I made to test out the general look/positioning of the damage.  I have a few alternate versions as well that I didn’t flesh out. We’re currently in the initial stages of working on the 3D version, but there are a lot of things that make this difficult. Not only do we need to need for the damage shape/lines to look good with the structure of the suit, we need for it to be positioned appropriately so it doesn’t look weird when joints bend so that we can minimize the number of joint correction models TK has to make. To top it off, we have to validate our solutions for overcoming the problems that originally kept us from doing armor damage in 3D (as of yesterday though I believe we’re past the biggest hurdle :D).  Point is, we may end up with a different design, and will almost certainly have to troubleshoot some issues.  

One other thing I wanted to point out is that we are planning on making armor damage and lust sickness completely independent of one another, meaning you can end up with additional variations that weren’t possible in previous versions of the game (hence the three configurations above). I’m not certain if APL had implemented this yet in the code, so this may come a bit later.

Light Mixer System Part 1

This was the backbone of my work this month. It’s also a lot to explain, so bear with me :o. 

I’ll start off by saying our ideas for drastically cutting down the workload for lighting are working, and the image above shows just that :D (note that these examples are just to show the flexibility of the system, and aside from the first one don’t correspond to any environment in game).  All nine of these lighting examples were accomplished with *a single render* that took about 15 minutes.  I was able to put all of the lighting configurations together in about a 60-90 minutes while getting used to the grading controls of the compositing software.  This workflow will absolutely allow a single person to manage the ridiculous amount of character lighting our new art style demands for the remainder of the project.

Here’s how the entire process is accomplished:

• We use Uber’s lighting rig to render approximately ten separate images per pose; one for each light group in the rig (plus one for things like Neon’s lights and dome lighting), thus encompassing all possible lighting situations.  All of the lighting bullshit we went through with the battle test releases pays off dramatically here by the way. I’ll explain below how we’re able to get all the images we need with a single render.
• I dump the renders into my procedural automation network for portraits/battle artwork and wire them up to the light mixing system. From here, I’m able to use the compositing software to simply adjust the lighting how I want. Make the left light red? Done. Reduce the reflection in Malise’s glasses? Done.  Hate the goofy highlight on Malise’s left boob? Roto it out. No need for re-rendering anything!
• I’m now able to adjust the lighting on *every portrait in the game* with a single set of sliders, and then export all of them at once with any additional post processing. This goes the same for enemies once I get that set up.
• I then use a batch script generator I made in Excel (kind of works like a database for all our portrait data) to create a script that names all of the outputted artwork files automatically. I still have to update this to handle lighting variations and enemies.
• I then batch re-scale for 720p in Photoshop (until we’re in 1080p) > dump files into game folders :D.  Or more accurately, hand off to APL to dump in the game folders.

It was an unexpected detour, but I spent the majority of a week furthering TK’s previous research into Nvidia’s Light Path Expressions. This is a coding framework for the Iray rendering engine that makes some great black magic possible (of course, there’s almost zero documentation available so there was a lot of painful testing involved... for anyone familiar with regex it’s similar). Luckily the work paid off. We’re now able to render all necessary images for step 1 of this process in parallel, meaning it cuts the rendering time by 90% for a pose. Tack on another unrelated trick I learned and we’re at 95% reduced rendering time for portraits. It’s a huge weight lifted off me considering I’d previously have to be rendering around the clock to make this system work.

Light Mixer System Part 2

Implementing the light mixer was one thing, but automating it was the next major accomplishment. 

I started by wiring up the light mixer to all existing portraits and creating the ability to save light presets and apply them to any new render sets. I also now have the ability to change the lighting on all game portraits simultaneously via master faders I created. There will be one of these for the left portrait, right portrait, and enemy group, meaning for any given environment there can be three variations of the preset. I also learned how to use logical expressions in the compositing program in order to code some extra control into the light mixer. This will allow for certain lights to remain on at a minimum level for specific poses that turn out too dark in a given preset. An example of this could be Malise’s attack pose, which is one where we’d always want at least some light on dat booty. I’ve re-lit and re-rendered all of Malise’s poses for compatibility with the light mixer, and am happy to say it works well; not only this but the poses look great in the different lighting setups I’ve tried. I’ll still need to adjust a couple and re-render for things I didn’t consider, like Malise’s left-hand gun making a shadow on her face when the right side light is on.

Automation Network Expansion

After having implemented lighting into the automation network, I spent a day last week expanding said network for the remaining base poses for Neon and Malise’s first outfits. I’m glad to say the system works, with everything updating as expected. Here’s the top level of the network, and here’s another look at it showing the control lines (purple lines are Python script controllers, green are lighting expression controllers). To give you an idea of the scale of the artwork needed for the full game, imagine 100 or so of those big blocks just for the character and H portraits.

Each image is assigned to a keyframe on a timeline, meaning for example if I want to see “Malise in her idle pose wearing her first outfit with no status effects” I’d go to frame 509. Upon realizing how much time I’d have to spend scrubbing around the timeline looking for a specific pose during editing, I decided to code a Python script that would automatically generate and (more importantly) update frame label numbers for each image.   

There’s still some additional scripting I can do to speed up future expansions, but it’s coming along nicely. 

Malise Lust Stage 3 Preview

Now that I’ve bored you to death with the inner workings, how about some results? 

I finished setting up / re-rendering all of the existing Malise poses for the new lighting system, and made a preview set of renders for her Lust stage 3 poses (uncensored). Excuse the clipping on the collar, it’ll be fixed in the final version!  

If you recall, she was all wet n’ juicy in the old version, and I still have to add that. I did some tests and determined simulation would be overkill, and that it’s probably best to use textures and simple stringy models where necessary for this. I’m not quite done with it yet, as naturally this led to….

More Texture-Based Liquid Experiments

After waffling some on what program to use, we decided I should learn Substance Painter so that I can paint more detailed liquid textures when necessary.  Substance Painter will allow me to use alpha stamps such as this as a starting place, and I can pretty easily paint across the various clothing items / skin sections. 

The alpha stamp method was a huge help for painting liquid in the old art style (in 2D), so being able to use them again for 3D got me to thinking about other ways I could implement them. 

As it turns out, it’s pretty easy to make some good effects with them just by creating a bump map, using the alpha stamp as an opacity mask, and rendering it on a simple shape or even a plane with the appropriate liquid material assigned. In 3D game terminology this is pretty much a decal. For our purposes, I could hop into Maya or even simply position them in Daz to get some extra stringy/drippy/puddle effects. Some things worked better than others – for instance liquid sprays only really look good with clear liquids, since subsurface scattering won’t work on geometry that doesn’t have actual volume (you end up with what looks like a dirty pane of glass instead of a spray with depth). Here are some of the better results I was able to get:

• Stringy slime / spit (uncensored)
• Liquid spray
• Puddles!

This method should prove pretty useful for all the spit, slobber, squirting, and so on that made the old artwork so delightfully messy. Most importantly, it works with the new lighting system, so the liquid won’t look out of place between environments like it would if we had to paint it in post.

Render Optimization

Yet another thing I spent some time on this month was experimentation with a program called Altus Denoiser. I mentioned above that I was able to cut render-time needed to use the light mixer for portraits/enemies by 95%. While this is great, larger cutscene images (ones that will get close-ups in game for example) will still require an hour or more for a clean render. This is especially true for images with a lot of liquid since subsurface scattering is slow. Combine that with the fact that the super messy scenes require multiple liquid renders for compositing, and the need for faster rendering becomes apparent. This Altus program seems promising, as it’s able to take two low quality renders (with some extra passes for input) and create a high-quality, noise-free version. My best test showed I could take two 7 minute renders and get one of similar quality to a 38 minute render. I suspect that ratio will improve even more with more complex scenes. It’s not very compatible with the light mixer since I’d have to manually process all the various light group renders (unless I can figure out how to script it), but I never really intended to use the light mixer for cutscenes anyways.  That said, as I’ve come to use it more, it’s become quite invaluable for quickly drafting lighting, but that can be done with garbage-quality renders :D.

AltairPL’s Programming Report

My part of ToDo list in the monthly update is pretty long, and I was able to only do the small part from it, but I'm still pretty happy with the progress.

April started rather poorly for me, since I had some real-life stuff on my head, but one good thing that came out of it was the much-needed break from coding, especially from all the battle stuff.

My work this month started with the battle sprites overhaul mentioned in the monthly update. Everything is now much cleaner and less convoluted, so adding and changing stuff later won't be as much of a chore as it would be with previous version. It's still not finished though, since one of the plans for it was to move UI/info elements to dedicated classes to make it easier to implement and change visuals, like for example the UI idea Ero posted in the monthly update. I decided to leave it for later and shift my attention to double-teaming, since its visual side was already taken care of during finished part of the battle sprites overhaul.

Now that I think about it, I'm sure we could/should come up with a better name than double-teaming, since the way it's implemented allows for pretty much unlimited number of stacking enemies... and I think Ero already has plans for holds with three enemies at once. Anyway, shortly after shifting my attention to the multi-teaming(?), I've noticed that some hold stuff was still poorly done and it could/would kick me in the butt later, and since it was kinda in line with the multi-teaming stuff, I decided to do both at the same time. The idea was nice, but of course something had to get in my way. In this case, this something was a prototype for H-stat tracking, which was tied to the previous approach. I had only two choices here - either completely yank it out and implement it somewhere along the line or to add it to the current workload. Again, it was somewhat related to the stuff I was doing, so I chose the latter.

To be honest, I think I got a bit carried away with it, but hopefully people who like stats will appreciate it. The prototype was only tracking number of stages of H-skill chains (hold, H-skill, finisher), so I've also added tracking of target body parts for the last two stages (H-skill, finisher). This required some careful planning, but I think it came out rather well... at least for now.

After getting H-stats tracking out of the way, I was able to finish making changes to hold stuff and finally start implementing multi-teaming logic. Since no art dedicated to multi-teaming exists yet, I had to use some old enemies and art for testing by making copies of all needed database elements and adjusting it accordingly. After that it was pure coding, testing, coding, testing, ... this is approximately where things blew up.

It started pretty good and I managed to implement pretty much everything needed for it, but my fears came to light when something blew up in my face. While recently testing the last batch of edits made to action conditioning, I stumbled upon an isolated issue with one of the skills. Said skill is not really needed and was added by me some time ago as a proof of concept, so I just swept the issue under the carpet thinking we won't have any similar troubles. I couldn't be more wrong. Multi-teaming handling for an already-holding enemy (waiting for another enemy to join the fun) is affected by the same exact issue, which threw a wrench into my gears and made me lose all my momentum. The problem is that the responsible code is part of something much bigger and complicated and every possible solution I could think of would require a lot of time and effort to implement and neither of them is perfect.

Luckily, we’ve now partially resolved it by identifying a discrepancy between my vision and Ero’s vision for the multi-teaming design. I had been working on a design that would have an enemy wait for another enemy to join in if it was available, but after discussing it with Ero we’re now looking at a system that utilizes a “window of opportunity” for additional enemies to join in. Since for most areas there will be a limited number of enemy configurations, this should present an overall better mixed bag of H-attacks.  

I already have a rough draft of the new version working, and currently only have a couple major issues left to fix. Some of these may be pretty confusing without seeing it in action, but here’s my progress/known issues list for this new version:

Fixed! issues:

• Cleaned up some chaos related to initial (re)implementation of multi-teaming
• Enemy portraits weren’t disappearing properly when spawned enemies released their hold, but this is now fixed. 
• "Strike" could hit incorrect enemy, but now properly targets only top hold stack enemy.
• Fixed the cause for some NoMethodError exceptions that were popping once in a while
• Fixed an issue where enemy spawning was not playing the standard hold animation and screen shake

Fixed? issues:

• Sometimes a finisher doesn't cancel actions of remaining enemies for which hold was also released - probably fixed along with the NoMethodError problem, haven't seen it in a while

Known issues:

• Knockdown pose doesn't work when physical restraints are still in effect (knockdown itself seems to be working though)
• There are some problems with hold states, including retaining the state of top enemy on his hold break or finisher. It should revert back to the state added by the new top enemy/restraint, like physical restraint’s “restrain” state
• Pretty much the same can be said about stat tracking, which in some cases will add more to the counters than necessary... I have no idea how to solve it at the moment
• The bottom part of the UI doesn’t slide entirely offscreen, so the 3rd enemy is peeking through during finishers o_o

Hard Drive Requirement Estimator

I finally took a couple days to create a spreadsheet for estimating hard drive space requirements for the full game.  This is very important for a game utilizing giant libraries of pre-rendered graphics and is something I’ve needed to do since we started looking at lighting variations. The purpose of making the sheet was to identify features that could cause exponential spikes in space usage, and to provide a test environment for finding solutions to alleviate these spikes. Another reason is that I want to try to be able to fit the game on mobile platforms, so scouting for optimization possibilities is another use for it. I’m glad I took the time to do so, as we’ve found some areas we can improve on. I’m not ready to report on a lot yet, but I can say we will absolutely need some JPG compression.   Some good news though is that the automation network will help with that, since I can keyframe greater compression onto less important graphics :D. 

Splicer Clothing Progress

We still have a lot of clothing assets left to finish for the Splicer overhaul, but some good progress was made.  Here’s a series of images detailing the progress and final results for what we have so far. 

• Splicer Material Variation WIPs 1
• Splicer Material Variation WIPs 2
• Camo material close-up
• Splicer Pants Type 1 (Final)
• Splicer Boots Type 1 (Final)

Ven Overhaul Preview

Last but certainly not least! Earlier this week I made rough draft for Ven’s new Genesis 3 body model so that we can show off the progress on her overhauled outfit. We're currently using Malise's skin textures, but here’s where TK and I are currently at with it (uncensored).  I expect the textures/materials to continue to change somewhat as we add in the other components, but it’s good progress for sure.

TK sunk most of his time this month into remodeling / retexturing her armor for use in the new rendering engine, but the results are really top notch. Here are some additional images of the assets in various stages of completion.

• Ven Legs (Texture WIP)
• Ven Boots (Model Progression)
• Ven Arms (Early Model)
• Ven Arms (Completed Model)
• Ven Arms (Texture WIP)

To Do List

Though I wasn't sure how much we could get done out of it, last month’s to-do list may have been overly optimistic since quite a bit of it still stands. I’ve broken down the tasks a bit better though. Where Malise’s armor damage is at when I finally get around to updating Neon’s base files will determine the release of and what content will be in Battle Test 4, so I’m not going to explicitly list it. Hopefully things go smoothly though!

Eromancer

• COMPLETE: Implement Uber’s light mixing system
• COMPLETE: Paint Malise armor damage concepts for TK
• COMPLETE: Calibrate Daz lights for HDR processing (currently doing this in post and it’s resulting in degraded dynamic range)
• COMPLETE: Begin Ven character overhaul
• COMPLETE: Expand automation network for remaining Malise/Neon base poses / script additional automation measures. This turned out being part of the bullet of below, and wasn’t trivial, so I’m listing it ^-^.
• IN PROGRESS: Pose and render remaining non-armor damage portraits for Battle Test 4. Set up and re-rendered all of Malise’s existing portraits for compatibility with the light mixing system. Finishing liquid textures for Malise and need to update Neon’s base files before I work on her.
• Work out a couple lingering kinks with the portrait automation system.
• Update Neon’s base Daz scenes with the big laundry list of changes that have been piling up (similar to Malise’s recent edits).
• Work with Uber and APL on implementing updated battle sound effects.
• Extend automation network / lighting system to include enemy battle sprites
• Set up and render police enemy for light mixer compatibility
• Assist TK with Malise’s 3D armor damage 
• Continue work on the new UI design
• Continue experimenting with Police H skill artwork
• Continue Splicer overhaul direction
• Continue work on Ven’s character overhaul

TK

• COMPLETE: Ven’s armor overhaul
• COMPLETE: Begin work on Malise’s 3D armor damage if time allows.
• IN PROGRESS: Help Ero with Ven character overhaul
• IN PROGRESS: Malise’s 3D armor damage
• Make remaining fixes to Malise’s suit/holsters
• Help Ero update Neon’s base Daz scenes.
• Update Neon’s base Maya scenes.
• Create joint correction morphs for Neon’s armor damage variation model.

AltairPL

• COMPLETE: Battle sprites code overhaul
• IN PROGRESS: Double teaming implementation!
• Reel in Ero when he suggests overly ambitious UI design ideas (so far so good!)
• Add dynamic fog blending to the map sprite lighting testing environment / prototype.
• Add map sprite lighting system to in-game proper
• Implement new sound effects 
• Continue working on battle engine / URGE engine

Ubercharge (on limited availability)

• IN PROGRESS: Assist TK with sculpting Malise’s 3D armor damage.
• COMPLETE: Assist Ero with implementation of the light mixing system in the automation network.

Sculpting Girl

• Continue working on Splicer sculpts

Mr. Kittyhawk

• IN PROGRESS: Finish remodel of Onyx’s crop-top shirt
• Work on one or more of the following: The Void – Market assets
  / Syndicate clothing assets / Remodel Ven’s top if necessary

Translator

• COMPLETE: Translate tutorials, controls, warnings and other miscellaneous remaining text to Japanese.