RedPanda Development Blog

Stephanie and I were trying to find ways to export Maya animations into JME (because she made a really awesome waterwheel that MUST be in the game), but encountered many difficulties. For exporting Blender animations to .md5 format, we simply had to download the Doom 3 .md5 exporter…but for Maya it seems that that only works if you are using the Doom 3 game engine, which we are not.

Our second idea was to export animations from Maya into a format that we could then import into Blender, exporting to the game from there. There were a few compatible file formats, but none that would import the model AND its animation.

We also tried downloading something called Muskoka to help us export Maya animations into .md2 files, but never actually got it working.

This is probably a top priority thing, since the whole reason we got Maya in the first place was to make animating easier. You’d think that because it is so widely used, there would be many ways of exporting animations into many different engines, but either that’s not the case or we are missing something. Anyone want to help us to figure out the best way to do this?

Please ignore the many, many emails that may have recently been sent to you.  They were waiting in a queue until Bobby got our RedPanda server to properly send emails.

Stephen and I have designed a basic framework for giving models in our game the ability to act for themselves! This code can be found in the new game.ai package in the repository, and in the spikesAndTests package. If you want to check out an awesome die moving all on its own, run

java -Djava.library.path=../project/lib spikesAndTests.AISpike 3 9999

or with whatever parameters are relevant. (HINT! try rotating the die while it’s moving around.)

What has yet to be done is integrating the BrainManager (don’t laugh!) into our main code base and creating a wonderful user interface for assigning Wills to Brainables.

I’ve implemented the pseudo-drag and quasi-drop mentioned in my last update, and as an added bonus, compensated for parental rotation when moving objects (Julio’s Bounty 1.) Until I can figure out how Quaternions work, it’s implemented manually by taking the parent’s rotation around the y-axis and rotating the delta-translation of the child by the opposite of that amount. (Maybe Quaternion.inverse() will have the same effect?)

The ClickManagers probably need a little refactoring. I’ll see about that this weekend.

I have added a bug tracker to our wonderful set of web applications.

You can find it here.

Create an account for yourself and start adding bugs!

After much frustration, I’ve finally fixed the bug with the cursor color not being updated. (Actually reading the update method helped a great deal.) Reintroducing myself to ClickManager has made me wonder if we’re approaching the translation of Wickets in the right way. We refer to our current system as “drag and drop,” but the fact that the Wicket does not remain under the cursor as long as the mouse button is held down means that we have more of a “cattle prod” interface: if it’s not doing what you want, just poke it in the direction you want it to go. Implementing a true drag and drop is well beyond my knowledge of linear algebra, but I think we could alter our current system to achieve an effect similar to a true drag and drop.

Read the rest of this entry »

I know how much you like ticket trackers, Bobby.  Do you want to set one up on RedPanda?

I fixed issue 2 and issue 4, which I mentioned in my previous post.

Also, I fixed a random bug that made every model into an item after the server was restarted — the opposite of the problem we had with items turning into models.

Issues 1 and 3 still have a Julios bounty on their heads.

Whoever fixes these problems wins a bag of Julio’s. (I’m serious.) None of these are trivial:

1) When you join two objects then rotate the parent, the child becomes impossible to control. When you drag it one way, it moves in another direction. My best guess is that we can fix this by modifying RelationalMovable or Wicket or ClickManager or wherever we implement our drag-and-drop these days. Moving a Wicket should take into account the local translation of its parent.

2) Parent/Child relationships are preserved as long as the server is running. But when you kill the server, problems arrise. I think register recursively needs to be adjusted. And possibly Wicket needs to save its name and its parent’s name; but I think this is probably already the case (because Wicket extends Node, which surely saves its own name.) So this might be as simple as sending the right parent name in the SynchronizeCreateCommonMessage that we create for each Wicket we load. However, if we have to worry about the order that messages are received on the client, then we might have trouble. For example, what if a client gets a message to create a child before it has created the parent? It will try to set the child’s parent to a Wicket that doesn’t exist yet. Should it wait around in its own thread until the parent has been created? We’ll have to see if things start breaking.

3) We can join Wickets, but we can’t unjoin them. This won’t be hard, I think. We can just have a key (like “U”), which loops through all of the selected Wicket’s children and sets their parents to be the sceneNode. But these changes must, of course, be reflected on the Server and other clients. So sending the proper messages is important. It’s possible that you can use existing method in Wicket — setParentWithName(String name) — for changing the parent based on a name string. The only problem is that, at the moment, the sceneNode’s name is null. NOTE: I think I might have left a field in SynchronizeCommonMessage called parentName. Don’t use it. It doesn’t do anything. All name setting is based on using the setId() method in Wicket (to which you pass a SynchronizeMessage’s syncObjectId.)

4) The thing that’s frustrating me most right now is that sometimes (but not all the time), if you log onto the server and create an object, all will SEEM well; but it really isn’t…

The server outputs something like “registering object with id = 2.” But then, whenver you try to move the object you’ve made, the server will continually spit out “Unable to find object 2 on server.” So it seems like it didn’t really register it in the SynchronizationManager.

I have no idea why this happens. But I have one clue: I played around with the call to hasDuplicate() in CommonObjectSynchronizationManager; and when I removed it, the problem (as far as I could tell) disappeared. It was, however, replaced by a problem involving duplicate Wickets appearing in the game — which is the same problem that motivated us to make the hasDuplicate() method in the first place. It keeps duplicate SyncWrappers from getting into the active queue in CommonObjectSynchronizationManager. So maybe it’s being too zealous and keeping SyncWrappers out when it should be letting them in?

This was ridiculously difficult and is probably still broken in many ways.

Here’s the simple explanation of what is supposed to happen:

1) You join two models together (as explained in my previous post.)

2) The parentChanged boolean field is set in the child.

3) OurGraphicalController detects this change in the child and fires off a message that contains the child’s parent’s name — as a string.

4) The server gets this message, finds the child about whom it refers, and changes the child’s parent to the Wicket referenced by the parent name string contained in the message.

5) The server sends the same message out to all clients.  The same parent/child joining occurs.

5) All is well.

Unfortunately, step 4 requires corresponding Wickets on the server and each client to have the same name.  Otherwise, sending the name of a child’s intended new parent will be useless.  So I did a fair amount of work to be certain that Wicket names are synchronized.  They are now named according to the SyncWrapper id that they happen to end up wrapped in.  The problem with this is that the SyncWrapper id always starts out as -1 until it is set (via some back-and-forth message passing.)  So for a short time the Wicket will have a weird name, like “tree.obj#-1.”  But this name is changed fairly quickly.  Hopefully there will never be a time when two Wickets have the same name.  But I am not yet prepared to certify that this is the case until we do further testing.

To make a long story short, when everything goes properly, Wicket joining now works.  In a perfect world, you can join two objects, move them around, log out, come back, and they will still be where you left them.  And they will still be joined.

But the world is not perfect.  I will blog about the current problematic issues momentarily.