Inner Circle Update for July 27 2017!

Hey guys!

Apologies for being late with this post! We’ve been working particularly long hours as we’ve been trying to realize the potential of all the new technological possibilities we’ve been investigating (and of course trying to keep up with production on v0.06 at the same time). 

I’m devoting this update to our progress on an idea that (assuming it works) won’t be fully realized until the artwork overhaul, but is one we started working on gauging the practicality of soon after the last IC update. It runs a wrecking ball through our current workflow, but the doors it opens for productivity and superior quality are a complete game changer (pun intended, hah).  

The idea is to centralize all of our 3D production around Maya, as opposed to producing character art in Daz and maps in Maya. 

This step would be like taking our 3D training wheels off, and is comparable on the art side of things to the way we’re ditching RPG Maker on the programming side of things. To clarify, this doesn’t mean we’d stop using Daz for initial character design, however it means that any final renders of 3D art for the project would be coming from Maya. There’s a long list of reasons for considering this (which I’ll get to), but as a starting point I have to rip on Daz a bit in order to level with you about the woes of using what is meant to be a character staging and posing application for a full-scale project like MATM. Be forewarned, this next section might get a tad messy and long-winded :D…

The Woes of Daz3D

Firstly, let me say Daz does what it’s meant to do very well. It does some specific tasks cleaner and at a much more lenient learning curve than other 3D apps.  That’s basically it’s strength; anyone with some artistic sense and basic knowledge of 3D can create good looking characters quickly. For MATM, the allure was that I (when I was working on this project by myself) could get assets easily. Well, what you can do with those characters is rather limited, and it’s when you try to go outside the intended scope of the program that things get ugly quickly. 

Unfortunately, this is all too common with Daz users (including us). The developers would have you believe it’s a powerful program, however most things beyond posing characters in a basic sense become significant chores, requiring workarounds and effort beyond what would be relatively simple tasks in any full-fledged 3D app with modeling capabilities. While this in part stems from the fact that Daz isn’t a modeling program (and thus has no tools for modeling), it has a lot more to do with Daz’s business model and how their success depends on keeping all of their technology contained. 

Daz wants users to purchase assets in their marketplace, and they don’t want people to utilize these assets in the much more powerful 3D applications used by the professional 3D industry. Keeping everything contained to Daz and incompatible with these other programs is very much in their interest, however they’ve done well at sidestepping the issue. Unfortunately, the issues propagated by this attitude are really limiting us, and are part of the reason why we think it’s time to move on from using Daz for anything beyond character design. Here are some examples that support my argument:

• Daz HD morphs are limited to content producers for their marketplace. The Daz Genesis body types for characters are very low-poly. This is great for performance, since in production the general rule is to work in low-poly and use subdivision to render at high-poly resolution. Unfortunately, it makes it literally impossible to do certain things without having the high-poly version of the body… something they only allow for their marketplace content producers. This is so that they can sell HD morphs such as this (a very basic rendition of what we would like to do) in their marketplace, but in actuality these products are completely impractical for use in anything but the simplest scenarios. In our case, we can’t do skin bulges or other details related to armor damage due to this (hence why I’ve been manually painting them since day one).
• Daz uses a proprietary rigging method. Anything with a rig (a skeleton for animation) imported into Daz Studio will almost certainly break. This technique, again, effectively limits Daz users into buying characters and creatures on their marketplace. This means rigged creatures or anything we produce in Maya or elsewhere can’t come into Daz, and it’s a real limitation on what we can do with regard to enemy design. 
• Morph based character design (see the bottom part of this page for a description). This is actually Daz’s strength since it allows for amazing flexibility stemming from one base figure model. However, when you attempt to export characters from Daz to another application it becomes a huge weakness. Without a lot of know-how, you simply can’t export characters and maintain their posing/shaping functionality to another, more powerful 3D application. What this means is that characters made in Daz stay in Daz. Again, great for a business model, bad for users. Fortunately, we think we are now at the point where we know how to overcome this, which is what I’ll get into in the later sections of this post.
• Daz can’t export animations, even though it offers the option to. This one has gone unexplained for a long time, and from what I’ve seen the developers tend to dodge questions on the forums about it. You simply can’t export animations from Daz reliably. Daz also has no physics simulation capability, so the above means we can’t export our character animations to another application to simulate physics and import them back to Daz. This has led me to have to animate things like hair/boob jiggle/anything else that would usually be handled by physics completely manually (and it’s almost always at a worse quality than what could be managed by automated physics). 
• Daz can’t export subdivision information. This is a new one we just found out about. Subdivision is a modifier to make a low polygon model into a high polygon model at a relatively low processing expense. Daz uses a very rare method called Catmark, and interestingly enough it makes their models look really good. It basically inflates geometry while it smooths it, which is great for big pouty lips and such. Here’s a GIF to show a comparison example. Notice the loss of detail in the face, collarbone, and ears with Maya’s subdivision. Ultimately, Maya’s algorithm is better for general purpose modeling, it just so happens that Daz’s is desirable for this purpose (and unattainable in other applications).

Examples like the above illustrate that we’ve essentially been trapped using Daz for things better left to more powerful applications for a long time now. Now that we have access to talent that can help us with assets, the limitations are really starting to be a burden. It had been quite a while since I even thought about the possibility of resolving this, but then we had the final nail in the coffin…

If you remember in the last update I was very optimistic about changing our rendering engine for character art from 3Delight to Nvidia Iray. Both exist inside Daz Studio, however Iray offers physically based rendering, a technique that Ubercharge will be using with Redshift, our new Maya rendering engine. Changing to Iray was a pretty important step for maintaining consistency with our art between the two programs. Unfortunately, we ultimately learned that Daz either half-baked or botched the implementation of some of the advanced features of Iray (including the user interface). This basically set me off on our current path. 

