- Oct 28, 2017
- 253
- 295
- Aug 7, 2016
- 1,910
- 2,575
- May 6, 2017
- 3,987
- 30,415
Why? We don't lock threads for abandoned games, if that's what you mean.
- Aug 7, 2016
- 1,910
- 2,575
After that you cant tell us to not bully the devs anymore lmao
- Jun 16, 2017
- 649
- 887
Of course he can he has Green Belt and most of us don't even have basic Dan.
I will type that again even if it get's deleted again.
The ULMF forum closed thread about MatM in 2017 because there were no more content to talk about.
In Fact, Year later there is nothing to talk about.
So mods closed discussion because it started to take form of people trolling each other out of frustration or just defending Developer. The latter was frustrating people even more.
In short, thread was closed to prevent an eruption of Autism.
We don't know if this is scam or no so the best thing to do is simply close the case...for now.
>But Xenon you can just ignore this thread.
Yes and people can ignore my comments as well.
However it would seem like begin an asshole about a guy who delivered hist last demo over two years ago is not welcomed here.
This thread should be buried unless mods can't unlock locked threads.
- Oct 26, 2017
- 163
- 227
ULMF is a different site... They do what they do and have their own culture and processes. Personally I like that we're not a clone of ULMF, and I like that abandoned games can still be discussed freely here... You're not really making a case for why we should treat this one particular thread differently to all the others on this site. After all you can simply stop visiting this thread at any time.
- May 6, 2017
- 3,987
- 30,415
Your posts were deleted not because they were criticizing the developer, but because they were name-calling and trolling.
And for someone who keeps saying the thread should be locked, you sure do keep coming back to the thread to post yourself over and over.
- Feb 1, 2017
- 2,799
- 27,549
You don't have permission to view the spoiler content.
Log in or register now.
- Aug 7, 2016
- 1,910
- 2,575
- Nov 4, 2017
- 556
- 819
- Feb 4, 2018
- 565
- 1,229
It is a long ass update and takes up huuuuge amounts of space here. I lazily copy pasta'd it, if a mod wants it to be removed, please do so.
EDIT: Put a spoiler on this badboi because silly me didn't think of it when i first made the post.
You don't have permission to view the spoiler content.
Log in or register now.
EDIT: Put a spoiler on this badboi because silly me didn't think of it when i first made the post.
- Aug 6, 2016
- 494
- 375
Thanks a bunch for the sharing the update. If you're worried about a mod removing your post then just put the whole thing under a spoiler tag so that way it'll at least be hidden.
- Aug 7, 2016
- 1,910
- 2,575
Thanks a lot for the update.It is a long ass update and takes up huuuuge amounts of space here. I lazily copy pasta'd it, if a mod wants it to be removed, please do so.
July 2018 Progress Update!
$3+ patrons
Jul 2 at 3:42pm
Hey everyone!
We’re winning our battle in the conversion to Maya/Redshift. 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
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 (You must be registered to see the links). I decided to go back to square one and reverse engineer the differences between Iray and Redshift’s subsurface algorithms byYou must be registered to see the linksand 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.You must be registered to see the links
You must be registered to see the links(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
Neon’s Material Conversion
Neon’s material conversion is mostly done besides some work on the eyes, hair, and a couple texture seams.You must be registered to see the linksYou must be registered to see the links.
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 JuneYou must be registered to see the linksI 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, butYou must be registered to see the linksin 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
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,You must be registered to see the links. 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.You must be registered to see the linksin the above image in under two hours from scratch on my first real test run of the process.You must be registered to see the links
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. UsingYou must be registered to see the linkslike 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
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:
Things still to do 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;
- [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.You must be registered to see the linksWe 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
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!
In addition, here’s a set of renders I made from the guns I’ve converted so far.
Since there was lots of gun design talk going on, Ubercharge got the itch and painted up
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?)You must be registered to see the links. I'm glad we ran through that early, it was unexpected and I was worried that it would be a large setback.You must be registered to see the links
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.You must be registered to see the links- 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
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:
Here’s a list of goals we need to accomplish to make that happen:
- 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
Maya Conversion Stuff
Other Tasks for Battle Test 4
- 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.
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.
- 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
--------------
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!
I cant actually believe they are making fucking cupboards now tho
- Nov 4, 2017
- 556
- 819
Is it just me or they are really aiming for AAA type of graphycs? They know this is indie RPG Maker, right? They would need much more money to make this a AAA. I was thinking this was just a scam, but now I think that the problem is their project management.
The only AAA level graphics (I would say Playstation 3 level) indie adult game I ever saw was from yiffalicious, and that game took years to be made and was just the scenes and modification support, no more than that, a scope far smaller than they are trying here.
Oh well, at least IF they manage to make this cores work they will be settle to make Donkey Kong style of sprites, bringing AAA level graphics to weak PCs, a Thing they can use for many future games. IF they can make it. I will still keep an eye out for this. Maybe in 10 years they actually begin launching great games, who knows?
The only AAA level graphics (I would say Playstation 3 level) indie adult game I ever saw was from yiffalicious, and that game took years to be made and was just the scenes and modification support, no more than that, a scope far smaller than they are trying here.
Oh well, at least IF they manage to make this cores work they will be settle to make Donkey Kong style of sprites, bringing AAA level graphics to weak PCs, a Thing they can use for many future games. IF they can make it. I will still keep an eye out for this. Maybe in 10 years they actually begin launching great games, who knows?
I think they have reached AAA graphics, Eromancer's skillset and dedication to improving his 3D art skills is amazing. Look at one of the comments in the above, 4 day crash course in ZBrush to learn object modelling. I don't disbelieve that, ZBrush is hard to pick up. This
You must be registered to see the links
is really, really good.Project management, in delivering game content is clearly an issue. So you look at rendering which I'm interested in and you have; original start with 3Delight and extensive use of photoshop (the slight cartoon style), then a shift to Iray and then a further shift to Redshift. Iray being a backwards step in my view, with there being a lot of people pushing out good Iray images. In the update above is mentioned months of rendering, I can easily believe that.
- Nov 4, 2017
- 556
- 819
Pardon me, I'm not familiar with those programs (3D modeling engines maybe? Like blender?). I don't understand what your last paragraph says. Is this Redshift easier to use? At least enough to worth the time to converting the assets to it? Because the first photoshoped graphics were good enough, already far beyond anything the 2D adult market had shown us. And while I agree that those images are really fantastic, I see very little difference between that Iray and Redshift in the comparison image.
Can you please explain me what exactly are they "wasting" their time?
- Feb 4, 2018
- 565
- 1,229
Done. Didn't think of it at the time because it was kinda early ulu. Thanks for reminding me
To cover off the 3D side, what they have done is moved too professional tools. In really simple terms Maya is a better version of Daz, Redshift a better render engine than Iray, and ZBrush a better modelling tool than Blender. All of them come will annual license costs, maybe $3k in total (unless they are students).
Are they wasting their time? Workflow wise it seems slightly better, on the basis that the export from Daz to Maya works nicely and the rendering time is reduced 50%. From what they saying it looks like they have dealt with all the key issues in making it work, but they have not tested it in quantity (say rendering 100 images). So if they hit issues with posing in Maya, then you have to pose in Daz, then export to Maya, which will probably defeat the time saving. My view is that I'm technically impressed, and I'm optimistic that it will work.