July 2018 Progress Update! (Patreon)

We’re winning our battle in the conversion to Maya/Redshift :D. There’s still work to be done, however. On the bright side I managed to keep the update under 20 pages ^-^

Lighting rig conversion and calibration is done. Neon and the police enemy’s materials have been converted, and Ubercharge and I put a lot of effort into matching up Iray’s material parameters with Redshift’s after finding some significant differences with our Malise conversion (subsurface and reflections specifically). The result is the best skin material we’ve had yet. TK has successfully automated most features of character rigging conversion from Daz to Maya, and completed two full revisions of his face/eye rig controls. I have a pretty thorough checklist of the remaining work for the conversion and beyond at the end up this update that should make everything a lot less confusing. 

We’ve also made a lot of environment progress unrelated to the Maya conversion. Ubercharge is back to working on maps, and Mr. Kittyhawk and I have completed a lot of work on props. I also found what I believe has been the missing link in our fluid workflow, and I have some work to show off there.  AltairPL has completed a ton of work on URGE’s error handling and encryption, and he has an extensive update for you regarding that.

Anyways, let’s get down to business shall we :D? The topics with the *** symbol are new or have been updated since the last Inner Circle update.

Topics for this Update

• Lighting Rig and Skin
• Neon’s Material Conversion
• Police Material Conversion
• Material Management System
• ZBrush: The Missing Link in Our Liquid Workflow***
• Ubercharge’s Map Progress*** (You'll wanna check this out)
• TK’s Maya Rigging Conversion and Automation Progress***
• AltairPL’s URGE Engine and Coding Progress***
• The Void – Market Props
• Onyx’s Weapon Shop***
• Moving Ahead***

Lighting Rig and Skin

Let’s start at the beginning o_o. 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 in the last monthly update (solved by the way in their latest update, horray), I spent most of the first week in June 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. (Update: iz now fixed!)

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.

Neon’s Material Conversion

Neon’s material conversion is mostly done besides some work on the eyes, hair, and a couple texture seams. Here’s the comparison between Iray and Redshift :D.  Remember, the goal here was to match the results of Iray.  Here’s the full size version of the above, processed image.

Due to Malise’s suit and Neon’s armor ending up significantly different under the render lighting, I had to dissect how Redshift processes reflections similar to how I had to do it for subsurface scattering last week. Reflections have physical accuracy baked into their algorithm in Redshift, and you can see that these come through a little nicer on Neon’s armor. 

While the opacity is still screwed up due to that issue I keep mentioning, Neon’s hair is otherwise looking better than in Iray in my opinion.  I’m using translucency more accurately here, and I shifted the hue back to the old look now that she has her lipstick again, as I think the more saturated look clashed with it. 

I chose to ditch the metallic look to the lipstick this time around, as its brightness values varied a lot depending on the lighting and this was probably a source of why I didn’t like It so much. Instead, I was able to obtain a realistic look that’s similar to the old style now that I know what I’m doing with PBR materials.

Police Enemy Material Conversion

I spent most of the third week in June converting the police enemy to Redshift.  I still have the skin and some fixes on his arms/helmet left to do – right now reflections on the arms are kind of messed up. Like last time, this guy’s helmet was a real pain due to the asset being broken up into an obscene number of parts. I’m also strongly considering swapping his boots and knee guards, which I hate, for something more interesting that should match his helmet. I haven’t gotten to test out the asset I have in mind quite yet, but here is what I’m looking at using as a starting point in case you’re wondering.

Building these huge networks manually and simply matching instead of creating is monotonous as hell, so I’m really glad this is the last character that needs converting for a bit.  After working on this guy, I took a few days and switched gears to help Mr. Kittyhawk with props, which we’ll get to in a bit :D.

Material Management System

While there’s relatively little face-to-desk interaction in converting these PBR materials to an entirely new rendering engine, it’s a lot of work in Maya right now as I have to hook these monster graphs up manually. For the sake of illustrating our need for a good material management system and to assure you guys I haven’t been resting on my laurels, here’s Neon’s behemoth of a material graph. While the added flexibility of being able to manipulate materials at this level is very valuable, this kind of beast currently has to be configured and hooked up from scratch when either converting or making a new character. Transferring materials between scenes in order to re-use them adds data to the nodes which is a mess to clean up, and while I’m getting okay at understanding Maya’s pitfalls here it’s still cumbersome. 

TK had identified back when he started using Maya for environments that material organization is Maya’s Achilles’ heel, and I agree. It’s fine if you’re doing one big scene with unique materials, but it becomes really obtuse when you want to just quickly swap materials between lots of scenes and assets. We’re therefore planning on building a material management system, probably incrementally as opposed to trying to do it in one fell-swoop, over the next few months while we settle in.

We know one component of the material system would be preset barebones graphs for characters coming over from Daz, set up with Redshift material nodes corresponding to the Genesis 3 material zones. A second component would be a script with a UI that allows us to pull materials from a database file of sorts and apply it to geometry in the scene we’re current working within. This process would automatically strip off or organize the data Maya tacks onto incoming nodes order to keep things nice and tidy.

ZBrush: The Missing Link in Our Liquid Workflow

I really needed a break from character material conversion this last week. I initially took a day to check out ZBrush, the industry standard for 3D sculpting, with respect to how it might benefit our liquid workflow. After some early success, I ended up doing a four-day crash course in it and developing two techniques that have shown some really promising results. One for gooey, drippy liquid, and another for more complex, stringy liquid (I’ll have a good example image of this next time probably). Not only does sculpting the liquid directly offer the most control of any of the liquid techniques we’ve tested, it’s also surprisingly fast. I was able to sculpt the models in the above image in under two hours from scratch on my first real test run of the process. Here’s the high res version of the final image :D. 

Why look at sculpting though when we have our other techniques and tools Uber and I developed? Those still have their situational advantages, but each have some major drawbacks. The texture-based method is amazing for detail and for attaching liquid effects to materials, but two serious flaws are that you can’t paint textures over UV tile lines (separate objects mainly) in Substance, and things like drips or strings where liquid comes off the surface of a character require a nest of planes to be positioned in advance so the textures can be placed on them. Blending between the connection points of these surfaces isn’t straightforward. Simulation is great for massive amounts of liquid, but the simulation set-up time is really steep for smaller scenes that require more control. Using sculpting in combination with these techniques can make them both way more powerful. One example is that I can take Uber’s tool that generates geometry from displacement textures, and use the highly detailed models within a sculpting session – I simply have to place them and blend them in. Another example is that we could run fast, low resolution simulations and then add some serious detail with maximum control fairly quickly in ZBrush.

ZBrush’s unique workflow is the key to making this efficient, and one of the best features is that I don’t need existing geometry to sculpt onto. Using ZSketch I’m able to draw with geometry like I would add strips of clay to a real sculpture (minus gravity getting in the way), and then sculpt the details into it. It may seem counterintuitive that manually adding details is the most efficient way we’ve found, but the amount of control it offers makes it so. 

Anyways, it’s a good start I think, and I’ll definitely get better at it after more than a couple days of practice. We can also improve the look of the liquid further by adding planar texturing to increase variation, as well as bubbles either from Uber's Houdini bubble-izer or by adding them in ZBrush.  

P.S. this is still the Malise test rigging model, so some stuff like the gloves/body shape are still messed up.

Ubercharge’s Map Progress

Ubercharge has been easing back into working on maps these past couple of weeks. He’s starting by generally improving and revising the early maps we did in the new art style to work with his final post-processing workflow. This includes things like adding volumetric lighting and custom models / details everywhere to make the areas believable and better reflect the theme, as well as just generally get them up to par with the quality of his later maps now that he’s gotten the hang of things. 

He just finished the New Babylon Alley map, which is the map that the player starts out on in the next major release. I'm really impressed by the quality of it and this crappy Patreon thumbnail doesn't do it justice, so here are some high resolution previews :D.

• New Babylon Alley 1
• New Babylon Alley 2
• New Babylon Alley 3
• New Babylon Alley 4

AltairPL’s URGE Engine and Coding Progress

Feel free to skip to the [New for IC] tag if you read IC updates since the last monthly.

Just before the previous 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 said monthly I did the same thing for the remaining source code files. When doing this, I was constantly thinking about the actual 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. I 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 slightest chance of causing an error. To do this, I needed to sift through the 3rd party libraries documentation, which resulted in my constant bitching about the lack of inline documentation about possible erroneous behavior for most/all of the functions from those libraries and the need to actually check library source code to see what error can occur where. At the same time, I've 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 was hoping to get the error handling done relatively quickly, but I've seriously underestimated complexity of some things. In a lot of places adding proper error handling required some changes to existing code to either remove the need for error checking at all, or to make sure there's no memory leaks when non-fatal errors occur. On top of that, some places for various reasons required general overhaul anyway, so to prevent doing the same thing twice, I made the necessary changes before adding error handling to them.

Best example of this, and one of the biggest derails, is related to something that was kinda getting on my nerves in RPG Maker - error during image loading or audio loading/playing results in game terminating exception, even though warning should be more than enough in most cases. I've coded such missing file handling in Ruby game scripts some time ago, so for various reasons I decided to keep URGE behavior as is (throwing exception RM-style).

All functions related to image and audio files loading/playing were changed drastically. If error occurs, dedicated function is called and that function is raising the exception, so changing this to a warning later should be a matter of minutes. Order of things in those functions was changed as well, which makes error checking more streamlined, but also ensures that everything is properly freed, which prevents memory leaks when the exception is rescued from ruby code, or when I switch from exceptions to warnings. This switch will require a lot of testing and probably some changes to game scripts as well, so I'm leaving it for much later - at least I am prepared for it.

Another huge task was related to my custom low-level functions library. Main purpose of this library is to make functions that will be universal for any operating system - usually by having dedicated processing for systems like Windows that use different Unicode standard than most other operating systems. On top of the few existing ones, I've added few new such universal functions. And all of them are now fully documented and use proper error handling.

Also, while digging through the libraries in search for possible errors, I've found a few neat compiler attributes that my IDE can use to show warnings where appropriate, so I've added those attributes whenever possible/applicable, to make my life at least a little bit less miserable.

When I finally got through the error handling of most convoluted core of the URGE, the rest of the processing was refreshingly smooth. And good riddance, since I was really growing tired of some related crap I had to deal with. It's not the end of the error handling in the grand scheme of things, but the remaining stuff will be completely overhauled sooner rather than later or will receive some more love somewhere along the line. One of the examples of the latter is moving error logging from Ruby to C, which should be less hacky and more solid, but since the Ruby version of logging is working just fine, I can leave it for much later and concentrate on more important things.

During this whole error handling improvement/implementation I've found a lot of places that needed fixes and improvements as well. I fixed what I could on the spot, and marked less important and bit complicated stuff for later. One weird thing is a bit similar to one of the required things from my TODO list, so at least I didn't have to think twice about what to tackle next.

That thing from my list is "[REQUIRED] design/implement creation of encrypted archive(s);". Have been thinking about it a lot lately and I had some ideas about it I've jotted down in the meantime, but before I could start designing it in depth, I needed to experiment a bit to see what is possible and feasible and what is not. Thankfully, my favorite option seemed to be working just fine in the test case, so I decided to design the encrypted archive around it.

[New for IC]

After success of the test case, I decided to move to something more advanced, which was somewhere between the test case and the game archive on the scale of complexity. This went relatively smoothly and is working great, so I could remove the weird part of the code mentioned earlier. I also allowed me to refine functions which will be used for the game archive(s), which is very nice, since the archive in itself will be complicated enough, so I'll have one thing less to worry about.

Last few days of the month I've spent on designing the game archive, it's structure, when and how it will be used, etc. It's almost done, but I still have few minor things to figure out, like how to handle game hot-fixes, which should be part of the core functionality and not slapped on top of it, like I had to do them for RPG Maker.

Well, I think that's about it for this month. 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;
• [REQUIRED] overhaul error handling, reporting, and logging;
• [REQUIRED] fix whatever critical errors we encounter;
• [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);
• [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;

The Void – Market Props

Mr. Kittyhawk has been continuing his work on map props this month. 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. Here’s the result in video format!  We intend to use this quite a bit to add animations to our maps.  

Onyx’s Weapon Shop

I decided that one of the maps we were planning is unnecessary, and the story event I was thinking about for it could take place on another map. I figured a more valuable use of our time is to actually create an interior to Onyx’s weapon shop. I have my reasons, but I won’t go into it :D. 

Suffice to say, we need a lot of props. Mr Kittyhawk has been working on display cases and the like, and I’ve been hunting down gun assets and converting them to Redshift. I scored some great finds—good enough that it’s likely that the Splicers and other enemies will be able to use some of the weapons I’m converting.  They are all really modular, and I made sure to convert them in such a way so that creating lots of variations is no problem.

Here are some renders of Mr. Kittyhawk’s first display case prop along with the gun props I converted so far! 

• Gun Case Prop 1
• Gun Case Prop 2
• Gun Case Prop 3

In addition, here’s a set of renders I made from the guns I’ve converted so far. 

• Assault Rifle 1 
• Assault Rifle 2  
• Revolvers 
• Heavy Machine Gun 

Since there was lots of gun design talk going on, Ubercharge got the itch and painted up a concept rifle we may make for one of the villains/enemies.  

TK’s Maya Rigging Conversion and Automation Progress

Week 1 – Not Breaking Shit / Learning Python

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. :)

Week 2 – Face Rig Automation 

The auto-rig script is in really good shape now! I had to do several rewrites of key portions of the face setup, partly because I'm an idiot and crashed without saving in a long while, and also because my methods changed a few times partway through. With the rewrite, I did some cleanup as well. It's been bugging me how long this is taking me to learn and do, but there isn't much I can do about that. I hope this doesn't bite me later, but I'm not including much in the way of error-handling in this script. The nice thing about the Daz exports is naming consistency, which gives me a known set of data to work with every time.

I had discovered that my previous setup for the eyeballs and eyelids was not going to work in general use, but especially not work when it comes to loading presets from Daz. But, this was one of the first areas I tried to tackle knowing that it would be a problem area, and I know more now. I guess I can consider that a beta version. I'm in the middle of setting up a new and improved configuration at the moment that should do everything it needs to and not flip everything the wrong way.

*Update* I managed to get this sorted out before Ero posted the update -- had a few kinks along the way. It turns out I was thinking backwards through my hierarchy while creating this new configuration. It's a big improvement and uses no extra math nodes this time- everything is rotating and blending as it should.

Once this eyeball/eyelid setup is done, that should be it for the meat of the character setup. Just need to plop down some file importing and some UI buttons and we'll be in business again! There will have to be a second stage to this for automatically converting and setting up materials. I expect that part to go much smoother and quicker.

On a personal note, it's nice to have this kind of growth in the scripting area. I still haven't done any serious modeling in a while, but I'm learning many things that will be helpful later on, even in modeling.

Week 3- Things Got Weird

Whatcha think of TK’s masterpiece? Lucky for us he’s not doing the actual posing :D. Check out his progress report:

So here's the finished result of my working face rig in animation form! My last post concluded with me with another new-and-revised Eyeball <> Eyelid interaction that also didn't work. I've since fixed that and you can see it in action in the first half where the eyes are moving. Now the eyelids are properly driven by the rotation of the eyes automatically, while the sets of override controls (in red) able to layer their own movements on top.

A frustrating thing that I kept running across and still don't understand, is why I can't "chain" constraints in Maya. Say I have two objects, a parent and a hierarchal child. I can attach a constraint to the child, and freely rotate the parent manually and both work. But when I add a constraint to the parent for rotation, only the parents rotation works, the child can no longer rotate from its constraint. Or instead if I pipe rotation values to the parent directly from a controller with no constraint then everything works, except that I don't have the offset that the constraint nodes provide. So I found a good in-between solution of using so called "driven keys" which are small animation curves to link objects together. This lets me keep my offsets, works with a child constraint while also acting like a damper where I need- The eyelids don't rotate at the full values the eyeballs do. Annoying, but at least it works.

So now after some tweaks and fine tuning, I'm back on the main part of the character setup. Just a few small changes (i hope) to how object naming gets corrected from the FBX imports and building the UI and its functionality.

Week 4 – TK Replaced by Replicants 

Whew, finally finished with this rig and script madness for now. But I'm swapping over to Daz Studio madness for a while, not sure which is worse!

I ran into some nasty kinks creating the UI for my conversion script. It turns out that Maya's FBX import API is Mel script only (Maya Embedded Language- it's old and clunky), and has some weird side effects when it comes to functions, scope, and passing variables. I needed the UI to present a browse button to pick a file, giving feedback on the chosen .fbx file, give feedback on the location of the associated helper script that Daz exports, then do the actual import. Normally this is an easy task, but no, nothing is that simple! I learned that I needed to pass a variable from python to mel, in a python line, then tell mel to import with that variable. Worked fine in testing, until I wrote it up in a function, turns out there's some scope issues that require some extra care. Worked fine in my testing function... until I tried to run it from a file instead of the script editor. Turns out there's even more to this particular scope issue that required even more special care. All is well now at least, and the whole thing works now without any babysitting! The UI isn't very pretty, but meh. I plan on adding some extras later when I have time, it would be nice to have easy access to some post-fixes that we can't fully automate, or add additional controllers to props or hairstyles that have joints in them- it just makes life easier when working on scenes.

