MV3D Development Blog

My bluetooth adapter came in today, so I’ve got lots to say now that I’ve actually used the wiimote. My original plan to go from wiimote to Python was to use GlovePIE to redirect the controls to PPJoy (a joystick emulator), and then just read the virtual joystick using Ogre’s input system or pygame.

Getting the wiimote to talk to my computer was a piece of cake. Installed the bluetooth adapter, paired it with the wiimote, opened GlovePIE and made a simple script that turned on rumble whenever I hit the B button. No problems there. I also got it to work as a mouse pointer by turning on two of the 3 LEDs in my IR beacon. The next challenge was getting data into Python. There are a few libs that “support” the wiimote in Python, but as far as I can tell, none of them support nearly as many features as GlovePIE. So, I installed PPJoy but there was no joy to be had there. It doesn’t support XP x64. Suck.

Now what? Remember I mentioned the possibility of letting MV3D run some network protocol that would send user input data? Well, GlovePIE just happens to support the OSC (Open Sound Control) Protocol. There was a Python implementation, but it was not async. There seemed to be a Twisted implementation out there, but it looked to be part of a bigger app. So I wrote my own Twisted OSC client and server. Yay for Twisted making things easy for me. If anyone wants the code, just ask. It only supports the basics of what I needed to talk back and forth with GlovePIE. Anyway, it works, and I made a Python app that did the same as my initial GlovePIE script (turning on rumble when you hit a button). Now I have access to the complete wiimote functionality in Python. Yay!

So, next up is to get it working in a Python Ogre + ODE app so that I can play with some virtual cubes and spheres and stuff. I have some interesting ideas for combining the IR tracking and the accelerometers so that I can maybe have a few strategically placed IR LEDs that would allow me to point the wiimote in pretty much any direction and have it either know its position, or able to estimate it fairly well. However, I’ve bought all the IR LEDs at the local Radio Shacks, and I don’t think they plan on restocking them, so I may have to order some online (which would be cheaper anyway).

Phew! I think I finally have persistence worked out in MV3D. I’m quite happy with it. I went back to my datastore method (yes, I saw that cringe), but I feel like I’ve made it quite a bit better. One of the reasons I couldn’t say no to it is that it’s lightning fast. All the other methods I’ve tried (all of which involved a database of some sort) don’t even compare in speed except for Axiom which is actually faster than datastore if using a transaction. One of the major issues with it before was that you never knew what you were saving since it was basically a fancy layer on top of pickle. Now, however, it only stores what you want to store. It also supports upgrading and downgrading stored objects on the fly (hah the original C++ MV3D persistence mechanism did this too). It allows you to do queries (no joins yet) extremely fast, and its indexes aren’t even optimized. Although, I will say, I haven’t tested it with a mega huge database / index yet. Maybe I’ll do that before moving on.

Every service that needs it has its own store right now. Most of them just save the objects directly to disk when they’re changed. However, for the simulation service (a.k.a destroyer of persistence mechanisms), it stores to memory and then writes it to disk in the background. One problem with the other persistence mechanisms I’ve used was that for the sim service, the data saved to disk needs to be a snapshot in time of all the objects the server is simulating. The other methods I’ve used would take 20 seconds or so to save a couple of hundred objects. So, I’d have to do it asynchronously and then the first object’s position it saved was 20 seconds behind the last one. What I do now is save all the objects to memory synchronously and then save that to disk. It does get a little chunky when there’s 2000 objects on the server, but there’s a bunch of optimizations I can make including storing objects in batches based on the area they’re in. It takes around 1 second to store 2000 objects and about 15 seconds to store that data to disk.

One thing I’m noticing is that the new data store is very good to my data. The old version would lose your data if you stopped the program at the wrong time. This one keeps itself up to date, and the store that the sim server uses keeps backups (since it uses a monolithic file).

