Andy Li's Blog

The point cloud calculated from OpenFramework/OpenCV is now able to stream into the haXe rendering program through TCP socket. However, currently the TCP socket used in haXe is in synchronized mode, which is blocking and limit the framerate. That part will be rewritten to use threading later on.

There is some problem with the point cloud too. Seems that the points’ z-value is scaled by a factor. I need to manually scale them to fit the real world and it is causing low accuracy. I’m not sure if that is the problem of OpenCV or not. But I’ll just stay in the current implementation unless I got more info.

The physic simulation is working with jiglibhaxe, so far so good. I’ll post some screen capture later.

The point cloud calculated from OpenFramework/OpenCV is now able to stream into the haXe rendering program through TCP socket. However, currently the TCP socket used in haXe is in synchronized mode, which is blocking and limit the framerate. That part will be rewritten to use threading later on. There is some problem with the point cloud too. Seems that the points' z-value is scaled by a factor. I need to manually scale them to fit the real world and it is causing low accuracy. I'm not sure if that is the problem of OpenCV or not. But I'll just stay in the current implementation unless I got more info. The physic simulation is working with jiglibhaxe, so far so good. I'll post some screen capture later.

I’ve been learning Haxe since the last few months. Beside the reason of many Flash guys moved/moving to Haxe because of better performance of compiled swf, I was tempted to try using its C++ target, which runs even faster(at least in theory, in most parts). Its language feature is also very nice, which is quite similar to AS3 but more powerful in many aspects. Check out its feature page if you want to know more.

And because of I need to write some 3D stuff in a project, I tried finding a Haxe 3D engine  that can compiled to C++, but who knows, there wasn’t one. Actually the 3D engines in Haxe are all quite young. There are 3 I found, all targeting only Flash: Sandy3D, originally written in AS, has switched its trunk to Haxe; Away3D, again originally written in AS, now has a Haxe branch inside its SVN in active development; Haxe3D, developed by Nicolas(the creator of Haxe), written in Haxe from the very beginng, seems to be very light-weight but I can’t found much info about it.

So I decide to work on one of them to enable a Haxe C++ 3D engine. Because Sandy3D should be the most complete and stable one(which actually stopped active development…), I chose it.

In the development of it, some issues are related to nme/neash, which are the re-invented cross-platform Haxe version of the Flash API. With the help from Hugh and Niel, project owner of neash and developer of Sandy3D, most of the problems are solved. However as I can see, re-inventing the Flash API is a hard job as consideration of other target is also needed, eg. JS/Canvas. I really hope Adobe can help this.

Currently some very basic demos of Sandy can be compiled to C++ and it shows that, in OpenGL rendering mode, the performance can goes over 300% of the Flash(Haxe, not AS3) version. However in normal rendering mode, the frame rate may actually be reduced if the window size is large. Anyway, I think the performance is quite depend on hardware/OS, also the 3D scene you’re showing.

Thanks for the Sandy3D team, they added me as a committer in their official Google project. And I have just committed the changes to the trunk There should be a new release soon if everything is fine.

A note to the ones can’t wait for a release:

1.Install hxcpp, nme, neash from haxelib.

2.Replace contents in neash’s neash/display/IBitmapDrawable.hx to a simple “typedef IBitmapDrawable =
nme.display.IBitmapDrawable;”.

3.To make mouse event work, in neash’s neash/Lib.hx, the code:

// Process pending timers …
neash.Timer.CheckTimers();
// Send frame-enter event
var event = new Event( Event.ENTER_FRAME );
mStage.Broadcast(event);

should be moved to the end of the do-while loop, just before the:

mStage.RenderAll();

4.For mouse event in opengl mode to work, additional fix which required a recompile of nme is needed. I haven’t tried
yet. Now just ingore this…

5.You should be able to use Sandy3D in C++ without the above patches for the next release of nme/neash. But for now, please do it.

BTW, I am also porting ported casalib, which I often use in AS3 development, to Haxe, see casahx.

