Dimajix Developer Blog

Today I stumbled over a new-to-me project on OpenGL.org: An OpenGL canvas plugin for Mozilla Firefox! The plugin called Canvas 3D only works in the new Firefix 3 line and provides an OpenGL context to Javascript.

In my eyes this opens the doors to many new exciting Web applications (if Javascript turns out to be fast enough), ranging from simple Model Viewers to some advanced online-editors. I wish I could find some time to explore some of the possibilities!

C#, Java and C++ are out. The upcoming star is called LOLCODE. LOLCODE is a new programming language that immitates the natural language of the leet coders.





HAI
CAN HAS STDIO?
PLZ OPEN FILE "LOLCATS.TXT"?
   AWSUM THX
     VISIBLE FILE
   O NOES
     INVISIBLE "ERROR!"
KTHXBYE

Obviously this new programming language will start a new era in software development!

After I have been working with ODE in order to get an assembly simulation running, I began to dislike ODE for several reasons. The topmost reason is that ODE does not seem to handle large scales very well (even in the handbook it is noted that best is to scale everything between 0.1 and 10.0 - this was not a real option in my case).

So I was looking at different packages, but even the two big ones Havok and Agiea/Physx do not handle arbitrary triangle meshes very well (at least that is what I understand after reading their documentation) as collision geometry.

Fortunately finally I found Vortex, which is a high-end physics package geared towards simulation. And I have to say that so far I am really impressed with both speed and accuracy! Vortex is able to handle collisions between arbitrary meshes very well and fast. The collision response is quite good, if I tune the parameters (mass, forces, joints), I get almost not penetration between complex triangle objects - this is quite a difficult task.

Plus Vortex offers a lot more parameters to tune than other packages in order to get realistic and stable simulations. So if you are looking for most realistic results with complex shapes, Vortex seems to me the only way to go.

After I started the integration of ODE into the immersive VR project, I stumbeled over a lot of difficulties, with some of them being still not properly solved:

• Collisions between arbitrary triangle meshes is a complex thing. ODE needs as much information as possible for correct collision response. This include the contact point and normal (both are rather easy to get) and the penetration depth. The later is not trivially extracted from a collision, moreover it even is not simple to give a correct definition in the case of non-convex geometry. I had to work around this problem by approximation the penetration depth on a triangle-by-triangle basis, but my approximation still can return much too big values, so I finally had to clamp the result.


• The connection of the virtual object and the tracked hand of the user is now realized by a fixed joint between two ODE bodies (one body for the hand ("user body") and one body for the object ("object body"). Out naive approach simply repositions the user controlled body in each frame and hopes that ODE will try to move the connected object body to the user body while trying to obey to collisions. This went well in some sense, but as soon as there are some collisions, the distance between both objects has been increased and remained even after the object has been moved out of collision again. Debugging the code showed that the user body has accumulated insane velocities in order to resolve the fixed joint constraint, and these velocities haven't been reset after collision. So I had to insert a linear and an angular motor with target speed of zero in order to slow down the objects. Still this is not an ideal solution, it would be much better to use motors in the first place to control the virtual object.


• ODE seems to be very sensitive to scaling. The ODE manual states that best results are achieved if all values are in the range 0.1 to 10.0. But we have models in milimeters (cars) and models with a meter scale (airplanes). ODE seems to be especially sensitive to different masses, it turned out that a proportional increase of all masses resulted in ignorance of all collisions.

Still there are a lot of open topics, and I was only able to achieve some sliding (the user moves a virtual object, which obeys to collisions with a static environment) in a artificial toy environment. Maybe we will try a different physics library, but my guess is that the biggest problem is the lack of proper penetration depth information.

Currently I have to develop a robust method for sliding simulation in a immersive VR environment. This means that the user in a CAVE should be able to move objects around, but these movements should be resitricted by collisions with a static environment. Unsurprisingly this task turns out to be non-trivial. We chose to integrate ODE as a physics simulation backend combined with our own collision engine originally developed by Gabriel Zachman.

There are two obvious problems:

• The virtual body moved by the user eventually has to be moved by ODE. This means that I had to extract the forces needed to move the object as desired by the user and pass them to the physics engine. This has been rather easy once I understood what the words torque and intertia tensor mean (both are needed for rotational movements).


• The more complex problem is the integration of the collision engine. The integration itself was straight forward, but the real problem is, that as soon as a collision is detected, the simulation gets out of control. The reason is that what we really would need is a penetration depth or we have to try to approximate the exct time of the first collision between two bodies. As our collision engine does not offer the penetration depth, I have to go down the second road and approximate the time of collision by progressively subdividing timesteps in case of a collision.

Interestingly I found out that commercial physics packages seem to employ much more advanced collision algorithms which can calculate the penetration depth or work in a continious mode and thus calculate the exact time of the first collision. Plus many games use simplified collision geometry and special bodies (spheres, cylinders, boxes) which make such calculations much more easy, while we have to cope with arbitrary high-resolution triangle meshes.

While looking for solutions on the net, I found two good PhD thesises on physics simulations:

• Stable, Robust, and Versatile Multibody Dynamics Animation by Kenny Erleben from March 2005


• Impulsbasierte Dynamiksimulation von Mehrkörpersystemen in der virtuellen Realität by Jan Bender from January 2007

Writing a interpreter for a custom scripting language always seems to be more complex than writing a small bytecode compiler and bytecode interpreter. At a first glance, writing a direct interpreter might be easier, but if the scripting language contains flow control (like loops, if/else statements and similar constructs involving jumps), this turns out to be false. The primary problem lies in the fact that one needs to duplicate large parts of the parser - simply for skipping over the parts of a script that are not executed (like with a conditional if-block whose conditioon turns out to be false at runtime).

Because of this insight, I began to concentrate on writing an easy-to-implement bytecode compiler that would transform a text-based script into a more machine-friendly representation. A positive side-effect of bytecode is that simple fact that it is much faster to execute than the original textual representation. The downside of this approach is the fact that it involves writing a compiler - something that sounds to be a complex and difficult task.

But after analysing the process of parsing a script, I came to the conclusion that such a compiler and its corresponding bytecode interpreter ("virtual machine") would be rather straight-forward and easy to implement, if the underlying model of the virtual machine is chosen carefully. In my opinion the best machine model (in terms of simplicity to implement a compiler and interpreter) it a purely stack-based RPN (Reverse Polish notation) machine. And such a model not only is easy to implement, but it also easy to extract the original syntax tree from the bytecode, which in turn allows further optimisation techniques as a postprocessing step (it even wouldn't be to hard to turn bytecode into native assembler).

Continue reading "Easy Bytecode"