eromancer
patreon
Inner Circle Update for June 8 2018!
🕑 Added 2018-06-09 07:41:28 +0000 UTCHey 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!
Comments
I can see their viewpoint as well Mango. Here's a game that under it's previous development progress was going along relatively smoothly for what it was, from OUR point of view. All of the sudden, they're overhauling the game engine, changing render programs several times and all of this has delayed the game, in addition not even a yearly release of some section of the game. Granted the release delay is due to the overhaul, but the rest of us who are inept as programming, CGI etc etc etc can only see it as negative excuses. Then there are the people who have pledged to other h-games they had their hearts set on that have flopped. I would very much like to see MATM to succeed, I don't intend to pull my pledge personally unless money becomes very tight, but even I worry about these things as well.
MangoFishSocks
That sounds very promising. Doing it will most likely lose you some support, but probably save you some down the line too as those that were on the fence won't stop their pledge. About your other comment, it's a shame most people with harsh criticism will never see it that way. It 'excuses' the non-content development time, for lack of a better word.
Almost all of the techniques we developed in the later stages of the old art style carry over into the new one, so I wouldn't feel like that was wasted effort. The way we make maps now, for instance, is simply an augmented form of our previous iteration from v0.05. The new art style though is as much about being able to complete the game as it is a visual facelift. Hand-painting features into hundreds of images was never practical, and a need for working smarter really made the art style change more appealing. Basically, the scale of the project demanded more automation, and using newer tools offers us that capability. The old style however was very much chained to the tools and the process, and attempting to continue with that using tools not designed for it would have just made it even more amateurish and awkward looking.
It's especially confusing when new potholes hit development and we have to change directions for a little while. Tasks that weren't completed in the previous to-do lists still stand until we get back to where we were in Daz/Iray with Maya and Redshift. There will be ongoing new tasks in Maya for a long while that we'll work on intermittently. Things like material application automation scripts and such. I can make a pretty well-educated prediction for a list of tasks for the next monthly update that will cover development up through at least the Enty launch and toward the next major release.
CC
This. This. This. I am, for the first time, considering dropping my support for this game. I've been a supporter now for 3 years...which is crazy considering it feels like they had a decent game almost a year ago (before the art overhaul was first announced). The art update would have been totally acceptable for a new game.
BazookaDre
While I am still supporting the game...the one thing that irked me is that they went through the whole engine/graphic overhaul after already getting into the game. While I always favor quality, this may have been better done on a sequel. However, now the path has been chosen and I feel that maybe some patrons like myself feel like we've footed the bill for the development of two game engines rather than one. My advice, get a playable demo out, get people feeling confident that this game isn't in dev hell or in endless dev.
that actually sounds kinda nice, i am only a pledge from recently, i believe 0.04? but this game is so nice and so interesting in both visuals and gameplay that i cant wait to see how it evolves further, with such a list or spreadsheet the rest of the pledgers could get an idea as to what to expect in terms of time and details according to what needs fixing or completed, it'd also make keeping track of the increasing quality of the game all the easier
MB
They do have something like that on previous posts, but it is hard to keep track of. Maybe a IC post with a view-only link to a Google Spreadsheet that lists all the tasks remaining between now and v0.06 (or v0.1, as they talked about given how much work is going better than expected with the engine), with up-to-date statuses like "Complete" (with date), "In-progress" (w/ estimated completion date), "To-Do" (with no date, because your man power is limited).
MangoFishSocks
This update and the last IC one were kinda dry, which is understandable given the tasks at hand. Let's hope you get through alright. I also vow for this completion chart/checklist. It would ease a lot of minds.
Hopefully my financial situation is in a good area soon. I'm not giving up on the project but I'll be back for sure.
AltairPL
Believe me, we would like to get past this stage of development, and get back to the release schedule from before, as quickly as possible as well, but rushing things and taking shortcuts is not in anyone's interest. We are aware that some patrons want something more tangible than just words and images, and we understand your, and some other patrons, reasons for for leaving, so there's no need to apologize. Thank you for your support and good luck wishes, and hopefully see you around the next big release ;).
Been too long without an updated version release. Battle test got my hopes up but it looks like this conversion to the new engine or whatever "progress" is taking a bit longer then expected. I admit I know nothing of programming or whatever process it takes to make a game like this but from a consumer standpoint, I feel neglected. I've been pledged to you guys since November of 2016 and I've increased my pledge from that point til now. The game looks great and I can't wait for you guys to finish what looks to be an awesome game. Therefore, i'm pausing my pledge until I see something in regards to v0.06. Maybe if we were given a completion chart or a list of things to do up to your new demo I would reconsider. Until then I'll be turning away my support. Sorry guys, and good luck.
