Category: Mobile

After my initial post about the Away3D port to OpenFL, I’ve spent quite a bit of time working through the code trying to get more and more examples working. On top of this, OpenFL was updated to 2.0 and changes were needed to re-work the Away3D port for it to function. Unfortunately, it wasn’t a simple case of renaming flash.* to openfl.* plus, other bugs kept getting in the way.

Finally I’ve got to a point where some more fundamental functionality has been implemented and works across platforms, for the most part (more on that later) and as such have marked this release as 1.0.0-alpha. There are still plenty of issues to be resolved but this represents a large subset of core functionality.

From within the project folder e.g. /development/openfl/Basic_View to build and test the application simply use the following, specifying an OpenFL target.

lime test <target>

Areas for improvement/Problems

With this release there are a number of known, but not fixed, issues but will hopefully be address when I (or someone else in the community) can get around to fixing them.

WebGL/OpenGLES

I’m not an expert in WebGL/OpenGLES and so there are situations where the generated gl commands may not be optimal and also may be problematic in some circumstances. One of these areas is the allocation of frame/render buffers when rendering to textures. There are some warnings that appear through native traces or WebGL Inspector in Chrome which I’ve not got to the bottom of yet.

RenderToTexture on iOS

Whilst the rendering to texture works across platforms there is an issue with restoring the default buffers back after the render to texture. In OpenFL 1.4, it was possible to retrieve the ID of the renderbuffer so it could be restored after a RTT. Unfortunately, that call, or specifically the ENUM used to get the buffer is commented out of the NME backend. It’s made more complicated by the fact that the type returned should be a WebGLRenderBuffer/WebGLFrameBuffer rather than an ID as was previously used. I’ve just not been able to work through the tooling required to get the development version of NME setup with Lime and then to OpenFL to try and fix this issue.

iOS Texture/Lighting issue

As you will see in the video above, there are some odd artifacts coming through in the Basic_LoadAWD example on iOS. Similarly, the colours of the lighting on the Basic_Fire demo are also too saturated.

Android Loading AWD

There is a problem reaching a premature EOF on Android with the Basic_LoadAWD demo which is proving difficult to track down at the moment.

Moving forward

Hopefully some of the above issues will get resolved soon and more examples will be added demonstrating further completeness of functionality.

If you give it a try and find any issues, please log them on GitHub for either the core library or examples and I’ll get to them when I can. Should you wish to fix the issues yourself then that would be fantastic, just fork and send a Pull Request to get your changes into the project. Your help & support is greatly encouraged.

It’s been a while….

After just over a year since my last post on the NME port of Away3Dlite here is another post on my recent developments. A lot of things have changed since the last post, including NME taking a back-end seat to the new OpenFL platform and the upgrade to Haxe 3.

Ch-ch-ch-ch-changes.

As such large changes were happening, it seemed a little futile to re-work the NME version of Away3dlite due to the effort required. In addition to this, the Away3D team had created a TypeScript port which introduced a mechanism to convert AGAL to WebGL. Another factor which influenced the decision was the development of OpenFL-stage3D which implements the Stage3D API in OpenFL.

Finally, the decision was made to go for Away3D 4 and leveraging the TypeScript code to implement a convertor in OpenFL to go from AGAL to OpenGL ES.

It’s only over 450 files – how hard can it be?

After several weeks of a combination of automated AS3 to Haxe 3 scripting followed by hundreds of compilation errors, re-compilation, more errors and so on, first glimpses of functionality can be seen in this port.

It works!

Using the demos from Away3D, initially Basic_View, followed by Basic_Shading and Basic_SkyBox, features were implemented and fixed in to functional OpenFL demos that can target CPP builds including OSX, Windows (should work but not tried it), iOS, Android, Blackberry Playbook and other native targets.

HTML5 and Flash targets are not supported at present but that might be an option going forward. Away3D-TS the TypeScript port provides a HTML/WebGL solution for the web and the original Away3D Flash library serves Flash/Adobe AIR solutions. I was more interested in targetting a number of devices such as desktop, tablet and mobile whilst not having to depend on Adobe AIR as some of my devices don’t and will never support AIR – those being older iPod Touch devices, old Android mobiles and importantly for me was the poor old Blackberry Playbook which, unfortunately will not receive the updates needed to expose Stage3D.