In any case, this closes the book on persistence finally! I’m very relieved. For a while, I was starting to think persisting a very open ended simulation wasn’t possible. I’m happy to say that it is. This is one big step towards a rumor I’ve been hearing around that an open source MV3D release would be coming up. There are still some other things I feel need to be done, such as bringing back the grass and trees, fixing bugs, documentation, and finally, figuring out some business related things.

Me and my obsessions, though. I’ve been completely obsessed with virtual reality lately. I don’t know why, either. It’s definitely related to MV3D since MV3D is a virtual world simulator, and it started with the videos from this guy. Anyway, yes, it’s pretty silly, but I still think it’s cool. So, I made my IR webcam 6dof head tracker, an extra 6dof IR tracking beacon for the wiimote I just bought, and I would have made a couple more tracking beacons if Radio Shack had bothered to label their LEDs with what they wanted for current / voltage (oops ). And yes, the normal wiimote sensor bar isn’t 6dof, it’s only 4 (x,y,z, roll). Added to the accelerometers in there, you get 5dof. I think you still can’t measure yaw, but my bluetooth adapter doesn’t come in until tomorrow, so I can’t say for sure. Basically, the beacon I made is a triangle instead of a bar. Using Alter’s algorithm, I can figure out the position and rotation of the beacon just like the head tracking.

The best part was going into Game Stop to buy the wiimote. First off, the cashier was like 12, and the manager couldn’t have been more than 16. hah. But then they try to sell me on a Wii game when I said I wanted the remote. I told them I didn’t have a Wii. This confused them greatly until I explained I was going to use the wiimote on my PC. And that just confused them more. Then they tried to sell me a sensor bar, to which I of course replied that I made one myself that was more accurate. Seriously, $20 for a few IR Leds in a box? Even at Radio Shack’s insane $2/LED price, that’s crazy. Anyway, so that apparently impressed them somewhat, but didn’t stop them from trying to sell me some random PC game.

In any case, now I need to make MV3D support alternate input methods. I’m considering writing a simple udp client/server (of which the client could live in MV3D’s client) for getting the data in there. That is unless twisted has a nonblocking USB Webcam API (joking). Basically, a secondary app will do the 3d positioning for the head tracking (including getting images from the webcam) and also for the wiimote. All that’s left is to convince someone to buy me this or this. Did I mention that I’ve been obsessed with VR? I don’t really play computer games, so it’s not like it’ll “make my game better” in a flight sim or the latest FPS. I just want the set up for MV3D, and I know I’m being silly because MV3D is pretty boring right now.

All silliness aside, one real use I can see for the wiimote and such is that I should be able to create some fairly kickass content creation tools. I can’t tell you how many times when building MV3D’s world editing tools that I’ve been very frustrated by the lack of a Z axis on the mouse (or by it being a crappy scroll wheel). It would be very nice if I could place objects in the world with the wiimote, and especially nice if I could get a little force feedback for when the object you were manipulating touched something. That would make it easier to line things up. This is pretty much the only productive use I can think of for the wiimote and head tracking, but it’s a good one since now that persisting is done, I can actually start building a world or two. Some fixing of world editing tools required.

One fun non productive use I could make would be to allow sending the position of your “hand” back to the server and then making it a physical extension of your PC’s body so that you could punch things or grab them just like that really crappy (but technologically advanced) game, Trespasser. Come on, you’ve got to admit the best part of that game was that your health meter was a tatoo on the main character’s boobs.

I now have 3d head tracking working in Python-Ogre. It is very cool, albeit a little jittery due to the graininess of the webcam images I think. I ended up finding an implementation of Alter’s algorithm for 3d pose estimation along with POSIT. They were in Pascal of all languages. I didn’t think people still used that one– I certainly haven’t in 15 years maybe. Alter’s was easier to use and seems to give pretty good results. I get about 30 fps with Python doing the image processing (identification of where the IR LEDs are on the image) and 3d pose determination.

