Inner Circle Update for May 26 2018! (Patreon)

Hey everyone!

I’m about two days late on this post ☹! We had a setback of a few days that has been resolved, but aside from that hiccup things are going very well with the Maya/Redshift conversion.  I honestly figured this would take much longer than it has, but it’s looking like we could have a fully rigged prototype of Malise with all her materials to show off for the monthly update. 

Malise Material Conversion to Redshift

I’m almost done converting materials for Malise to Redshift! It’s been a steep learning curve for me since Maya’s material editor is the first node-based one I’ve used. It’s far more flexible than Daz though, and now that I’ve figured out most of the tricks for the difficult stuff the other characters should go more smoothly. Close-ups should be a major improvement over Daz since Redshift is designed to handle much higher resolution textures, and with Maya I can and have taken the opportunity to layer in detailed tiling textures, as well as procedural effects to improve lower resolution stuff. Here are some close-ups of some of Malise’s props showing the vastly improved details I was able to add:

Glasses 1

Glasses 2

Gloves

Holsters and stuff

The big jobs though were skin, eyes, and hair. I spent another two days on skin after the last IC update, then two on eyes, three on the clothes and three on hair.  Polygon hair is, it turns out, Redshift’s major weakness. Since Redshift was designed more for films, it was designed around the more detailed fiber-based hair. This became the cause of our big setback over the last few days. 

Basically, Redshift can only see 16 layers of refraction/opacity deep.  This means if you have 20 panes of glass it will stop calculating refraction after the first 16.  Polygon-based hair uses texture opacity, and ours happens to be way more than 16 layers deep. We have however come up with a workaround that looks nearly as good as Iray did. The big difference is that you can see more hard edges – especially on stuff like bangs. Very luckily however, Redshift is redoing their depth tracing in 3.0 (hopefully available this year) and will allow for unlimited depth, at which point we'll make necessary improvements. Basically, crisis averted. 

Anyways, I still have some work on the suit to do as well as her guns to convert, but those should go quickly. 

Maya Rigging Progress

TK has achieved a hell of a lot since the last update. Character rigs are working in Maya, and he spent an evening teaching me the basics of how to use the new one for Malise. Some other major milestones include:
 

• Functional face rig with advanced eye controls
• Joint corrective morphs for Genesis can be brought over and automatically hooked up. These are automated shape edits used to fix geometry to prevent clipping when joints bend.
• Grafts work! (grafts are additions/replacements for Genesis’ geometry – we use these for the nipples/genitals)
• We can convert poses from Daz to Maya (this one’s huge, I didn’t expect this)
  
   

Here’s a full update from TK!

More Rigging! I've learned a lot in the past couple of weeks and now have a functional facial rig that I can attach to any character we bring to Maya from Daz. Matrices just kicked my ass, but I have a much better understanding of most of the workings of them, like how to get world/local/parent/parents parent translations and do things with them. Getting the eyes to do everything I needed them to do proved quite the challenge, and I'm happy that I've gotten that working. Remember, I'm primarily someone who does models and textures; big 3d maths are scary!

A quick rundown on the eyes: 

• Eyeball controls on the face and out in the world, we can use either.
• The world look-at controller can follow the character's root or the head via a switch.
• Master and individual controls for the eyelid sub-bones, we can use either.
• Eyelids will follow any of the above appropriately when the eyes look around, this deforms the skin around the socket as well.
• And all this wrapped up into a rig that I can place on any character. This is a big one for me.

Now that I have a prototype worked out, my next step is to write up a script to automate the whole attachment process during the character setup stage. I've been meaning to do some real work in Python for a long time now, this will be a good chance to do that. Meanwhile, I've only spared a little time to catch up with the animation toolset in Maya, and a script suite called Red9 that looks like it will be very helpful later down the road, but these are minor things that will go quick once we come around to it. First, we'll be bringing in all the existing poses from Daz, and that's simple at least- at least mostly. Apparently there's some "forearm rotation fix" that sometimes needs to be applied to Daz poses. Eromancer had mentioned it in passing but I haven't looked into whatever that is. You can see the bad rotations in two of the poses linked above, but it's the minor stuff like this that happens daily.

But for now, my brains are mush, but I'm feeling happy with my progress the past couple of days. I can get back to doing more fun things soon.

AltairPL’s URGE Engine Progress

Well, I must admit that, not counting some initial hair tearing moments, switching gears from Ruby to C was a good idea. Can't say everything went easily and without problems, but I've managed to do a whole lot of stuff this week.

