Inner Circle Update for June 8 2018! (Patreon)

Hey guys!

We haven’t slowed down since the monthly update and are still pushing through the Maya conversion stuff. APL and TK are making steady progress, but Uber and I were pretty much waylaid hammering out some unforeseen stuff with the lighting rig and materials in Redshift. The good news is we’re squared away now, and I want to mention just how awesome the Redshift support team is. It’s night and day coming from Daz (no offense to the solitary, completely overwhelmed forum support guy at Daz), as these guys are actually really into finding solutions for production-level developers that are trying to break new ground with their tools. 

Lighting Rig and Materials

Aside from spending a couple of days going back-and-forth with the Redshift support as we worked through that HDR lighting issue we talked about last week (solved by the way in their latest update, horray), I spent most of my time on the lighting rig and materials.

I started out the week by calibrating the lighting rig in Redshift to match the intensities we’ve been rendering at in Daz. Once I had the lighting matched, the goal was to correct any inconsistencies between the materials. For all the work I had put into skin, there were still issues with it. The main problem was that the subsurface scattering wasn’t working as I expected, so it ended up looking way more opaque than intended (Iray on top, Redshift on bottom). I decided to go back to square one and reverse engineer the differences between Iray and Redshift’s subsurface algorithms by stripping the layers from our Iray skin material (yummy!) and replicating the results in Redshift step-by-step. I had to start over a few times, experimenting with the different RS shaders, but In the end it paid off, as Uber and I were able to establish how to recreate the nice color variation and translucency we had going on with Iray’s skin, and even improve the subsurface/overall color. Here’s a comparison.  

I also made a few high quality/high resolution renders (uncensored) to show how much the details have improved in combination with the new subsurface lighting.

This process was also beneficial in that Uber was able to preemptively spot a Redshift bug that would’ve driven me insane if I had gotten to it first. Our renders need to be done in such a way where each light is rendered separately, allowing us to composite them later with our dynamic lighting system in post. Turns out this feature is incompatible with the Redshift material blender nodes (we use these for blending between materials like Malise’s lipstick and skin). Uber reported it, and Redshift’s team is already working on a solution. They make weekly releases, so hopefully we’ll have a fix before we need it :D.

Throughout all the skin stuff, I was able to do some render settings tests, and discovered RS can render in 4.5 minutes what Iray took 11.5 minutes to render (each final portrait render took 12-15 minutes in Iray, and was still kind of noisy). Since we’re looking at literally months of render time throughout the entire project, it’s no joke when I say that the time taken for the entire process of converting to Maya will be recovered in faster render times :D.

Mr. Kittyhawk’s Map Prop Progress

Mr. Kittyhawk has been continuing his work on the map props. He learned how to use Ubercharge’s procedural Maya/Redshift shaders and has been applying them to his parts. In addition, we’ve both been learning how to use animated textures in Maya, and how to get them to render properly in Redshift. It’s simple once you know the routine, but we spent a whole day navigating some deathtraps that were causing Redshift to not recognize the textures. The result is shown in the video you see above :D.

TK’s Rigging Conversion Update

I've spent more time with the HumanIK rig, and found the "best" way to prepare the Daz models and how to best avoid breaking everything. One of the attractive features is that it handles animation retargeting out of the box, which is one less worry. Retargeting is daily routine for many animators- it's the act of transferring animation data from one skeleton to another; motion capture for instance. There were a couple hiccups that took me a while to figure out, however. Sometimes it's not obvious where a problem actually is but obvious once you know where to look.

It turns out that there are options neatly tucked away that attempt to auto-correct the hips, feet, and hands for both the source and target figures while respecting the "floor". In our case with Genesis 3 figures in some poses, this correction overcompensates (or something?) leading to some very wrong joint rotations in the twist joints. I'm glad we ran through that early, it was unexpected and I was worried that it would be a large setback. Turns out it's just a few button clicks to correct.

Meanwhile, I've been parsing the Daz2maya script (the commercial conversion software we’re using as a baseline) and making a lot of notes. The script does work as-is, but there is a lack of customization and I've discovered lots of problems throughout. So, I'm cherry picking functions from it, making whatever modifications or rewrites that I need as I go. This is what I'm focused on right now, and the new Python script is starting to take shape! I've done some scripting before, but this will be my biggest and most comprehensive, which is pretty neat. It's also the most annoying in the sense that selecting different things and making lists in Maya is just... annoying. I'm starting to understand now, of all the times I hear programmers speak in pride over some small thing they accomplished in a clever way. :)

AltairPL’s URGE Engine Progress Update

Just before the monthly update I reviewed all the source files related to graphical objects. One of the reasons for this was to find and mark all places requiring better or even added error handling. After monthly I did the same thing for the remaining source code files. When doing this, I was constantly thinking about error handling overhaul, possible approaches, problems, etc.

When I finally finished processing all files, I started preparations for the overhaul, by making dedicated source and header files and moving everything related to error handling to those files. With this out of the way, I was ready to start the overhaul itself. Had a nice idea for error string fetching, and even though its prototype was looking good at first sight, I quickly found a nasty problem with it that could, in some cases, lead to Access Violation / Segmentation Fault, which is always bad, but in case of something as critical as error handling, it's unacceptable. Had to go to plan B, which has some small flaws, but at least it should be foolproof... with me being the fool ;).

Error handling is not an easy thing to do, since its nature requires highest level of attention possible and the need to check absolutely everything that has even slight chance of causing an error. It's going slowly, but I already made a lot of progress with it and am pretty happy with how it comes along. At the moment, I'm in the middle of removing old error handling functions and replacing them with new version, which is much more universal and easier to maintain.

While doing this, I was constantly bitching about the lack of inline documentation about possible erroneous behavior of some functions from 3rd party libraries we use. And then I realized that my inline documentation is even worse, so I decided to improve it at the same time as improving error handling. Great thing about it is that new documentation stands out from the old one, so all functions utilizing proper error handling are easy to spot, which will make checking and updating rest of the functions much easier.

I should be done with the remaining old functions soon, except one that will require some tricky crap shoveling. After that, I will need to go through some related functions, which are affected by the change, like returning some value, which is no longer needed, and/or using value returned by other function to perform error check that is also no longer needed. I really hope to get this done by the end of the week, so I can start the most tedious and time-consuming part of the overhaul - going through all the marked code parts, and adding or updating the error handling there. Hopefully I'll be able to report full success in the next update, so till then... APL out!