The effect is really nice. I can even spread it out over two of my 3 monitors. The third is unfortunately run by a separate graphics card, so Ogre won’t render to both at the same time. Maybe some hacking would fix it, but in the other room is my video projector if I want to get crazy..

I’m debating on using the second camera to track a stick of some sort. I have a very amusing magic wand from my LARP days that is just begging to become an input device. That would be cool because I could add physics into the demo and knock things around with the wand.

A cool other use I found for this setup is never having to lose my mouse again. I have three screens on my main system, two on my old computer, and one on my laptop. All of which are connected by synergy. So, I find myself losing my mouse pointer fairly often. While playing with some open source head tracking software, I had it controlling the mouse and found that the mouse was always on the monitor I was looking at. Speaking of that tracking software, even though the result of my tracking is waaay more jittery, it felt a lot more realistic than the other one.

I should really get back to MV3D though, but let me tell you, the ticket for adding mouse-look is getting upped in priority.

I finished up integrating Axiom into MV3D and had most of it actually working. Fitting it in was pretty hard, and in the end, it turns out it actually won’t work for the main simulation part of things. It’d be fine for accounts, realms, directories, and asset descriptions– all things that are fairly static. In any case, I’m taking a break to decide how to proceed.

Instead, I’ve been working on something all together different. There have been some videos going around on how to use the wiimote for various things like head tracking, a virtual whiteboard, etc. I’d been sort of thinking of making a wiimote and writing some software to do the tracking, and then saw this. It is in Python, and it was easy for me to get working with my webcam and stuff. But looking at the code, it needed some help, and only single point tracking was working with a reasonable (>4fps) framerate. No problem. I started over on the tracking code and have multipoint 2d tracking working at about 50fps (faster than my webcam can dish out frames). I added dual webcams (crappy, but who cares for this use) from radioshack for $15, along with an assortment of IR LEDs and a valiant floppy disk that gave its life to become a !IR filter. So far, I’ve only gotten two point tracking (like the wiimote’s sensor bar), but 3 point is just a little bit of trig away.
Anyway, I have no idea what I’d ever use this for, but it’s fun to play around with– especially hooking it up to Ogre for 3D tracking.

MV3D is getting a little big. It’s about 65kloc now in 230 files, though I suppose some of that is cruft that I’ll be pruning sooner or later. There’s over 300 unit tests, but to have good coverage, it probably needs another 300.

I haven’t updated in a while, mostly because there hasn’t been anything interesting to update about. I’m still working with Axiom. It’s not going badly, but there’s a lot of work to do. I’m also doing a lot of refactoring and adding unit tests as I go along, so that’s part of the reason it is taking so long. I’ve finished all the server plugins except the simulation one. So, right now, I’m going through all the various objects and areas and making them work with Axiom.

After 3 or 4 failed attempts at integrating Axiom into MV3D, I’ve finally got it working in a pretty good way I think. The only real issue I have currently is that my Items get pretty messy. As far as I can tell, if a parent class creates a member variable, in the child class (which is also a subclass of Item), you need to re-define that member variable as an axiom.attribute. This is a little annoying, because you’d expect to be able to define those member variables as axiom.attributes in the parent classes, but Axiom doesn’t like that. I found a way to hack it if you aren’t planning on persisting that variable, but it’s so messy that I prefer just listing out all the parent classes’ member variables in each child class. I’ve got the Account Service and Asset Service transformed to use Axiom (including all the types of Assets and AssetGroup). Each class has about 30 extra lines of defining parent member variables, but as far as I can tell, that’s the only way to do it.

Overall, I’m happy with the results, though. Next on the list is probably Directory Service, and then Realm Service. Realm Service will be fairly interesting because that’s where I’ll start to see physics stuff that needs to be initialized on load. The most fun will be with Simulation Service because not only is there physics stuff there, but the physics stuff can’t happen until the required Realm is loaded and its physics initialized.

