MV3D Development Blog

So first, I took a look at some more Nevow stuff, and it seems like it should be pretty easy to work with. I didn’t expect otherwise, but you never know.

I just finished writing up a basic data model for the photography website. It was pretty easy. In order to test it, I created some unit tests that store and retrieve things. I figured out how to do various types of relations such as one to many, and many to many. All in all, it’s pretty straight forward and should do the job very well. The next step here is to integrate it with Nevow and then make an admin interface to create data.

The big question is: can I use it on MV3D? I think for 90% of the data, it would be fine. The other 10% is the stuff that changes 20x per second like object position, rotation, and velocities. I have no idea how I’d store that stuff in Axiom as I wouldn’t want to save it to disk so often. Once a minute is probably fine. Maybe there is some sort of parameter I can set for that. I’m definitely open to any ideas here.

As far as other MV3D stuff goes, the new version of Python-Ogre includes a bunch of kick-ass addons such as a really nice dynamic sky, and paged geometry. The paged geometry is what will allow me to have forests with tens of thousands of trees in them (no really, this can display hundreds of thousands of trees on screen without breaking a sweat). There’s also now a kick-ass water texture/shader in the Python-Ogre demos that I can use. Now if I only wrote a nice tree generator that could be used with the paged geometry.

For things that I’ve done, well, I’m creating a base object that uses bodies. It is < 200 lines of code, which is a good sign. I also refactored out a lot of stuff related to object views and figured out how that whole mess will work with bodies and visual objects. Basically, items (objects, areas, realms, etc) in MV3D can be Viewable. Something that is viewable has a sister view class that contains only the attributes that are needed for the client. The reasoning for this is that you don't want the client knowing everything the server knows about an object. That leads to cheating. Right now, viewable objects that don't use bodies update position and rotation of their views all the time. This isn't slow, but it could become so. Instead, with bodies, I've decided that the body level and below is all public data that the client can know about. So, an object and its view share a reference to a body (or more than one). The body can have visual objects attached to it, which become models and such on the client. On the client side, the body updates the position/rotation of its visual objects as needed based on client side physics and updates from the server. It seems to make a lot of sense to me, but we'll see how it works soon enough.

On the subject of portals, it actually looks like I can do some render to texture work in order to support smaller portals visually. Basically, I should be able to create a flat object and render whatever is behind the portal to it. It is theoretically possible to only render to it when it is visible to save some cpu cycles.

The next step here of course is getting a working object using bodies on the server and client. But first, housework.

Edit: Persistence Thoughts
Right now, bodies don’t actually have a member variable called “position” or anything. They just get/set that information directly in the physics engine. Maybe I could define position/rotation/velocities as Axiom attributes and then once a minute start up a coiterator that goes through all the items on the server and calls a method on them that would cause the bodies to do something like self.position = self.odeBody.getPosition(). Does that seem like a reasonable solution? I don’t know Axiom nearly well enough to say if that would be fast and not dumb.