eromancer
patreon
Inner Circle Update for September 11 2017!
🕑 Added 2017-09-11 13:31:46 +0000 UTCHey guys!
We all came off of the monthly update needing a break, so I think all of us took a couple days before jumping into new stuff. Nonetheless, we have some stuff to show off below!
Map Progress
Ubercharge is back home, so he’s been able to begin working on maps again!
He started out the month by finishing up the geometry for the first of the Void’s Perimeter Wall maps. He’s also begun working on placing structures for another of the city maps. We intend to try some neat atmospheric effects on this one, such as animated steam coming out of vents in the street.
I worked some on concepts for the parallax background of the perimeter wall map. The original idea was to create a city sprawl that the player would view perched atop the wall, however we’re now thinking about doing a sort of dystopian Kowloon-Walled-City-inspired backdrop with towers of slums. Sorry, the only image I have of it is this concept-stage photo of my screen when I crashed Maya by running out of VRAM (I need to learn to use instances). This was about the time I decided to upgrade my hardware, as mentioned at the end of this update >_>.
Compositing and Liquid Testing
We sort of killed two birds with one stone here. The following tests evolved from an experiment Uber concocted with the goal being to composite renders from Iray (in Daz Studio) with renders from Redshift (in Maya). The test turned out however to be a good opportunity to test the liquid materials we’ve been working on, and I think we’ve made some progress there because of it.
First up is the compositing thing. Being able to incorporate renders from Iray and Redshift into a single piece is a pretty valuable piece of functionality for us, and could possibly serve as a backup plan if we can’t fully convert our characters to Maya during the artwork overhaul. Using this method, we could do things like use monsters created in Maya and rendered in Redshift in H scenes with characters from Daz / rendered in Iray. One element of difficulty in doing this is that light and shadows would be heavily affected by characters/creatures in proximity to each other, and since PBR rendering isn’t as forgiving as our previous style it’s not as simple as masking the characters out in Photoshop and plopping them in the image. A second is that layered, translucent liquids simply can’t be masked easily.
Uber’s solution involves taking a completed Daz render of a character, and projection mapping the image as a texture onto a static model of the character/pose that’s been imported into Maya. Here are a few images of this process. We then import camera and light positions from Daz to approximately reproduce the Daz scene in Maya (once we standardize our lighting for portraits we’ll be able to have matching lighting rigs in both programs, making the task of matching the lighting much easier).
To show a full test of this technique, Uber decided he would composite a basic slime prop onto Onyx with his custom WIP liquid material. This is a difficult task due to the translucency of the liquid, but the technique worked great!
Naturally, doing this turned into a chance to work on the liquid materials more, so I took a stab at it in Daz while Uber worked on techniques to add subtle but advanced effects such as bubbles and texture. While none of this is representative of the quality we should be able to manage when we get around to actually generating liquid geometry via simulation, it’s a good step in creating accurate materials that should work in a multitude of situations.
AltairPL’s Progress Update for Last Month
So, I noobed up and forgot to include AltairPL’s progress update in the monthly update ;(. Here it is!
AltairPL here! I started August with a long list of immediate TODOs, but instead of shrinking, it only grew bigger. That doesn't mean I made no progress, though -- the list below may not look too impressive, but I'm pretty happy with my accomplishments this past month:
- Did some experiments with OpenGL shaders to see what else I can achieve with them, like few not yet implemented RPG Maker things, or one crazy idea that had potential to somewhat improve map loading times and memory usage.
- Implemented RPG Maker .ini parsing to get rid of some hardcoded stuff.
- Implemented RPG Maker script database loader, and modified exception (error) handling to make sure that database scripts are aptly named in both exception message and backtrace.
- Made preparations for a huge batch of basic URGE functionality, but a cold slowed me down, and most of the planned changes ended as notes/comments.
- Coded and maintained the lighting test environment, which helped Eromancer to relatively easily test various lighting scenarios for the new sprite lighting system.
- It was planned for later, but I've designed and added to the test environment a prototype for simple character reflections.
- Did a lot of URGE-RM compatibility testing, and in the process: fixed few URGE bugs, added a few compatibility flags to URGE, fixed few scripting bugs unrelated to the engine, etc.
- Made dozens of small changes to both URGE and ruby game scripts, most of which I don't even remember.
AltairPL’s Progress Update for this Week!
The “basic URGE functionality” mentioned above was my main time sink in September so far. Most of the stuff included in this was until recently hard-coded into the engine, and most of it was poorly made since I was just starting my C adventure then.
One of the things that was impacted by this was interoperability of URGE executable with MATM's RPG Maker project. Some things were working by supplying a simple path variable, but many things required making copies, and working on two basically identical copies was not only a huge waste of space, but was also making maintaining both a nightmare (e.g. increased chances that I will change one build and forget to update the other). So, a huge chunk of my time was spent fixing this, and not counting few weird problems, I managed to do this. I can now easily use URGE along with MATM RPG Maker data, which makes testing things in both engines a lot easier.
While doing the above, I also thought out and started implementing a new URGE data structure which will be needed/useful sooner or later once I decide to make a version for 64-bit Windows or other OSes (like Linux, or MacOS). To be honest, I don't even know if it will work like I want (and most certainly support for other operating systems is a thing of the (distant) future), but I like to be prepared and hopefully it will pan out.
Another very important piece of functionality is moving some options from source code flags (changing flag value requires exe recompilation) to ini file (changing flag value requires only an app restart), which will make setting up and testing stuff way easier. Most of this stuff will be used only by the dev team and won't be available for end users, but I'm also planning on including some end user options, like "wait for vsync" flag, "scale filtering" mode, etc. With time, those options will most likely be moved to the in-game menu; hopefully without needed restart, but this will have to suffice for now.
All of the above, even though advanced already, still requires a lot of work and is my current work-in-progress, but I'm already very happy with it.
Story Cutscenes in Premiere
The first thing I did (besides drink way too much) after the monthly update was to experiment with an idea I’d been thinking about since I started using Adobe Premiere for video editing. I’ve been wanting a better solution for creating the animations for story cutscene events for a while, and now I’ve got one!
Creating the cutscenes in RPG Maker is pretty much as low tech as it gets. All the animations are done via code. Basically, I have to position every image by its coordinates manually, and every time an image is moved/zoomed/rotated/whatever I have to compute the new coordinates by hand (and by guessing since there’s no way to preview it).
What I’ve found is I can set up Premiere’s video sequencer to act as a cutscene editor. By setting the coordinate system to match the one used in RPG Maker and URGE, and by using frames as the timecode instead of time, I effectively have an environment where I can create cutscenes as a video, adding cues for things such as message boxes and events. Once that’s done, I can use the information stored in the sequencer’s keyframes to get things such as coordinates and frame numbers for events, and use those to create the code for the cutscene event in engine.
Still low tech, but this solution will probably cut a week of work off of v0.06 alone.
Ubercharge’s Monster Sketches
There was some discussion in one of the previous threads regarding monsters, and I think it inspired Uber to spend some time sketching ideas while he was still out of town. Being able to break away from licensed assets and create our own creatures will no doubt give us some freedom, and if these quick concepts are anything to go on we should see some really detailed stuff in the future :D.
Hardware Upgrades
Long story short: Ubercharge has purchased a new rendering rig and is waiting for it to arrive, and I took a more masochistic approach and redesigned my system for GPU rendering.
Upgrading hardware isn’t something I thought I’d need to do for a while after building a new rig earlier this year. The change to physically based rendering however means we are now using GPUs for rendering as opposed to CPU (no worries, the monster CPU will be used for liquid and physics simulation in Maya). Naturally, this is the one thing I didn’t go all out on, so I took a couple days redesigning my rig by adding two GeForce GTX 1080 Tis. This should’ve been pretty simple, but due to the size of the cards I had to remove the M.2 drive I’m using for cloud syncing and replace it with a standard SSD to free up space on the motherboard. It took a couple of days to sync the new drive to our cloud, but I’m now back at 100% and rendering approximately 3.5 times faster. Ubercharge’s new system has a similar GPU setup, and will be a dramatic improvement over his old hardware. I’m looking forward to seeing what he can do with it!
Comments
Maybe a set of sprites, at 25% kinda wobbly on their feet. 50% wobbly limping while holding abdomen. 75%+ crawling/drag movement with semen trail behind them. For movement condition check. I don't expect this, but it would be a nice little thing I wouldn't mind to see and maybe it could be added at a later date.
Probably have to make a body dragging sprite animation for the map with semen trail behind them. Personally not sure how they would be walking after Stiggy got 'em, synthetics or not.
Antilles
I've been thinking something similar, like whoever gets fucked by Stigmata should get some sort of negative from it until they get to an ARIS station.
MB
On the monster kick: Maybe one that if it finishes it's h-grapple sequence without being killed or removed from the character, it 'binds' to them with status affects (slower movement, increased rate of arousal, limits on player actions in battle, etc) until the player visits the nearest medbay. Creatures that themselves aren't a gameover, but will make it that much harder to survive battles. Might be tricky dealing with multi-creature animations though, unless some of these rendering and engine overhauls begin to allow for that flexibility.
Kurowscar
Yesss! Those monsters look Dead Space inspired! Honestly I'm a little sad because it's likely going to be several months/a year before we move past this level so until then I'm gonna be pretty antsy to see the hardcore stuff!
myself yourself
love this slime already :D
Venus
I'm in love...
Noodledoodleopolis
That pic had me goin nuts for a minute. My last PC died so I just built an upgraded one. Cant wait to play the next version on this thing.
Tadd Morgan
This all looks amazing, I am so excited to see what is next for MatM!