I’m trying to decide if it’s worth it to partition up items in the simulation service. That way, you could have multiple stores and maybe use a binary tree based on the item ID to determine what store it goes in. Actually, directory service could really use this since it holds a listing of ALL realms / asset groups. Or maybe, the partitioning should be on which directory service you get your info from. Will have to look into that.

But first, a bit of coolness.. My trac server is misbehaving, so I just looked at the server it runs on to see why. While looking, I noticed that an MV3D server was running on it (it’s the dev mv3d server), and after logging in, it seems it’s been running for 112 days. That’s just under the 133 days since the machine was last rebooted (probably because of the power outage that was longer than the run time on my UPS). Anyway, pretty cool. Now that I think of it, it’s not like it’s just been sitting there unused. For quite some time, I was connecting to it to test the performance of the client. It isn’t even barely compatible with the client now though because I reorganized SVN today… A lot. However, I just connected to it from my old desktop which has a very old version of MV3D running on it. Yay for things that keep running without crashing. It doesn’t surprise me that it’s still up and running, just mostly makes me happy to know that MV3D’s server is that stable.

In any case, I finished the refactoring of objects to use bodies. I didn’t do the beach ball, but it’s like 20 lines of code (and probably doesn’t deserve to be its own object type even), so I’ll do it some other time. That’s one ticket down (if trac was working).

Then I took some time to work cleaning up the SVN repository. Originally, there wasn’t a trunk, it was just mv3d, branches, and tags. Now there is a trunk, and mv3d is inside the trunk. The reason this is important is because this way, if some other package has a server module, it won’t conflict with MV3D. I also renamed all the top level directories to use lowercase and most of the second level ones as well. There’s still some more SVN moving around to do since I think the util directory is a little vague and could be better named or split up or something. Currently, it has everything that isn’t specific to either the server or the client. I made the choice early on to separate client and server code so that the client can ship without any of the server code, and the server can run without the client code. However, the util module is the common ground between them.

I’m not sure what’s next. Probably making normal config files for server and client. For the client, I’ve been thinking that adding an auto-login/character picker option to the config file would save me some clicks when testing. Also moving the Ogre config stuff in there would remove another click.

After that is Axiom integration. If I’m quick about the config file, I may get to start that tonight. So, with that, it’s off to config file land!

I’ve made a lot of progress with the photography website. I figured out how to make an admin interface that is password protected in Nevow using portals (which I have prior experience using in MV3D).

So now, I have a front page of the website that has the javascript slideshow on it, and an admin interface that allows you to modify which images get put in the slideshow and what order they’re in. It is pretty cool and works well though the admin interface is pretty simple. It lets you add photos by entering the url and display order. Then you can select them in a list and move them up/down or delete them.

My ultimate goal here is to allow Corey to upload photos to the app and then use PIL to resize them (and maybe even add a watermark if I get fancy). I’ll make a few sizes, but one will be slideshow sized so that he’ll be able to select any photos from his site to put on the slideshow.

My sister and Corey came by for the holiday, so I got a chance to talk to him more about what he wants out of the website.

Now, though, it’s MV3D time. And time to convert the terrain to use bodies.

I finally got to spend some time yesterday working on the photography website. Admittedly, part of my motivation is that I’m also writing a site in Nevow for work that is due on Monday, so I’m trying to learn it as quick as possible. If anyone has a link to some good / up to date documentation, that would be cool. I’ve mostly had to learn from the source & examples with a fair amount of guessing going on.

I still haven’t really integrated the site with Axiom yet, but at the moment, it does have an index page right now. I was able to find this javascript that does all I want as far as slide shows go. I just need to hook that into Nevow/Axiom so that Corey can choose what images go there.

Something I’m finding confusing is how the tags work in the xml templates. This could be because the only other template engine I’ve ever used was one that I wrote, and it had a whole programming language you could use in the templates. Anyway, for a while, I thought you could only put the nevow: tags in div tags. I finally figured out that it can be any tag.