I've been learning Haxe since the last few months. Beside the reason of many Flash guys moved/moving to Haxe because of better performance of compiled swf, I was tempted to try using its C++ target, which runs even faster(at least in theory, in most parts). Its language feature is also very nice, which is quite similar to AS3 but more powerful in many aspects. Check out its feature page if you want to know more. And because of I need to write some 3D stuff in a project, I tried finding a Haxe 3D engine  that can compiled to C++, but who knows, there wasn't one. Actually the 3D engines in Haxe are all quite young. There are 3 I found, all targeting only Flash: Sandy3D, originally written in AS, has switched its trunk to Haxe; Away3D, again originally written in AS, now has a Haxe branch inside its SVN in active development; Haxe3D, developed by Nicolas(the creator of Haxe), written in Haxe from the very beginng, seems to be very light-weight but I can't found much info about it. So I decide to work on one of them to enable a Haxe C++ 3D engine. Because Sandy3D should be the most complete and stable one(which actually stopped active development...), I chose it. In the development of it, some issues are related to nme/neash, which are the re-invented cross-platform Haxe version of the Flash API. With the help from Hugh and Niel, project owner of neash and developer of Sandy3D, most of the problems are solved. However as I can see, re-inventing the Flash API is a hard job as consideration of other target is also needed, eg. JS/Canvas. I really hope Adobe can help this. Currently some very basic demos of Sandy can be compiled to C++ and it shows that, in OpenGL rendering mode, the performance can goes over 300% of the Flash(Haxe, not AS3) version. However in normal rendering mode, the frame rate may actually be reduced if the window size is large. Anyway, I think the performance is quite depend on hardware/OS, also the 3D scene you're showing. Thanks for the Sandy3D team, they added me as a committer in their official Google project. And I have just committed the changes to the trunk :) There should be a new release soon if everything is fine. A note to the ones can't wait for a release: 1.Install hxcpp, nme, neash from haxelib. 2.Replace contents in neash's neash/display/IBitmapDrawable.hx to a simple "typedef IBitmapDrawable = nme.display.IBitmapDrawable;". 3.To make mouse event work, in neash's neash/Lib.hx, the code: // Process pending timers ... neash.Timer.CheckTimers(); // Send frame-enter event var event = new Event( Event.ENTER_FRAME ); mStage.Broadcast(event); should be moved to the end of the do-while loop, just before the: mStage.RenderAll(); 4.For mouse event in opengl mode to work, additional fix which required a recompile of nme is needed. I haven't tried yet. Now just ingore this... 5.You should be able to use Sandy3D in C++ without the above patches for the next release of nme/neash. But for now, please do it. BTW, I am also porting ported casalib, which I often use in AS3 development, to Haxe, see casahx.

I’ve successfully let OpenFrameworks and swf communicate using TCP socket. So I can use Flash’s 3D engines. I will not use ActionScript, instead, I will use haxe.

I’ve been using haxe for some time, it is a language that originally designed to compile swf file but has been developed to compile many more format, for example C++(and than use it to compile native codes). So I will write the rendering part in haxe, targeting swf and optionally compile it to C++ native binaries if possible.

The 3D engine of choice is Sandy3D. It has been completely ported to haxe and feature complete in haxe’s swf target. In the past week, I’ve been working to modify it to let it run on haxe C++ target. With the helps of Hugh and Niel, project owner of neash and developer of Sandy3D, quite a few demos is complied to C++ and running.

For more info on this progress, see my blog post.

Next step will be try using jiglibhaxe with Sandy3D on haxe C++ target. It is already usable on Flash target. So I can still use haxe Flash target if anything failed.

I've successfully let OpenFrameworks and swf communicate using TCP socket. So I can use Flash's 3D engines. I will not use ActionScript, instead, I will use haxe. I've been using haxe for some time, it is a language that originally designed to compile swf file but has been developed to compile many more format, for example C++(and than use it to compile native codes). So I will write the rendering part in haxe, targeting swf and optionally compile it to C++ native binaries if possible. The 3D engine of choice is Sandy3D. It has been completely ported to haxe and feature complete in haxe's swf target. In the past week, I've been working to modify it to let it run on haxe C++ target. With the helps of Hugh and Niel, project owner of neash and developer of Sandy3D, quite a few demos is complied to C++ and running. For more info on this progress, see my blog post. Next step will be try using jiglibhaxe with Sandy3D on haxe C++ target. It is already usable on Flash target. So I can still use haxe Flash target if anything failed.