The Demos

Anyway, as you can see in the video, there are a range of devices used to demonstrate each of the demos – some do better than others.

The Source Code

The source code for the demos and more importantly the source for the library are available on github.

This is a very early and unstable codebase. Some of the classes have not been referenced yet so will not compile without some tweaking. Please feel free to fork and issue pull requests if you fix something – and there is still a lot to fix.

Hopefully the port will become more and more complete over the next few weeks and eventually be a complete Away3D V4.x port to OpenFL.

If you don’t already know, Haxe NME allows you to write code in a language that has strong similarities to Actionscript 3 but compiles down to native code across multiple platforms including iOS, Android, BlackBerry, Windows, Mac, Linux, Flash and (beta) HTML5. Admittedly, Adobe Air also provides a fantastic mechanism for publishing to multiple platforms but the temptation of native performance was very enticing.

Introduction

What you see here is a brief summary of the NME port of Away3Dlite proof-of-concept.

Check out the following two videos (available on YouTube) to see 3D in Haxe NME in action .

Starting off

To begin with, it took no time at all to set myself up to build the supplied examples. The biggest thing for me was having to install MonoDevelop and the plugin to build NME applications. I use FDT on a day-to-day basis and there are Haxe templates but unfortunately, I couldn’t find any NME templates and didn’t want to spend any time trying to create one.

With MonoDevelop & Haxe NME setup, building and deploying to all my devices was incredibly easy and I had the supplied Box2D example up and running on my Mac, iPad, Blackberry Playbook, iPod touch 2G and Huawei U8510 (Ideos X3/Blaze). What was particularly interesting for me was that it was now possible to easily build and deploy to my devices that don’t meet the min specs for Flash/Air – so I’ve been previously unable to develop for these devices (iPod Touch 2nd gen & Huawei U8510). Very impressive.

Lets go for an Away3D test drive

My first idea was to try a simple Away3D type test and this was my first problem. The only library that has been ported to Haxe is Away3Dlite. No problem, I can give that a try. This was where the second problem arose and my noob-ness was showing. Having not played with Haxe before, I didn’t really know what the differences were between it and Haxe NME. As such, when i came to use the Away3Dlite Haxe code, I found lots of reference to flash.... packages rather than nme.... packages. This meant that the port of Away3Dlite was for Haxe only and for NME it needed to be different.

I then started to realise it was not going to be such plain sailing as I had first thought. I soon found that there were some fundamental missings from NME – namely the z property on display objects and other 3D supporting classes and methods.

Building on Haxe NME

The next part of the setup, to allow me to add the missing functionality was a little more problematic but all those problems were down to relatively straight forward problems, but unless you know what you’re doing, can seem quite fundamental stumbling blocks – it was a bit of new territory for me. A quick post to the forums on www.haxenme.org pointed me in the right direction and soon enough I was able to have a play.

My objective, and proof-of-concept was to get Away3Dlite or more specifically, the Haxe implementation working under NME so I can build native apps.

The Proof-of-concept

This port, for now, is a far from complete NME port of the original Away3DLite Haxe port, with the addition of NME extra bit’s-n-pieces so it all works together. As Away3dlite is based on Flash Player 10, there is no Stage3D code in there, just good old fashioned DisplayObject type stuff. Also, this implementation also only supports iOS, OSX, Blackberry and Android targets in NME, so far. I suspect the Windows and Linux targets should be ok if they depend on the neash packages but I’ve not really tried the Flash or HTML targets as there may be conflicts or un-implemented features that I have built into NME and the neash packages.

You may be asking ‘why bother’, as Stage3D bring huge performance improvements with greater capabilities and is supported across multiple platforms. Well, for starters, Away3Dlite had already been through a port – so the starting point wasn’t right at the beginning. Secondly, I’ve been annoyed for a while that I have devices that I couldn’t build for. Yes they are low-spec or quite old but it seems a shame that other apps work well but anything done in Air can’t be published – very frustrating. I was also curious to see what performance could be had in comparison to Stage3D – and that’s something I still need to ascertain – See the ‘The Future?’ section below for more info.

One major reason for giving it a try was to get familiar with NME and begin to understand what can be achieved with the platform and I am very impressed so far.