The other thing that’s confusing me is forms. I’m looking at the examples that use formless, and I pretty much don’t understand how they could actually work. So, that probably means copying them and messing with them until they break and figuring out how they work that way. I’ve also never used anything to create and parse web forms other than the library I wrote for it.

Anyway, today is housework, building a computer, and hopefully finding time for MV3D. No pretty screenshots. I got bipeds working again, though there is one little issue, but I think that’s more related to how bodies work than anything. I’ve moved on to moving the water object over. That’s also a little bit tricky since it was probably the only object that still talked directly to Ogre. It’ll still have to do that to an extent because it uses render to texture, and I haven’t yet thought of a good way to wrap that in a non-renderer specific way. Next is wrapping up the object refactoring with terrains. I’m hoping I can do some huge cleanup there since they are (I think) one of the things that cause the client to freeze while it is logging in to the server. I bounced the mesh generation to its own thread, but that didn’t seem to help, so either the terrain is bombing out PB when it gets transferred because of the height data (I moved to a array(”f”).tostring() hoping to solve that), or I don’t know what the issue is. Anyway, hopefully I’ll work on that today. Then there’s actually one more object to change to use bodies, and that’s the beach ball. The beach ball should be more fun now that I added a “kick” command. It should also be incredibly simple to convert since it’s just the same as the box except the collider and mesh.

So, my initial new style object using a body is finished. The server side is 80 lines of non-shared code. The client side is 0. Since it’s just a physical object that has no special other qualities, all the client side code is shared. In fact, I suspect most objects will share the client side code. The only differences will be things that have more complex physics like bipeds or cars. The reason for this is that in order to make things move smoothly on the client, I need to mirror the physics there.

Speaking of bipeds.. They are pretty hard to simulate in physics engines. I’ve probably talked about it previously here, but I do it by creating a capsule (pill shaped object) for the body that is attached to a non-physical object for the head. Every update, the capsule is set to stand on end. At this point, you could walk around– kinda. However, you’d basically be dragging your ass along the floor. Simulating feet in a realistic way is very complicated, and I feel is getting way too crazy for a MMORPG. Instead, I cheat. I cast a ray down from the bottom of the capsule and check where it hits something. If it hits something in range of the length of the character’s feet, I push up on the capsule. This way, it floats in the air. When you encounter stairs, as long as they are below the bottom of the capsule, the player will appear to walk up them. Otherwise, they are “too high” and it will just bump into them. Anyway, this is a fairly common approach and works well. It’s when you get into simulating virtual knees that bend when you land hard that gets tricky. Also, if the player is standing on something that is moving, he should move with it. I had all but the last part working well before, but copy/pasting it and then doing a little refactoring seems to have broken it. The specific problem now is that the ray cast results are used to determine if the player is on the ground, however, it keeps bobbing up too high to register the ray cast and then falling back down. So, hopefully I can come up with a good solution to this. I also need to add the part about moving the player if the object he’s standing on moves.

Now, those aren’t really the issues I’m talking about. Here they are:

The first one is disturbing. I have no idea what happened. All of a sudden, there was an ogre head on the horizon. I turned around to get a closer look and it was gone. The second one is just confusing. I re-built the female model, but now, the torso is facing the wrong way.
Speaking of rebuilding models. I’ve a) gotten very good at applying skeletons to models in 3ds max, and b) FINALLY FINALLY found a 3DS Max->Ogre exporter that works. Ok, so there’s another one that works, but it takes a few days to get a model right. This one, it’s right on the first try. With the other one, you’ll get a properly exported mesh, but when you play an animation, it distorts the heck out of it because the bones are in completely the wrong position. Anyway, I found some simple free 3d models out there and was able to properly export one of them:

Just got to get the biped working again, change the terrain and water objects to use bodies, and then, I think it’s on to Axiom.