Concertroid! Engine - on a translucent screen! (courtesy of Re:VB-P)

Re:VB-P, developer of the similar VOCALOID-inspired concert animation software AniMiku, has agreed to do a test run of my software on his own translucent screen and projection system!

Collaborating with him on this project, I'm learning a lot of things about 3D modeling and animation that I would've probably never understood otherwise. While he demoed his projection system running my software, I took a couple of pictures to see the difference between his software, my software, and the official concert renderings used by Crypton Future Media, in order to better understand where my program needs improvement.

Here's what I will be working on in the near future:

• Cleaner edges (antialiasing)—Most noticeable in the Blu-Ray release of the 2010 VOCALOID concert by Crypton Future Media, the lack of antialiasing in 3D models causes the edges of the character to appear sharper and, though not usually noticeable while in the audience, becomes much more apparent during filming, especially close-ups in high definition!
• Improved rendering—Using the default settings already provides a much better render of the character than MikuMikuDance, which applies a more anime-like shader and defaults to drawing edge lines throughout the model, something that simply doesn't look right in a concert. However, there is always room for improvement, and adding support for HLSL/GLSL shaders is something to look forward to in the future.
• Faster rendering—The software currently takes around 50ms to render a single frame on my ASUS computer with integrated graphics card and 4GB memory. While I plan on having a much better dedicated rendering computer for any concerts I present, I would like to fix all the things that my program might not be doing "The Right Way" that is causing it to be so slow.

And finally, some screenshots. Special thanks to my friend and colleague Re:VB-P, developer of the AniMiku virtual concert animation software, for providing the screen and taking the time to demo my software on his setup. AniMiku has been used for live events around the world by the VOCALOID producer group Vocalekt Visions. Re:VB-P also helped identify a crippling bug that never showed up on any of my computers, but sometimes happened on other systems—particularly those with third-party graphics hardware.

Concertroid! rendering with lights on

Concertroid! rendering with lights off

Universal Editor module for VMD file format

Finally finished the excruciatingly painful analysis of the VMD file format (versions used in both V1.30 and V7.39 of MikuMikuDance). I'm rather proud of it because it's the first time in a long while that I've actually figured something out just by tweaking values, not actually looking at other people's (free) source code.

I added support for the VMDMotionDataFormat in Universal Editor, so hopefully when I get around to finishing the animation system for my renderer it will be able to read (and convert!) VMD files generated from both versions.

This was excruciatingly painful primarily because of the way the bone frames are stored. It was interesting to notice that the only difference between V1.30 and V7.39 file formats (besides the model and bone names) were the field sizes of the model name (10 bytes in old version, 20 bytes in new version). But the way the frames are stored is hideous.

