MV3D Development Blog

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.

I took a break from bodies to add some eye candy. Bodies are 99% working. They seem to have issues when they are in an octree node that gets split though. Have to check that out. Also have to make a method to limit how fast they update based on something or other.

First up, a lot of objects that use bodies. 2000 to be exact.
Pretty reflections at night	Trees, grass, and water. Not too bad for FPS, but not very good either.
Walking through the forest.	Trees and water at sunset
A whole lotta trees	Too many?

So… This stuff isn’t too impressive because I basically shoe-horned in this Python-Ogre demo. And for some reason, you get pretty clouds in the demo, but I don’t get them. Anyway, this isn’t done in a client server way at all. It’s just attached to the client side of the terrains. Making it into something that comes from the server probably won’t be incredibly hard. The trees will also need integration with physics since you can walk through them right now. There are other optimizations I can do I’m sure to get things going faster– especially tweaking the settings of the tree plugin.

Right now, I need to get back to the server side of things and make bodies work better. Something I really need is an easy way to write unit tests that involve a client and server. I spent a lot of time going back and forth with Bodies making them work when transferred from a server. I more or less had this working before, but it was pretty kludgey (Ogre would get initialized and everything). It would have been nice to be able to write unit tests for the issues that came up.

Anyway, better get back to doing some non eye-candy stuff.

So, I almost have my example Box object that uses bodies going. It works ok, but it sends updates way too often, client side Physics may be not working (hard to tell since it sends updates so often ), and you don’t see it in its initial position until it moves. But I took a short break to give you the following pretty picture:

I should have some trees and grass to go along with that soon.

Also, I forget if I mentioned, but I saw that the Python-Ogre guys made wrappers for libnoise. This is very cool because even though MV3D already has a pretty good noise generator, this one is in C++ and therefore will be quite a bit faster. I suspect the new sky plugin uses it for real time clouds (which you can’t see in the screenshot because they are broken for some reason).