Inner Circle Update for June 17 2018! (Patreon)

We’re continuing to make progress with our conversion to Maya / Redshift, and things have gone quite smoothly this week :D. As much as I’d like to be showing off a bunch of new stuff, the best we can hope for over the next few weeks is a speedy transition with as few hiccups as possible.  

Minus a small list of fixes that I still need to make, I was able to convert all of Neon’s materials this week (shown above). TK and APL have updates for you on rigging and progress on the new engine, respectively, and Uber is now rounding the bend on his master’s classwork for the year, so we’ll be seeing more map progress out of him. 

Getting the lighting rig set up for our dynamic post-process lighting system was a breeze in Redshift, so that’s done too. Yet another shout-out to Redshift’s support team on this one. Ubercharge found a bug with this stuff last week that could’ve been a real inconvenience to us, and these guys had it fixed within the week. While we’re on that topic, Redshift 3.0 experimental builds are supposedly starting in a few weeks. If you recall from the monthly(?) update, polygon-based hair isn’t very compatible with RS due to depth tracing limitations (lots of polygons stacked closely = bad). These should be removed in 3.0, so hopefully we’ll have those hair issues resolved before we start pumping out renders. 

We’ll go into some details below, and then I’ve got a more up-to-date summary of our immediate roadmap since all of this Maya conversion stuff has made it tough to keep up.

Random but relevant, what’d everyone think of the big Cyberpunk 2077 reveal :D? We’ve been talking about it a lot this week.

Neon Material Conversion

Neon’s material conversion is mostly done besides some work on the eyes, hair, and a couple texture seams. Here’s the comparison between Iray and Redshift :D.  Remember, the goal here was to match the results of Iray. And here’s the full size version of the cover image. 

Due to Malise’s suit and Neon’s armor ending up significantly different under the render lighting, I had to dissect how Redshift processes reflections similar to how I had to do it for subsurface scattering last week. Reflections have physical accuracy baked into their algorithm in Redshift, and you can see that these come through a little nicer on Neon’s armor. 

While the opacity is still screwed up due to that issue I keep mentioning, Neon’s hair is otherwise looking better than in Iray in my opinion.  I’m using translucency more accurately here, and I shifted the hue back to the old look now that she has her lipstick again, as I think the more saturated look clashed with it. 

I chose to ditch the metallic look to the lipstick this time around, as its brightness values varied a lot depending on the lighting and this was probably a source of why I didn’t like It so much. Instead, I was able to obtain a realistic look that’s similar to the old style now that I know what I’m doing with PBR materials.

Material Management System

While there’s relatively little face-to-desk interaction in converting these PBR materials to an entirely new rendering engine, it’s a lot of work in Maya right now as I have to hook these monster graphs up manually. For the sake of illustrating our need for a good material management system and to assure you guys I haven’t been resting on my laurels, here’s Neon’s behemoth of a material graph. While the added flexibility of being able to manipulate materials at this level is very valuable, this kind of beast currently has to be configured and hooked up from scratch when either converting or making a new character. Transferring materials between scenes in order to re-use them adds data to the nodes which is a mess to clean up, and while I’m getting okay at understanding Maya’s pitfalls here it’s still cumbersome. 

TK had identified back when he started using Maya for environments that material organization is Maya’s Achilles’ heel, and I agree. It’s fine if you’re doing one big scene with unique materials, but it becomes really obtuse when you want to just quickly swap materials between lots of scenes and assets. We’re therefore planning on building a material management system, probably incrementally as opposed to trying to do it in one fell-swoop, over the next few months while we settle in.

We know one component of the material system would be preset barebones graphs for characters coming over from Daz, set up with Redshift material nodes corresponding to the Genesis 3 material zones. A second component would be a script with a UI that allows us to pull materials from a database file of sorts and apply it to geometry in the scene we’re current working within. This process would automatically strip off or organize the data Maya tacks onto incoming nodes order to keep things nice and tidy.

TK’s Rigging Update

The autorig script is in really good shape now! I had to do several rewrites of key portions of the face setup, partly because I'm an idiot and crashed without saving in a long while, and also because my methods changed a few times partway through. With the rewrite, I did some cleanup as well. It's been bugging me how long this is taking me to learn and do, but there isn't much I can do about that. I hope this doesn't bite me later, but I'm not including much in the way of error-handling in this script. The nice thing about the Daz exports is naming consistency, which gives me a known set of data to work with every time.

I had discovered that my previous setup for the eyeballs and eyelids was not going to work in general use, but especially not work when it comes to loading presets from Daz. But, this was one of the first areas I tried to tackle knowing that it would be a problem area, and I know more now. I guess I can consider that a beta version. I'm in the middle of setting up a new and improved configuration at the moment that should do everything it needs to and not flip everything the wrong way.