For each keyframe, it stores the bone data block (name of bone, position and rotation of bone, and interpolation data) for each bone affected at the keyframe. This is not that big of a deal... except that the keyframes aren't actually stored in the order they should appear during playback. They're stored apparently randomly, though presumably (I haven't tested it) in the order that the user adds them to the timeline. I ended up making a class RawFrameData to store the frame index and bone information, storing all of that information in a System.Collections.Generic.List<RawFrameData>, then sorting that list in ascending order by the frame index.

I then created three classes: a MotionFrame class, a MotionAction (abstract) class, and a MotionBoneRepositionAction class which inherits from MotionAction.

MotionFrame has a frame index and collection of MotionActions (so that other actions, such as texture changes, can be recorded on the keyframe as well, though these aren't supported by the VMD file format and will require a new Concertroid-specific file format to store them). The MotionBoneRepositionAction represents a bone position/rotation change, and stores all the data that was originally present in the VMD file.

A quick note: the model and bone names between the PMD models are bound to be different, and the model and bone names in the model for the single-model MikuMikuDance V1.30 are hardcoded, so if I develop a converter, it will have to feature some way of allowing the user to map old VMD bone names to new VMD bones and vice versa. Also, supplying an XML configuration file with the bone mappings already laid out for some of the more common models (hanaminasho, kio, animasa, etc.) would probably not be hard to do, assuming I can find the time to work on them. This would also allow you to convert VMD motion data between models that have different bone names...

Anyway, no screenshot for now because there really isn't anything to show. Once I develop the user interface for the converter, I'll post that. But since I've completed VMD support (I checked by converting World is Mine from V7.39 to V1.30 and it played perfectly!) I am not going to do much more with it at this moment.

Right now, my focus is on getting my renderer to animate with the given animations and/or pose files. So until next time, thanks for reading!

Ren'py Data Manager

It's a small utility that allows you to back up your save data for Ren'py-based games with ease. Currently only works with Katawa Shoujo, since that's the visual novel I've been playing at the moment ;p But as I get more involved with other VN's and learn how they structure their save files, perhaps I will add support for them as well.

It's really great if you like to play on multiple computers but hate having to restart the game from the beginning. It also features the ability to backup the persistent data (like which extras you've unlocked).

Screenshot:

Download:

• Binaries
• Source Code

Note: Right now the binaries have only been tested on Windows. My Linux system is down at the moment so I have not had the time to test on Linux; however the software is written in C#, which is cross-platform and can be compiled under Linux with mono. The data path is found based on the Windows version of Ren'py though! The data path may be different on a linux system; since I haven't tested it, I don't know what it's supposed to look like. A simple switch(Environment.OSVersion.Platform) should take care of these different cases though.

screenshots of what I have so far!

No animation just yet. Still trying to figure out the bone positioning and mapping the bone movements to the vertices of the model, with some consultation from my buddy over at AniMiku, who is undertaking a project quite similar to mine, except his is done in DirectX, and actually works at the moment...

I'm not content to just re-build MikuMikuDance in OpenGL instead of DirectX, though. Here's a trio of of screenshots that showcase some of the rather interesting new features you will find in the Concertroid! animation system:

Nicer rendering and animated textures: You won't see this in the preview, because there are no animations, but if you look closely at the skirt and armband textures between this screenshot and the following screenshot, you'll notice that they're different - changing every frame as the software is doing live rendering.

Lights-off mode for added effect: This feature was introduced in the 2011 Sapporo VOCALOID concert done by 5pb. and Marza Animation Planet, although they made a few mistakes. The lighting actually (in my opinion) got worse in the 2012 concert, but regardless of that, their biggest mistake was that they did not use it enough. The first few songs featured lights-off mode, and everything else they just lazily faded out. Since Concertroid! is a live rendering system, there will be no need to worry about that. If there is a delay specified within a certain threshold between two songs in the set list, the lights will go off and the model will still appear to be on the stage.

Bone view: This is only a feature for me to see the bones as I am developing the animation system, but it is a feature I will keep in Caltron (the underlying .NET rendering library I am developing alongside Concertroid!) in case other developers might find use for it.

I hope you've enjoyed this latest update, look forward to more coming in the next few months (hopefully, if I can get these features all sorted out!)

FINALLY...... you'll never believe this

TL;DR: I fixed the problem, here's the result. For those who want to know the dirty details... I was playing around with Caltron, the rendering engine for PolyMo Live! (now Concertroid!) and I started noticing a peculiar bug in the method that applies the textures. Colors in normal GDI are encapsulated by System.Drawing.Color in the .NET framework, a structure I use to store color values in non-Caltron projects (like Universal Editor). These Colors represent color values using four Int32s (something I've never understood, since colors can really only be practically represented in ranges from 0-255). Whether they're four Int32s or four Bytes, their practical range is still only 0-255. Well, OpenGL expects color values to be formatted as percentages, something I knew full well when I started getting into it. However, as I soon learned, I was forgetting a crucial part to the texture applicator. The RGB color values were not getting divided by 255. So, I just added the necessary division, and voilà! The entire thing went black. See, I had forgotten ANOTHER crucial part to the renderer. I had forgotten to flip the light switch. Yes, the light had been configured with the correct color values and position and whatnot, but I had forgotten to glEnable() the light. Anyway, now that I fixed both of the problems (and found an interesting phenomenon where the light position wasn't completely correct and was actually illuminating INSIDE Miku instead of outside her), I feel it's time to update the blog. So enjoy the latest picture! I should have a test program (and complete source code) released soon, but I found another bug where the software will run on my machine but no one else's. I think it's due to the universal-editor library doing something it shouldn't be doing (namely, attempting to read/write from a read/write-protected location)... so I should have that fixed in no time.

TGA image loader for universal-editor

Believe it or not, those last screenshots showing polymolive displaying (somewhat flawed) textures on the model were not in the de facto TGA file format (TrueVision "Targa"), they were in Windows Bitmap (BMP) format. I had been converting all the textures to BMP format because it was easier to load the BMP files using the .NET System.Drawing API, which (being based on Windows' own GDI system) does not support more esoteric file formats like TGA. Fortunately, now TGA textures load PERFECTLY... though whether they'll display correctly on the model is another story, but the below screenshot proves that the textures load just fine when displayed in a System.Windows.Forms.PictureBox - so any errors with the model textures is an OpenGL issue and NOT a universal-editor issue!!!

universal-editor and polymolive update...

So I finally got around to doing some decent improvements to polymolive... all thanks to frostworx, whose free-software (GPLv3) libmmd library and dunan program helped me to better understand the PMD model file format and how to go about rendering the model (and textures) using OpenGL.

I've improved the implementation of the PMDDataFormat in universal-editor, correcting some minor model flag bugs that caused the DataFormat loader to not load textures properly (so no matter what I did on the rendering side, I wouldn't see the textures because they never got loaded!)

I've also followed the code in dunan/libmmd to render the PMD files, but as I'm translating the code from C/C++ to C#, I might have missed a few important things (like the correct way to P/Invoke the OpenGL library...) I've attached a screenshot of what I have so far.

The first time I implemented texture processing:

The improvements:

As you can see, the "improvements" are not much; the only good thing is that now you can clearly see she's wearing some clothing, lol ^^;;

I still have to figure out why most of the parts are drawing white instead of skin-tone, and why the entire model seems to be too *light*...

if anyone has experience with OpenGL and wants to provide some assistance, please feel free to leave a comment ... much appreciated ^_^