Renegging

While I said in my last post that I wouldn't be updating this blog as frequently any longer, it was in the mindset that it would be because I wouldn't be encountering any major breakthroughs or code epiphanies. Instead, the reason for the lack of updates has been sheer lack of work.

Anyone who knows me can guess the culprit for this procrastination. Yes, it's Minecraft. I've been working on a fairly epic railway station hub that serves as a crossover point for four separate rail lines that each traverse the world in a single cardinal direction. But, last night, when the update to 1.2 hit the craftiverse, our SMP server was not yet updated, preventing any of us from playing.

So I worked on Rustbot. And then after an hour I stopped and played Codblops. But the important thing to note is that during that hour I was able to test a theory about a particular bug, and I was right.

I've been working on object constraints (i.e. linking of two objects together) and had been encountering a problem wherein a collision would be detected between the object being added to the scene and an already-existing object. When the collision is detected, I tell the engine to add a ball socket constraint between the two at the point of collision. What happened subsequently is that the two objects flapped together tightly and began to vibrate uncontrollably as if by some epileptic fit.

It then occurred to me that the cause could be as simple as the objects are still colliding with each other when the constraint is added. That is to say that one object is still physically penetrating the other. So the physics simulation is constantly trying to move them apart but cannot due to the imposed constraint. Well, I decided to test it by saving the contact point info when a collision is detected and then allow the step simulation to finish. After the physics engine has managed to push the two objects apart, as it would normally, I impose the constraint.

And voilà. It worked.

I am now left with one problem concerning the constraints; upon collision, momentum is still transferred to each object, causing them to flap around once the constraint is added. Obviously, I don't want this to occur. I want the two objects to simply be connected and behave as they were previous to the detected collision / constraint addition.

So I've thought of a way to do this. I will have to save each object's transform after the collision is detected but before the world is stepped. Then, after the joint is added, overwrite each object's transform with the saved ones so that they don't fly haphazardly everywhere.

I will be testing this tonight.

In addition, I've been struggling with how to implement player control in terms of interaction with the physical world. Obviously I want the player to have mass and shape so that a bump into an object causes the object to move, and so that the player will fall when not on solid ground. This is easily implemented by just having a rigid body in the world and attaching the camera to it instead of a renderable mesh.

What this will do, unfortunately, is interact just like any other object. That is to say that it will bounce off other objects, slide down slopes, roll and topple over. That is all decidedly bad. What I can do in this case is to constrain the object's linear and angular freedom. I can use setLinearFactor(0,1,0); so that the object is only allowed to move in the y direction (thanks to gravity) and not slide around. I can also use setAngularFactor to all zeroes so that it isn't allowed to rotate at all.

The only problem with that, then is that the camera will still bounce off the ground, which I don't want. Indeed there is more to consider when trying to climb slopes. This will be more tricky than it appears at first glance...