At the moment, I'm making some final fixes for Malise’s trip to Maya. Some morphs need adjusting, Daz partly ignores her eye transforms on export, and her gloves/boots rely on Daz 'HD morphs'. The boots and gloves are giving me a bit of pain at the moment; the concept is simple, but the software isn't agreeable it seems. The morphs are already fixed, and I'm not sure how to fix her eyes just yet, it might be something we'll just do in Maya.

PS. I was replaced by replicants.

Moving Ahead!

The timeline has been getting progressively more confusing with the Maya conversion, but our next milestone is still Battle Test 4 / the Enty launch. From a player’s perspective, here’s what that release will contain: 

• Full lust system enabled, including all stages and armor damage for both characters
• At least one example H skill chain
• Potentially the new combat user interface

Here’s a list of goals we need to accomplish to make that happen: 

Maya Conversion Stuff

• Convert materials for genitals
• Convert the police enemy from Genesis 1 to Genesis 3. Genesis 1 uses TriAx rig weightmapping, which is completely incompatible with any modern 3D app. 
• Update Neon’s base Daz scenes to match her model we’ve been using for the recent battle tests. Need to do this before converting to Maya.
• TK’s rigging conversion (Daz to Maya) pipeline and scripts need to be functional and relatively bug free.  I believe we’re at that stage, but haven’t gotten to do a new full test of the pipeline. 
• Get Malise, Neon, and the police enemy rigs working in Maya (this shouldn’t be a problem at this stage, but again we haven’t gotten the opportunity to test TK’s scripts on different characters yet).  This includes props like hair/genitals. The further TK refines his scripts/process before we do this the less we’ll have to revise later. 
• Convert Malise/Neon’s battle poses from Daz to Maya and make fixes where necessary.
• Lay the groundwork for portrait rendering automation in Maya and get a basic system working (this will be a huge timesaver, so it’s worth investigating as soon as possible). 
• Render all the portraits up through Battle Test 3 in Redshift and get them hooked up to our lighting system. Will likely knock out a script for simplifying that last part, since any future full re-renders will be impractical to set up by hand.

