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.