August Progress Update (Part 2)! (Patreon)

This time we’ll be talking about the progress on v0.06 map design, including some new images of Ubercharge’s handiwork. AltairPL also has an update, where you’ll get to see some shots of MATM running in RPG Maker in 16:9, and lastly there are my experiments with fluid simulation. There are also a couple of new shots of Ubercharge’s materials skills where he gives an example of how we can very easily add bubbles and additional details to 3D liquid using only textures and displacement mapping.

V0.06 Map Progress 

Now that Ubercharge is all caught up to speed, he spent some time working on his implementation of a set of map concepts we drummed up early this month. The maps depict the entrance our heroines take into the Void, New Babylon’s lawless district left to rot in the hands of the criminals and the unfortunate. The Void is surrounded by a perimeter wall, and our characters have to find a way around the police checkpoint blocking their way in.  

I’ve created a video slideshow depicting Ubercharge’s modeling work and our progress in bringing the environments to life. If you’d like to check out the images in full, here are a few albums where you can do just that!

Map Progress Album 1

Map Progress Album 2

Map Progress Album 3

Overlooking the Void Early Concept

AltairPL’s Programming Update

AltairPL here! If you are Inner Circle member, feel free to jump to [IC new] tag - everything before it was already included in July IC updates.

Just as planned, after finishing my rendering optimization clean-up, my attention turned towards RPG Maker's Window class. And I'm kinda glad I did, especially since implementing it was always uncertain. While coding and testing basic functionality of my implementation of the Window class, I've stumbled upon a problem which was causing game freezes in certain conditions. The problem was entirely my fault - I've botched Ruby => C number conversion and in certain conditions and it was causing an integer overflow, and in turn throwing the game into an infinite loop. The bad news is that it was not the only place where I made the same mistake, so I had to trace back all similar conversions, analyze them thoroughly and fix when necessary. The good news, and the reason I'm glad I started working on the Window class, is that I've found it pretty early and in controlled conditions, so it was relatively easy to pinpoint and fix.

Anyway, while fixing the overflow issue, I've also fixed another small issue and found out that some debug information isn't properly outputted. The latter was kinda complicated and only affected me, so I was going to leave it for later, but some hard to pinpoint crashes changed my mind quickly. So, I went and fixed the problem with debug messages not being properly outputted in most cases. This fix was well worth the time, but had one additional and not really intended side-effect. RPG Maker suppresses all Ruby warnings, which makes the programmer, such as me, a bit lazy/oblivious when it comes to some coding conventions. So, when I fixed the problem with debug messages I was literally flooded with various Ruby warnings. I'm happy to say that none of those warnings was a sign of something botched, but it was way too much information every game start/restart. Since I was already derailed, I dove into the Ruby scripts and fixed all warning spawning code that I was aware of... there's probably a few more of them hiding in the shadows, but I'm already lighter by roughly 800 warnings every game start/restart. Some fixes were as easy as typing a few characters, but some required a bit more work. On top of removing causes for warnings I also cleaned up a few related things, organized a few things a bit better, removed one or two obsolete pieces of code, etc.

With better debug information, I was able to finally make some progress with the Window class implementation. I've also fixed one major problem related to rendering and started suspecting one piece of code of being a potential source of memory leak... I tried testing it out, but was unable to verify it, so I've left my future self a note about keeping an eye on it and moved on. To recap, the Window class implementation is almost done, but remaining things are a bit complicated and not used by us, so I've left them for later.

[IC new]

The next step was decided after compiling and cleaning up my notes when I noticed that implementing shaders will take care of the following three entries from my TODO list:

• I don't want to go into details, but every use of sprite's tone/color required extra amount of VRAM and it was bothering me a lot;
• RM's Tone, besides standard RGB components, have gray component, which is used to desaturate the image before applying RBG components to it - it was impossible to implement it without causing severely impairing performance;
• Since I've learned about SDL_gpu's capability of using GLSL (OpenGL Shading Language) I was wanting to give it a shot, while being afraid of it at the same time.