Other Tasks for Battle Test 4

• Finish Malise’s 3D armor damage
• Pose/render the later lust stage / armor damage portraits
• Develop H skill chain and artwork for police / both characters
• Potentially revamp combat user interface

I’m sidestepping a few tasks here that aren’t completely essential in order to get to Battle Test 4 faster. Once we reach that milestone things will be back to their usual heightened level of chaos and we’ll be able to continue putting out test releases as we push toward the next major update.

--------------

The next major update, which will be v0.10 if we make it into the URGE engine or v0.06 if we don’t, obviously still has a lot of work to be done in terms of content. Things will start transitioning heavily from the technical side for me and TK to content once the Maya conversion is done, and for APL either when has URGE production-ready or we decide he needs to jump onto content-specific tasks.   

The task list is still pretty scary, so I’d rather wait till we’re standing on the achievement of BT4 to hit you with it. That said, I want you guys to know we’re not offended if you can’t stick it out and would rather wait till we’re putting out content again. The fact that so many of you have to this point is fantastic to us, and shows it how much this community wants (and in my opinion needs) a high quality H-RPG.

Outside of the Enty launch, which is a new audience, I’m still determined not to push promotional stuff and go asking for more money until we’re ready to launch the next major version. At this point I’m confident it will be exceedingly special, it’s just a matter of getting there.  For those of you sticking with us, your pledges are doing a ton by offsetting the amount I’m putting into the project out of pocket at this point, so know that it’s especially appreciated!

Thanks again for everything guys!