Monday, January 26, 2009

square root estimation fun with javascript

After reading about Fast Inverse Square Root I thought it would be fun to see this iterative estimation process in action:

Wednesday, January 21, 2009

refactoring safety net

I recently started porting and collecting some code for doing various sorts of intersection, or collision, tests in haxe.

At the moment, it is pretty limited with ray/triangle and ray/sphere tests.

The first test I ported was based on based on "Fast, Minimum Storage Ray / Triangle Intersection" by Tomas Möller and Ben Trumbore and ported directly from the copy of the code on here.

The results documented in the paper are pretty impressive and having source code certainly made it an easy win, but some aspects of the code concern me:
  • points are represented as arrays, perhaps not very efficient in haxe
  • the code has multiple returns points, can't be inlined in haxe

I want to refactor the code to be as efficient as possible because this is likely to be the innermost loop of particle simulation routines, etc, but I don't want to break the implementation.

Enter the test case.

My initial testcase generated 1000 random triangles and rays and tested the culling and non-culling version of the algorithm.

All well and good, but not good enuff for refactoring since I need to make sure the same inputs produce the same outputs before and after my changes.

So... I put in some trace commands to produce xml like so:
<hit non_hit="1" cul_hit="1" t="0.5373583852">
<v0 x="0.6581358404" y="0.1374191698" z="0.9648343668" />
<v1 x="0.308879062" y="0.6053369969" z="0.3154988046" />
<v2 x="0.8667143827" y="0.1228679823" z="0.3068826511" />
<src x="0.1215154344" y="0.2182366329" z="0.4350455069" />
<dir x="0.7023522276" y="0.3298090568" z="0.1063413928" />

Now I can verify that the same input produces the same output.