As you can remember, at the time of the last IC update I was working on directory listing function, which was supposed to become a base for other functions and functionality. I thought it will look a bit different in the end, but either way, I can report full success. One function approach changed into few functions approach, but it's much more versatile this way. In a nutshell, name of every directory/file found is passed to another function, which uses it according to the needs, like recursing sub-directories, or checking if file has given extension and processing it if it does. And that's exactly what I needed to fix font processing, which was broken when I switched toolchains and which I would have to recode anyway due to the problems with unicode paths. Testing showed that unicode paths are processed correctly, BTW, so it's another small victory. With this, I could scratch two entries from my immediate TODO list, and I could start the game in URGE once again, which allowed me to work on and test remaining TODO entries.

At this point, I wanted to overhaul error handling and reporting, but it kinda overwhelmed me, and since I had no good idea how to do main part of it, and because my old code scares the shit out of me, I decided to leave it for later and deal with some stuff that will allow me to clean up the code somewhat and in turn decrease amount of code needed to go through to do this error stuff properly. With that it mind, however, I did mark all the places in the code I could find that could use more error handling, and keeping it in the back of my head resulted in finding few potential and a bit hidden problems along the way, which will require some attention sooner rather than later.

Next thing I tackled was coding shader version of Viewport's color, flash, and tone handling, which not only are used for some screen flashes during the battles, but they're also currently used in custom scene transition code. Had some serious issues with this, and considering I was having very similar problems with something else shortly after updating one of the libraries, I think it's a bug in said library. Somehow managed to get the undesired behavior under control, but this may not be the last we've seen it, which is kinda bad, since I wanted to use some new features from that library, but now I need to hold off in case the problem gets worse and I'm forced to revert to the older version of the library. Anyway, did what I wanted to do and now shaders are used for viewports as well, and since it was the last thing needing a switch to shaders, I could now clean up all of the non-shader code I kept just in case.

Now that I got rid of the old and obsolete code, I could do what I wanted to do for a long time. Right from the start, all custom RM ruby classes implemented in C were made exactly how are they were seen by ruby, which required a lot of conversion for different types used by shaders and 3rd party libraries. So, I've decided to change them to use data types compatible with internal stuff in hopes that it will improve performance. Data structures were recoded, along with every possible use of them, and functions representing ruby methods were changed to return values compatible with RM. As I've said, I've hoped for some performance improvement, but unfortunately I haven't noticed any change at all, which kinda sucks. Well, at least the code is a bit cleaner, which is always a consolation. Also, while doing this, I've noticed that Window class implementation is in better shape than I thought... It's a bit of a mess that needs a lot more work and cleaning up, but at least it works (for the most part).

Still have few required things on my list, but every time I launched MATM in URGE, one of the optional things was bugging me, so I've picked it to be next. Font drawing library we're using for URGE has some serious issues with drawing italicized text when font doesn't have dedicated italic style, and I'm not even sure if dedicated italic style works, but that's a whole different story. Tried to debug and fix the library itself, but even though I think I know exactly what the problem is, my knowledge was not enough to fix those problems in the library code itself. I've managed to fix one of those problems some time ago by implementing custom outline, but the other one was too complicated for me and I had no idea how to fix it. Problem is that library is using italicized glyph bounding box for position, which is incorrect for glyphs like 'T', 'W', 'Y' and causes them to be drawn/rendered shifted to the left. Had some crazy ideas about how I could fix it, but in the end, something much more simpler, relatively speaking, seems to be working just fine for custom italics, so I'm not complaining. Well, it could use some additional tweaking, but that's something that can be done at a pretty much any time.

Not sure what I should tackle next, to be honest. I have an idea how I could test/trigger one of the possible deathtraps I think I've located earlier, so I'll probably try to verify and fix it if necessary, while it's still fresh on my mind. And then I'll probably move to the Window class implementation since it's closest to the finished state than anything else. Remaining required features, however, will be a major pain in the butt. Anyway, I've updated TODO list a bit, so take a look if you're interested.

Things recently done to make URGE production-ready:

• [REQUIRED] figure out directory contents handling;
• [REQUIRED] recode game fonts processing;
• [REQUIRED*] code shader version of Viewport's color, flash, and tone handling;
• [OPTIONAL] fix most noticeable italics font issue;

 Things still to do to make URGE production-ready:

• [REQUIRED] finish implementing Window class - too much convoluted work to convert used vanilla windows to my own Window ruby implementation;
• [REQUIRED] design/implement creation of encrypted archive(s);
• [REQUIRED] overhaul error handling, reporting, and logging;
• [REQUIRED] fix whatever critical errors we encounter;
• [OPTIONAL] implement system fonts handling;
• [OPTIONAL] fix remaining font issues;
• [OPTIONAL] test and, if possible, implement game controllers support;
• [OPTIONAL] finish implementing scene transitions - for now Viewport objects are used for this purpose even in RM, so it can wait;