Benefits of Producing Outside of Daz

This is where the post gets a lot more positive and less whiny :D. 

The solution to our Daz problem is to be able to convert characters we create In Daz to a mainstream format that can be used in powerful applications like Maya/3DS Max/Houdini/etc. 

I go more into our experiments and how we plan to do this in the next section, but here I want to go over the benefits we would have with producing outside of Daz. 

• We can use a single renderer (Redshift) for everything. Redshift provides the same benefits as I listed with Iray in the last update, only this one actually works (yeah, we’ve already begun testing it with character assets). This will obviously help with consistency. 
• Opportunity for vastly improved posing/rigging/animation tools. Daz doesn’t even allow for two characters to interact/collide in an animation without a lot of messy scripts (which usually fail). Obviously, this kind of thing is pretty important in a game like MATM.
• We can edit the geometry of characters. Daz uses morph-based technology that completely breaks if you edit the geometry of a character. Maya’s technology is smart enough not to break, meaning we can increase polygon density where necessary.
• Modeling tools. I spend a lot of time in Daz making workarounds for things that could be fixed simply by making a few quick modeling edits.
• Physics simulation. Physics based hair, and soft-body simulations for breast motion, skin deformations for grabs, tentacle squeezes, etc.
• Complete asset compatibility. As I mentioned, we can only use assets from the Daz marketplace and a few other sources inside Daz. A good example of where this issue hit us recently is Stigmata’s new hyper advanced robodong. Ubercharge’s rig for it doesn’t work in Daz, so I’ve had to create a new one.   
• We can learn clothing creation tools like Marvelous Designer, and actually use the clothes without having to re-rig them for Daz. Here are some examples of the high quality of clothing assets people produce with that program.
• We get to keep the benefits of Daz. With our method we will still be able to utilize the good things about Daz in other programs, such as joint corrective morphs (for more realistic bends and such) and facial expressions.
• Hardware scalability. I discovered after my PC upgrade that I can throw all the hardware in the world at Daz and it will still perform poorly in complex scenes. This is due to it being single-threaded in nearly all aspects other than rendering. Maya and other professional apps make use of hardware much better.
• Improved scripting possibilities. Basically everything facing the user in Maya is a script. This means we can edit pretty much whatever we want.

Converting Daz Characters to Maya

As I mentioned earlier, the good ol’ developers at Daz pretty much make it so that this is a nigh impossible task. However, after Genesis 1 Daz changed their skinning system on Genesis figures from a proprietary (read: completely incompatible with everything) system called Triax Weighting to something called Dual Quaternion skinning. Dual quaternion skinning is widely accepted between applications, thus exposing a point of weakness in Daz’s iron grip that we could exploit!  

Since we started using Genesis 3 as a base figure with Onyx (our most recent female character), she provided the perfect test subject for beginning our attempts at conversion to Maya.  Suffice it to say, we thought this would fail miserably, but within 3 or so days TK, Uber, and I had viable solutions to all the major problems. Those solutions are as follows!

We will be using the Autodesk FBX format to export each character’s shape and skeleton, along with all essential morphs (joint corrective, facial expressions, and some others) to Maya. Here’s an image showing that we have the facial expressions working (the bars in the Shape Editor window are sliders for the expressions). And here’s one showing Onyx’s skeleton and shape successfully imported into Maya with proper weighting. From there, we will use a subdivision reverser and attribute transfer technique that Ubercharge and TK created to reacquire the subdivision details that Daz refuses to export. We then need to develop a script that will automatically reattach all of the joint corrective morphs (so we get those sexy bends… here’s a video on what they are all about), as well as their joint activation ranges, and also axis locks and rotation constraints for joints. Without these, posing would be hell (it’d be very easy to create unrealistic bends). TK was able to successfully hook one up manually, and knows how to write the script we need, but collecting the data will be a chore. Lastly, we’ll need a script for converting the characters’ shaders/materials to Redshift. We’ll likely utilize Ubercharge’s script coder I mentioned in the last update for this process, since he was really successful with the script for converting all our environment assets to Redshift. 

What’s All This Mean?

To be frank, it’s super chaotic here right now; mostly in a good way mind you :D. Let’s see… this will require a list! 

• A new engine being worked on, and all of the considerations to go with that
• An improved art style being developed
• New rendering engines to learn
• I’m still basically a Maya noob, so I’m working double time to keep up with TK and Uber. I’ve likened it to leveling a new class, and right now I need to rely on them for the heavy hitting.
• A major character conversion project that if successful will undoubtedly lead to awesome things (and more work)
• And let’s not forget v0.06!

Basically, our heads are absolutely spinning :D. 

We have what looks like an opportunity to remove most of our limitations and headaches with 3D art, but it’s simultaneously a bit of a curse since we’re trying to develop v0.06. To top it off, there’s the glaring issue of artwork inconsistencies that could arise up until we have time to sort things out with the artwork overhaul (post v0.06).  I’m still trying to figure that one out, but at the moment it simply looks like I’ll need to progress with the 3Delight rendering engine and Daz for the remainder of v0.06 production and try to deal with inconsistencies in what will almost certainly be much better looking maps due to TK and Ubercharge being ahead of the game on that side of things. 

Anyways, enough with the uncertainty :D. For now, we can celebrate the fact that it looks like we have a chance to graduate from the Daz/Poser world and join the big kids with all their fancy big kid toys.