eromancer
patreon
August Progress Update (Part 3)!
🕑 Added 2017-08-04 20:49:56 +0000 UTCHey guys!
I’m devoting this last part of the 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 in mid-July. Again, we won’t be starting work on this idea until the artwork overhaul after v0.06, but the week or so we spent experimenting with it shows a lot of promise that could really add a lot of room for future growth on the 3D art side of things.
The idea is to centralize all of our 3D production around Maya, as opposed to producing character art in Daz and maps in Maya.
The concept 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). Doing this 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: basically Daz either half-baked or botched the implementation of some of the advanced features of the Iray rendering engine (including the user interface). We’re effectively stuck with beauty passes with Iray, meaning if we ever need to do any significant post processing we’re out of luck. 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, clothes, 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.
As we work on v0.06 we will continue to research the tools available to us if we are to change over to Maya, but for now it looks that it’s at least possible, which is really good news!
Comments
They'd be a lot more technically viable. We'd still need to do armor damage entirely in 3D. There's the option of animating liquids in After Effects but it'd be mega time consuming. They do something similar to that for animated H visual novels. But yeah, that's the direction I was exploring with that v0.05 animation.
Honestly these progress updates are more interesting than the game.
Rather than having combat H animations, would cut-scene animations be too difficult to do? The end of v0.05 was partially animation, so is this direction you were already heading? I imagine running an animation for each section of the game instead of potentially each encounter would be easier to create. Or did you already mention all of this in a previous post?
as good as info you give on your progress there is so far nothing new to download (no offense) so ill just cancel my pledge for a while untill i see a new download on the way . good luck on the progress . great game and i enjoyed every reles so far but its been a bit too long a wait :) . I will surely be back that is a promise tho.
I had a post a couple months back about the issues we need to overcome for animations that might give some answers. Outside the time requirement needed to make the animations, we'd need to be able to do liquid and armor damage entirely in 3D (this may be possible after the artwork overhaul) and create a really advanced caching system to be able to load all that image data on the fly, We'd also need to be able to cache while updating the graphics, which is something we can't do yet.
Kerryberry
I think you should do it after switching to the new engine you mentioned earlier. Is it possible to utilize it for H animations?
Subjectivity
Every new update that mentions a breakthrough, new artist or new technology being used, I always hope "Please say this means animated H attacks!" but apparently that is way more complicated than all these other advancements. It looks so good, it just kills me that they won't move!
I would worry about progressing to a 3D game engine with your next game. You have a good start with the current Malise and the Machine. Trying to overdo it on the first try will just leave you guys burnt out and hard on cash. Not to say that you shouldn't be looking around now and learning if that's what you want. But to overhaul the current game engine another couple times or more, that might not be feasible. Malise and the Machine has great artwork compared to other H-games I've looked at, interesting plot and considering it's originally all based in ...RPGMaker... of all things.
Honestly battle H animations would be easier with a 3D engine, but that presents a whole new range of tech issues (increased hardware requirements, etc)
Well, it's not the workflow yet. It's what I'd like us to progress to after scaling some learning curve. And yeah, that's a thing I want to work toward. This would allow me to animate easier, but it wouldn't resolve our tech limitations. The problem there is that we'd need to cache and play a lot of frames dynamically. Might work out but we're not ready to commit to it.
Mav
Sounds like you guys are having some success with the new workflow/tech. Does this mean that in combat H animations will be a thing in future versions?