On to the demo

All the demos are versions of the standard ExMQO.as example from the Away3DLite examples git repository. It loads a Messerschmitt BF109 aircraft and clones it four times, positioning them in a cross formation, then on each Event.ENTER_FRAME increments the X,Y and Z rotation of each model.

In total, there are 6072 triangles in the scene with approximately around 3000-3300 triangles visible at any one time. So it is quite an intensive demo.

The following is a performance table of all the devices used in the above videos. The performance FPS are not especially accurate, more indicative of the comparative performance on the devices under relatively normal operating conditions. Also, there may have been other factors that contributed to the values, good or bad, which I may have overlooked.

Performance scores – from my observations

Device

Air Captive Runtime FPS

HaxeNME FPS

MacBook Pro 13″ 2.26Ghz Core 2 Duo

17

37

iPad 3: iOS 6.01

3

11

Blackberry Playbook: OS 2.1

4

11

iPod Touch 2nd Gen: iOS 4.2.1

not supported

5

Huawei Blaze/Ideos X3/U8510: Android 2.3.5 (600Mhz)

not supported

4

For the iPad and Playbook, both the HaxeNME version were built and deployed along with an AIR captive runtime version whereas the iPod and U8510 could only manage the HaxeNME version – but at least they managed it 😉

Admittedly, the performance wasn’t phenomenal but to be honest, I wasn’t expecting it to be that high really. The POC takes advantage of HaxeNME’s GPU graphics rendering but ideally it would implement the GPU drawing in a far more efficient way to take advantage directly of the ‘z’ property (at the GPU level), depth buffer, etc, as used in more conventional hardware 3D rendering scenarios including OpenGL and Stage3D. This implementation pre-transforms all the triangles from 3D to 2D on the CPU rather than feeding 3D information to the GPU drawing API and even then the drawing uses the default system within NME rather than being an optimised version. I went for an ease in implementation rather than trying to change the rendering pipe-line of NME (I did look at it originally, but things soon broke so I stayed away from it for now).

There are bound to be a lot of optimizations that could be made by coding C++ implementations of methods rather than relying on the HaxeNME translation, none of which have been investigated as yet.

I suspect there is plenty of room for performance improvement.

And now?

Okay, the proof-of-concept did it’s job and I have an operational (too some degree) Away3Dlite port in Haxe NME, which is what I was after. I’d like to try and produce a more functional application using the port to see the what real world performance increases can be achieved.

I’d also like to investigate areas where I could improve performance. This will always be a trade off though between time and complexity of the solution – quick wins are good but re-writes/refactoring may need to happen to achieve significant gains. I need to understand the inner workings of NME in greater detail to have the confidence to dive in there.

The Future?

I know the current 3.4.4 beta of Haxe NME now has experimental support for OpenGL 2 and has examples of using shaders. I’d love to be able to port Away3D 4.x to HaxeNME for a full featured NME 3D engine. Again, I think it would take a while to implement as it would either require implementing Stage3D functionality in Haxe and NME or alternatively working the other way around and reworking the Stage3D implementation in Away3D and re-write necessary elements, such as shaders specifically for NME – even an NME rendering system.

Certainly a lot to think about but an interesting challenge. We’ll see what happens

You can see the new Halftone effect and Displacement effect in the images below.

The Halftone effect can give your images a magazine/newspaper ‘print’ look. Coupled with the background images, frames you can add and vignetting you can create some astonishing photo’s straight from the Playbook camera.

You have full control over the size of the ‘Halftone’ blobs and rotation of the pattern. You can change the foreground and background colours or even opt to have the background transparent.

The Displacement effect displaces/refracts the photo using a particular pattern. There are a number of patterns to chose from and they can all be scaled and rotated. You can also adjust the strength of the image displacement/refraction and optionally add a psuedo depth (bump) to the displacement or make it transparent.

Warp-a-tron for the Blackberry Playbook™ is now available through the Blackberry App World.

Warp-a-tron allows you to take snapshots with special effect directly on your Playbook. Preview and adjusts the effects in real-time using the multi-touch screen controls and save your master-piece to JPG or PNG in your photo library.

Choose from a whole range of special effects including zooms, twirls, colouring effects, etc and even optionally add a frame to you picture.