Anyway, after reading about GLSL and experimenting a bit, I've learned enough to actually attempt using shaders; what I did can probably be considered as something very simple, but it does the job I wanted it to, which is on-the-fly application of tone/color/flash for sprites/planes/etc. There are 2 problems with it though. The first one is that it messed up something I did earlier... kinda forgot about it before moving to next thing, so I should really fix it ASAP. Second problem is that it's a bit slower than previous implementation, but all things considered, I think that the gains far outweigh the costs.

Lately, we had few discussions about the direction of the game, engine and artwork overhaul. One of the points was changing the game aspect ratio from 4:3 to 16:9. Testing game's readiness for 16:9 was my last task in July and it's something I'm still knee-deep in. For various reasons we've decided to change current game resolution from 1024x768 to 1280x720 (mainly to get the art team working in that aspect ratio sooner rather than later). A lot of images like backgrounds will have to be redone, but that's not my department. Maps, battles and most menus are working and looking great, few menus will require some changes to fit everything on the screen, and one menu is causing an exception. I had some problems with Planes (a class used for graphic layers), which are hard-coded in RM's DLL, but fortunately I was able to fix this. What I couldn't fix however is another thing hard-coded in said DLL: for some reason transitions are limited to 1024x768 area... oh, how I hate Enterbrain and their ways. I'll probably have to code some kind of replacement in Ruby for vanilla transitions - got one or two good ideas for that. With re-coded transitions and updated/redesigned UI, we should be able to make the 4:3 => 16:9 change in time for v0.06.

Here are a couple of screenshots showing the game running in 720p!

Map Scene 

Battle Scene 

Fluid Particle Simulation Fun Time!

So, what started out as a simple experiment with fluid particle simulation ran on for three days. I intended to let it wait for the artwork overhaul, but ended up digging deeper after some early successes.  3D fluid simulation is something I’ve wanted to attempt since starting the project, as it could potentially mean a huge reduction in work required for getting good looking happy juice all over our lovely ladies. Currently I paint it all manually, and while it works well it’s also very time consuming to do properly. Let it be known that I’ve seen some really bad attempts at 3D liquids in 3D porn, and I would only consider doing it if I could make it as good looking or better than the current method.

My first attempts at accomplishing this were using Maya’s Bifrost simulation package. After climbing a big learning curve I was able to get pretty damn good results, however the problem is that it is extremely slow when working at the detail required to get said good results.  And this is with my beast of a Xeon processor churning away on all 22 cores. Here’s a video of a relatively early test at a much lower detail level than is required to get the effect we need (not to mention it’s not viscous enough).  Note that the test was using Maya’s hardware renderer on a liquid with no material, meaning it looks very solid (like milk). For all of these tests I was focusing entirely on the geometry and dynamics aspects of the liquid, meaning I was trying to get the dynamics and physics right. I eventually moved to a test scene where I tried physically enacting some cumshots to see how it turned out.  This is where I was able to tweak the physical parameters of the liquid to get some great results, but it’s also where I figured out that the processing was too slow to be practical. A simulation requires about 50-100 frames to get what I’d need out of it, and these higher end tests were running about 20-30 seconds a frame.  

Despite the mixed results, here’s a set of images from my experiments with Bifrost.

I later felt the need to heed Ubercharge’s recommendation of trying Houdini out. So, a second round of testing took place with Houdini. As with Bifrost, I believe the potential is absolutely there, however getting the proper fluid physics/dynamics in Houdini proved to be a greater challenge, and thus I’ll need to revisit it later. The good thing however is that Houdini performed significantly faster than Bifrost once I got past some early issues. 

After the physics and geometry tests, we took turns seeing if we could develop a quality material for the 3D liquid.  The simulations generate the geometry, but it's this that gives it correct color, opacity, reflectivity, details and so on.  Here are our initial material tests, followed by a new one of Uber's in which he shows how bubbles and other details can be added.

All in all, I think there’s potential here, and I want to revisit it during the art overhaul when there’s more time to learn and experiment. 

Stay tuned for part 3 tomorrow, where I'll discuss how we plan to convert our Daz characters over to Maya, as well as all the potential benefits it'll provide!