Archive for February, 2010
I recently started on a 3D Flash job and was chuffed to find that Cauê Waneck has been porting Away3DLite to haXe. Anyway, suffice to say I was super-happy that I didn't have to do any AS3.
What's there currently is a direct port of the Away3dLite library, but in haXe. It makes a big use of the AS3 (FP10) native Vector (Vectora<Float>) so it's quite fast, but not directly portable to platforms other than Flash 10 yet. As far as I can tell performance is the same as, or similar to the FP10 AS3 release, but Cauê has assured me that he's having fun optimizing it.
Away3DLite is missing some functionality that is in the full version, things that I need for my current project, including the Morpher and AnimatedBitmapMovieMaterial classes. The first I've ported myself and the second has been ported by Cauê (thanks mate!).
And the Morpher.hx class.
I had a lot of trouble getting it working to start with but it's pretty easy once you get the ideas down. The main problem I had was the fact that neither the Collada object, nor the Object3D you get from it when doing .parseGeometry() has any vertices, so I got nothing when I passed it to the Morpher. What I'd missed is that I need to get one of the children from the Object3D that I get from the Collada .parseGeometry(). This is because, as Bartek Drozdz points out, "a Collada file represents a scene, not a single 3d object".
The next thing to know is that you should wait for the ParserEvent.PARSE_SUCCESS events dispatched from your Collada objects. When these are done you can use .getChildAt(0) on your .parseGeometry(colladaData) object to get a Mesh which you can then parse to your Morpher. In my example I have:
m0 = cast c0.parseGeometry(daeData1); // used to restet Morpher to original state
m1 = cast c1.parseGeometry(daeData1); // the model that I scene.addChild(m1) to
m2 = cast c2.parseGeometry(daeData2); // the model to Morph to
As you should notice I'm using the same daeData for both m0 and m1. I make my new Morpher passing it m1, then on each enterFrame:
mp.mix(cast m2.getChildAt(0), (1 + Math.sin(Lib.getTimer() / 150)) / 3);
mp.mix(cast m2.getChildAt(0), (1 + Math.cos(Lib.getTimer() / 250)) / 3);
Hope that helps someone else, I was stuck for days
Yay my first post in months!
We are working on a top down racing game, where the background scrolls vertically. This soulds like something flash should be able to do - no sweat! I've run into two issues:
1 - massive screen tearing - as the whole screen is scrolling vertically
2 - fluctuations in the processing time of frames, causes non-smooth motion (i think)
Here is a simple test of black balls falling down the screen. You should see tearing on the circles, rending issues (the bottom of the circle is cropped off sometimes) and jumpy verticle motion. I've tested on various computers+systems & it seems the issues running from worst to best are as follows:
VIEW TEST - maximise the window for most shocking results
windows xp x64
To me it doesnt make much difference between firefox, ie, chrome. Most tests were run on QuadCore 2.5ghz comps. Except windows XP, which is P4 3.0, and macbook 2.4. - funnily the slowest comp (p4) ran the best.
It is quite common knowlege that flash doesnt perform any doublebuffering or v-sync, to fix screen tearing. UnitZeroOne has a great article on this. Luckily flashPlayer 10 has a new WMODE - DIRECT, which seems to fix the issue a fair bit. According to adobe it: "The direct WMODE will use your video card to paint pixels to the screen as fast as possible while freeing up your CPU to work on other tasks"
This seems to have a few issues with rendering (for us thus far) But it is a LOT smoother. It seems that it shouldnt have too much of a speed decrease (like transparent/opaque) either, after looking at some tests
Circle test in:
The final issue:
AS you can see, the motion is still not totally smooth in DIRECT mode. It seems that flash has issues with updating the frames at a constant interval, which is noticable when i want a constant scroll. I dont know if there will ever be any way to get around this.
I've made a new version which moves the balls based on time, rather than frames. It basically moves 300pixels/second. ~ the same speed as before. It doesnt seem to make too much differnce - sometimes you get large jumps as the time lapses, and then the balls need to catch up - so not a great fix, but interesting.
download v2 test source (only haxe version is time based)