*Update* I managed to get this sorted out before Ero posted the update -- had a few kinks along the way. It turns out I was thinking backwards through my hierarchy while creating this new configuration. It's a big improvement and uses no extra math nodes this time- everything is rotating and blending as it should.

Once this eyeball/eyelid setup is done, that should be it for the meat of the character setup. Just need to plop down some file importing and some UI buttons and we'll be in business again! There will have to be a second stage to this for automatically converting and setting up materials. I expect that part to go much smoother and quicker.

On a personal note, it's nice to have this kind of growth in the scripting area. I still haven't done any serious modeling in a while, but I'm learning many things that will be helpful later on, even in modeling.

AltairPL’s URGE Engine Progress Report

I was hoping to get the error handling done by now, but I've seriously underestimated complexity of some things. In a lot of places adding proper error handling required some changes to existing code to either remove the need for error checking at all, or to make sure there's no memory leaks when non-fatal errors occur. On top of that, some places for various reasons required general overhaul anyway, so to prevent doing the same thing twice, I made the necessary changes before adding error handling to them.

Best example of this, and one of the biggest derails, is related to something that was kinda getting on my nerves in RPG Maker - error during image loading or audio loading/playing results in game terminating exception, even though warning should be more than enough in most cases. I've coded such missing file handling in Ruby game scripts some time ago, so for various reasons I decided to keep URGE behavior as is (throwing exception RM-style).

All functions related to image and audio files loading/playing were changed drastically. If error occurs, dedicated function is called and that function is raising the exception, so changing this to a warning later should be a matter of minutes. Order of things in those functions was changed as well, which makes error checking more streamlined, but also ensures that everything is properly freed, which prevents memory leaks when the exception is rescued from ruby code, or when I switch from exceptions to warnings. This switch will require a lot of testing and probably some changes to game scripts as well, so I'm leaving it for much later - at least I am prepared for it.

Another huge task was related to my custom low-level functions library. Main purpose of this library is to make functions that will be universal for any operating system - usually by having dedicated processing for systems like Windows that use different Unicode standard than most other operating systems. On top of the few existing ones, I've added few new such universal functions. And all of them are now fully documented and use proper error handling.

Also, while digging through libraries in search for possible errors, I've found a few neat compiler attributes that my IDE can use to show warnings where appropriate, so I've added those attributes whenever possible/applicable, to make my life at least a little bit less miserable.

I think that would be all major stuff for this update. Minor ones were mainly small fixes and quality of life changes.

To recap, maybe error handling wasn't finished as I have planned, but the other stuff I did was important and big enough that at least I don't feel bad about myself.

Map Progress

Ubercharge has actually gotten to put in a couple days of work recently on map stuff. Now that he has his procedural post processing pipeline pretty much golden, he’s focusing on doing a pass over his initial maps to finish them up and bring them up to par with the latest stuff. He’s starting out by adding hard surface details and sci-fi greebles to the first alley map he did. Here are some previews of that:

Hard Surface Parts

Wires and Details

Moving Ahead!

The timeline has been getting progressively more confusing with the Maya conversion, but our next milestone is still Battle Test 4 / the Enty launch. From a player’s perspective, here’s what that release will contain: 

• Full lust system enabled, including all stages and armor damage for both characters
• At least one example H skill chain
• Potentially the new combat user interface

Here’s a list of goals we need to accomplish to make that happen:

Maya Conversion Stuff

• Convert the police enemy’s materials from Iray to Redshift. This is one of my jobs for this upcoming week.
• Convert materials for genitals
• Convert the police enemy from Genesis 1 to Genesis 3. Genesis 1 uses TriAx rig weightmapping, which is completely incompatible with any modern 3D app. 
• Update Neon’s base Daz scenes to match her model we’ve been using for the recent battle tests. Need to do this before converting to Maya.
• TK’s rigging conversion (Daz to Maya) pipeline and scripts need to be functional and relatively bug free.
• Get Malise, Neon, and the police enemy rigs working in Maya.  This includes props like hair/genitals. The further TK refines his scripts/process before we do this the less we’ll have to revise later. 
• Convert Malise/Neon’s battle poses from Daz to Maya and make fixes where necessary.
• Lay the groundwork for portrait rendering automation in Maya and get a basic system working (this will be a huge timesaver, so it’s worth investigating as soon as possible). 
• Render all the portraits up through Battle Test 3 in Redshift and get them hooked up to our lighting system. Will likely knock out a script for simplifying that last part, since any future full re-renders will be impractical to set up by hand.

Other Tasks for Battle Test 4

• Finish Malise’s 3D armor damage
• Pose/render the later lust stage / armor damage portraits
• Develop H skill chain and artwork for police / both characters
• Potentially revamp combat user interface

I’m sidestepping a few tasks here that aren’t completely essential in order to get to Battle Test 4 faster. Once we reach that milestone things will be back to their usual heightened level of chaos and we’ll be able to continue putting out test releases as we push toward the next major update.