Inner Circle Update for July 9 2017! (Patreon)

Hey guys!

I have a bunch of various topics to talk about this week, so let’s get into it right away!

V0.06 Map Progress

Ubercharge spent some time this week working on his implementation of a map concept we drummed up I think last week. The map depicts 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. Here’s an album depicting his work on it (it’s still a work in progress), followed by a paint-over test I did to test lighting and processing. 

Transition to Redshift

One of Ubercharge’s specialties is being able to quickly create physically realistic materials. He does this using a physically based renderer (PBR) called Redshift. He has pretty easily convinced TK and I that transitioning from Mental Ray to Redshift for map creation is a good move, and with TK’s help he already has the basis for TK’s map creation workflow working with it.

Obviously, our game’s art is highly stylized, so why should we be looking at PBR? Basically, stylization doesn’t mean the materials have to look simplistic. Overwatch is a great example of a stylized game that uses physically based rendering yet maintains its own look.  

Here are some of the potential benefits of switching to Redshift:

• It’s a GPU renderer (uses the graphics card instead of CPU). 
• Better lighting effects such as global illumination and reflections 
• Rounded edges via renderer 
• Procedural dirt, puddles etc.. (image by Ubercharge)
• Much faster render time than Mental Ray, which took a long time without any calculation intensive scenes.
• RS has much better shaders, where we can create absolutely any material you can think of. 
• Good integration with Substance Designer and Substance Painter outputs, where we can use metalness/roughness textures that are in newer licensed assets. 
• We can quickly recreate better shaders for old assets we had since it offers high interactivity during render testing.

That’s not to say it won’t take some tweaking to get it to fit our style. The lighting test render for the map above was done using Redshift, and I’m looking forward to Ubercharge’s final textured version to see how it compares to our old methods. 

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.

Early today I felt the need to heed Ubercharge’s recommendation of trying Houdini out. So, a second round of testing took place today 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. 

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. 

AltairPL’s URGE Engine Progress

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 is kinda complicated and only affects me, so I'm going to leave it for later.

I'm now back to Window class implementation, and with luck, I will be able to finish it this coming week.

Asphalt, Again! (TK’s Concrete Mixer, Part Two)

TK here! More and more and more Substance Designer work, and payoff! The “concrete mixer” I started last month is finally working! Four fully-featured sets of parametric textures, and a couple simple ones to back them up. I'm happy with the result after seeing them all put together. However, I did hit some technical snags, so my big ultra-genius cracks generator is dead in the water still, but I'm still hopeful. Here’s a quick little example of a non-tiling road surface created with the mixer. Some minor things still bug me in the actual putting-together process that left me with more manual painting than I had originally aimed for (see the two obviously repeated rocks along the bottom in the render, which I could have painted out).

Uber has finally convinced me to try out some other rendering techniques as well as another software for rendering, which I used for this first time here. This was nearly out of the box and I'm very pleased with the quality and speed, though I have a thing or two to learn about properly setting up Redshift to make a prettier picture. The displacement and normal mapping don't show up at all here, causing it to look quite flat.