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!!!