My test looks like this now:
public function testCanned() {  
var count = 0;
var tests =

for ( i in 0 ... 50 ) {
for ( test in tests ) {
verifyTriangle( test );
var stopTime =;
var diff = ( stopTime.getTime() - startTime.getTime() ) / 1000.0;

trace( count + ' tests / ' + diff + 's = ' + ( count / diff ) + ' tests/s' );

After a few test runs, the initial numbers look like:
AppTest.hx:99: 459600 tests / 32s = 14362.5 tests/s
AppTest.hx:99: 459600 tests / 36s = 12766.66667 tests/s
AppTest.hx:99: 459600 tests / 35s = 13131.42857 tests/s
AppTest.hx:99: 459600 tests / 35s = 13131.42857 tests/s
AppTest.hx:99: 459600 tests / 36s = 12766.66667 tests/s

So... it averages out to around 13231.738096 tests/s

My first refactoring was to use a "result" variable and some branching to only have a single return point so I can use the inline function modified:
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s
AppTest.hx:99: 459600 tests / 32s = 14362.5 tests/s
AppTest.hx:99: 459600 tests / 31s = 14825.80645 tests/s

For an average of around: 14733.145160 tests/s

This comes to 14733.145160/13231.738096 = 1.11347013167180814489 , for an 11% speedup just from this trivial change.

From some earlier work, I saw that an optimized point class could be significantly faster than a typedef, some additional tests (unpublished) show that using arrays to represent points was about 4x slower than typedefs!

The next refactoring will be to use this "InlinePoint" class

AppTest.hx:101: 459600 tests / 18s = 25533.33333 tests/s
AppTest.hx:101: 459600 tests / 17s = 27035.29412 tests/s
AppTest.hx:101: 459600 tests / 17s = 27035.29412 tests/s
AppTest.hx:101: 459600 tests / 17s = 27035.29412 tests/s
AppTest.hx:101: 459600 tests / 18s = 25533.33333 tests/s

Average is 26434.509804. 26434.509804/13231.738096 = 1.99781084028493908605.

Damn! Of course it comes at the cost of a new type, but still.

So pretty, happy, but still a little concerned about this:
var edge1 = threePt();
var edge2 = threePt();
var tvec = threePt();
var pvec = threePt();
var qvec = threePt();

That's a lot of memory allocation madness... One optimization I tried was to move the declarations to where they are actually used... not much difference...

What about passing in a workspace? This bumped up to 28725 for an improvement of 8%, but doesn't really seem worth the bother.

So that's the good news... now the bad news...
ERR: AppTest.hx:48(tests.AppTest.randomTriangle) - expected '-0.206685315' but was '0.4077964499'

Happily, it turned out to be a red herring from the refactoring of the test itself:
assertEquals( cul.x, non.y );

should have been (and now is)
assertEquals( cul.x, non.x );


Friday, January 16, 2009

Finding the Twilight Samurai

I woke up this morning thinking of an oddly disturbing movie I saw a couple of years ago.

It's about this this samurai who is living right around the poverty line. A widower, he supports his daughters and elderly mother making extra money building and selling cricket cages to the local villagers.

In Meiji Japan, this sort of activity is borderline illegal due to a the caste system so it's a little sketchy.

Then one day, in the middle of barely being able to keep his family alive the leader of his clan shows up and says: "I need you to go kill this guy."

I googled on: samurai movie cricket cage widower

Which led me to:

Looking at the role of the samurai in a very narrow, mercenary sense, the appeal of risking your life in exchange for a position of authority and respect makes a certain sort of epicurean sense.

Watching this movie, I felt compelled to ask: why is he willing to risk his life and the life of his family for people who have really given him nothing in exchange?

Or course, the answer is honor. In this film, it is a rare commodity with a very odd exchange rate.

Just like in real life.

Tuesday, January 6, 2009

stickman physaxe

So I was reading about physaxe 1.2 and thought it would be fun to have some more stickman action leveraging it.

The demo I throw together is mostly from code ripped off from the original post and little bit of stuff to make the "springs":

Move the mouse around to move gravity and click anywere to add some junk:

Usage is something like this:

var a = body( 50, 40 );
var b = body( 50, 140 );
var j = new DistanceJoint( a, b );

world.addBody( a );
world.addBody( b );
world.addJoint( j );

It is not integrated into the physaxe code right, cuz I had to loop over my joints when I stepped the world.

The interesting piece of the "DistanceJoint" look like this:

public override function preStep( invDt : Float ) {
var currentDistance = dist( b1, b2 );
if ( 0 != currentDistance ) {

var diff = ( currentDistance - this.distance ) / currentDistance;
var xdiff = ( b2.x - b1.x ) * diff;
var ydiff = ( b2.y - b1.y ) * diff;

b1.v.x += xdiff * 0.5;
b2.v.x -= xdiff * 0.5;

b1.v.y += ydiff * 0.5;
b2.v.y -= ydiff * 0.5;

It doesn't take into account the relative mass of the bodies but that should be pretty straight forward.

It should be enough for stickmen, cloth, strings, etc.

If you are interested, you can find the code here.

Friday, January 2, 2009

segmented flowers

So... let me start off a little differently by saying: I'm not really all that thrilled with how this came out.

The basic idea was to model plants, flowers, as vertlet-based segments using distances constraints for each segment. In order to keep the plants upright, I added a new a "height constraint" to keep each vertlet a certain amount above the ground.

Additionally I rooted each plant's base point so it wouldn't wander off.

Next, I added rain by modeling each drop as a vertlet and testing it's previous and current coordinates again each segment (see below)

Here are the results:

You can click to toggle the rain. I think it might be improved using a better design for the plants (eg: that branching tree algorithm).

This partially scratched the itch I had to model dynamic plants, but not quite... Hopefully I'll turn up some more information on how to do properly at some point.

I think angular constraints might work...

Anyway, if you are interested, the code is available for whatever you like.

2d line intersection test

Once upon a time, long, long ago... I wanted to find out where 2 line segments intersected in 2d.

I played with rise over run and all that dumb crap till I finally found somebuddy who had the math-magic I was looking for.

Here it is translated to haxe:

public static function intersectionTime(
line_0_x0:Float, line_0_y0:Float, line_0_x1:Float, line_0_y1:Float
, line_1_x0:Float, line_1_y0:Float, line_1_x1:Float, line_1_y1:Float
) {
var line_0_xdiff = line_0_x1 - line_0_x0;
var line_0_ydiff = line_0_y1 - line_0_y0;

var line_1_xdiff = line_1_x1 - line_1_x0;
var line_1_ydiff = line_1_y1 - line_1_y0;

var line_1_normal_x = line_1_ydiff;
var line_1_normal_y = -line_1_xdiff;
var l2 = (
line_1_normal_x * line_1_normal_x
line_1_normal_y * line_1_normal_y
if ( 0 != l2 ) {
l2 = Math.sqrt( l2 );
line_1_normal_x /= l2;
line_1_normal_y /= l2;

var denominator = (
-line_1_normal_x * line_0_xdiff
-line_1_normal_y * line_0_ydiff

var t = -1.0;
if ( 0 != denominator ) {
var numerator = ( 0
+ line_1_normal_x * ( line_0_x0 - line_1_x0 )
+ line_1_normal_y * ( line_0_y0 - line_1_y0 )
t = numerator / denominator;
return t;

I'm sure you can find some explanation of what it does and why it works, but sometimes... don't you just wanna rip off code?

"So what's the deal?" you ask? Fair enuff. You pass it the end points for two line segments and it returns where along the first segment the intersection would occur (-1 means never, sorry).

If it is between 0 and 1, that means it occurred some where along the first segment.

If you want to see if the intersection (or collision) occurred on both segments, you can then call with the segment orders reversed to see where on the other segment it hit ala:

var t_0 = App.intersectionTime(
line_0_x0, line_0_y0, line_0_x1, line_0_y1
line_1_x0, line_1_y0, line_1_x1, line_1_y1
var t_1 = App.intersectionTime(
line_1_x0, line_1_y0, line_1_x1, line_1_y1
line_0_x0, line_0_y0, line_0_x1, line_0_y1

var hit_on_0 = ( t_0 >= 0 && t_0 <= 1 );
var hit_on_1 = ( t_1 >= 0 && t_1 <= 1 );
var real_hit = hit_on_0 && hit_on_1;

var x = line_0_x0 + ( line_0_x1 - line_0_x0 ) * t_0;
var y = line_0_y0 + ( line_0_y1 - line_0_y0 ) * t_0;

Note if "real_hit" is true then x,y will be the coordinates for the actual intersection, otherwise it is where it would have hit on the first line (line_0).

Here you can see it in action.

Grab the code here and look at


It's not the most optimized way to do things since there is some duplicated computation, but I know you don't wan me to have all the fun!

BTW.... does anyone know when/why these google turkeys stopped allowing the embed tag? Sheesh... Numbskulls! Yes... I am looking it in the mouth...