The case for integrated, native physics in the Flash Runtime

[chris.campbell]

Hello everyone,

As hopefully many of you know, a community based feature request page was created a few months back (Feature request for Flash and Air - uplist) and we've had a number of great ideas added and voted on.  In an attempt to better understand the individual requests, we thought we'd start threads on particular subjects to allow us to ask questions and get community feedback.  These posts should not be taken as a commitment to a particular feature (or lack of commitment to any other feature.)  I can't stress this enough.   I don't want anyone to think that we're ignoring other requests or to assume that because we're asking about something, they can expect to see this done in a future release.  We simply want to better understand the request so that we can reduce the number of assumptions on our part.

To start, let's we've got a few questions regarding the request for "Integrated (native) physics" which currently has 142 votes.

• When talking about physics, are you interested in a 2D or 3D physics engine?
• Can you list native engines that demonstrate the features you want the Flash runtime to implement natively?
• For instance, if you're interested in Box2D functionality, have you tried http://www.box2dflash.org?
• Is there a huge performance gap between the native and ActionScript implementations of Box2D?
• Are you looking for solutions for desktop or mobile?

Thanks,

Chris

[makc3d]

To this part:

• Is there a huge performance gap between the native and ActionScript implementations of Box2D?

you might want to watch this video:

[hnjps]

• When talking about physics, are you interested in a 2D or 3D physics engine?

I'm interested in a 2D engine.

• For instance, if you're interested in Box2D functionality, have you tried http://www.box2dflash.org?

yes I did and performance is very bad on mobiles.

• Is there a huge performance gap between the native and ActionScript implementations of Box2D?

yes a huge one.

• Are you looking for solutions for desktop or mobile?

both

[Ben_Leffler]

Agree with everything hnjps said - but my primary focus (in 99% of cases) is mobile.

[chris.campbell]

Thanks for the video.  Given the results, would an open source ANE project be a better solution than a closed implementation in the runtime?

[makc3d]

Chris: a number of Adobe ANEs already exist but hardly get any attention by Adobe. So, if you are going to make yet another (physics) ANE, please make sure developers will be maintaining it in the long term, OR you could just support someone else in a manner you are doing it with Starling/Away in doing it.

Pro-NAPE guys: NAPE API is indeed nicer, and - unlike flash port of box2d - it is still worked on. But have you seen the sources (specifically, did you ever build them : ) In the same time, C++ version of Box2D is actively developed and straihtforward to compile.

[Infin8]

I would second @makc3d's comments. Unless creating a new physics ANE has some huge benefit over existing solutions why add more things to maintain. Especially when there are so many unfixed bugs still waiting for attention.

[zwetan_uk]

please go with the option of having an open source ANE

but still do own/maintain the project

if possible open source the already existing ANE

reasons:

- you may have already existing libraries or ANE out there

   but none of them know the internals of the Flash/AIR runtime

   as well as the Adobe dev

- if it happen the project end up in "oblivion", not updated etc.

  being open source it allows other dev to keep updating it or at worst fork it

- don't fool yourself, such project can not be dependent on Adobe only

  as developers you need to contribute or such project will never come to life

now, let's see what can happen,

a bunch of dev works either on NAPE or Box2D native port in an ANE
with the help of a couple Adobe folks

-> when the dev hit big problems related to the AIR runtime, the Adobe dev can push them in the right direction

-> the work will mainly be done by those dev, not really the Adobe dev

the worst situation imho would be to have 3 or 4 devs instead of joining forces under 1 project,

to split into 3 or 4 different projects ...

worst than that, having no contact or help from Adobe, for when the really tough problems occurs

you have really no one to turn to ask questions

[PhilipThonbo]

2D please

Nape

mobile first (AIR)

nape runs great performance on 2d on mobile

[Mahron]

Native physics would be great for 2D and 3D, desktop and mobile.

Not necessarily the whole engine but fast collision detection functions like :

ray-triangle ray-sphere collision detection for 3D

or line-line line-circle rectangle-rectangle for 2d

those are the cpu killers(especially for 3d). The rest can be as3.

In my opinion runtime integration would be the cleaner solution + it would be cross platform.

[MSGhero]

NAPE's api is nicer than box2d's.  Mobile performance is more of an issue than desktop performance, and I'm interested in 2D.

[Rahul_Kamra]

2d Engine for mobile , with  api similar to nape on  Mobile / AIR . I tried nape on mobile, its fast but can be better.

[FramaisCellarGhost]

• When talking about physics, are you interested in a 2D or 3D physics engine?

2D please.

• Are you looking for solutions for desktop or mobile?

Both, for me, priority is mobile

Thanks for the great work you guys are doing on AIR/Flash, keep it up!

[b_whiting]

Hi Chris,

Glad you guys have taking an interest in the uplist we made!

From my point of view an inbuilt physics engine is something that will be a big commitment from Adobe's part that perhaps could be spent better in other areas.

Here is my pros and cons for the idea.

Pros:

Awesomeness, no doubt it would be a great and exciting feature to add to the list of capabilities of the flash runtime.

It will help restore faith in the flash platform... it is still being improved and not just with bug fixes but with huge new features!

It will put flash back on the radar in terms of new developers and probably help a few of those who have moved on to reconsider coming back to flash.

It would be built with flash in mind from the ground up producing a much more performant and gc friendly engine.

It makes flash a more competitive option against unity for 2d games.

It would remove a barrier to entry for more novice developers.

It would enable physics to run on mobile devices without taxing their cpu's as much.

Any new feature for flash is a pro in my books!

Cons:

It will probably take a fair bit of time/effort to get it up and running well.

It will no doubt need to be maintained/updated for some time to come.

If it doesn't quite resonate with what the community needs/expects it could end up becoming a burden and a source of frustration for some (not likely but still possible, i.e. if it ends up still being slow, or the api is akward...)

Time spent on this could be time spend on improving the current architecture.. if you could make actionscript run as fast as java (or even faster) in terms of math, function calls, execution speed etc... then the existing libraries would probably do the job just fine with a little tweaking here and there.

Whatever you do we are glad you are listening to your developers!
P.S. Make flash faster... I know it can be done!!

[pshtif]

I think having high level physics engine natively isn't that good of an idea as the resources can be spend better and there are already great physics engines or ANEs. What you could do though is implement low level methods natively that will help speed up these engines without bringing your own high level engine. For example native triangulation methods (this would even help in other areas and was requested for long time), more robust native geom functions for collision testing etc. Leave the high level stuff to the community and just speed up the low level, I mean I was told years ago that you guys already have triangulation algorithms inside Flash player its just not made transparent to developer, why not? So look at what these engines actually need to bump up their performance and implement that instead of working on your own engine.

[Mal_CanDo]

A native 3D physics engine, that could be restricted to allow for 2D physics, would be great.

Having a fast mobile physics engine would be crucial, and also having native constructs such as eg character controller or vehicle.  The Bullet physics ( AwayPhysics ) is great for online, and the ANE seems like a good option for offline, but having these technologies integrated ( either Bullet, or Havok ) and easily available to developers would encourage their update.

Here's a link to an example of AwayPhysics being used for a Flash game for the recent Lego Movie.  Without the built in vehicle template, this level of raycasted vehicle physics not have been possible.  Note that AwayPhysics was slightly modified to work with Flare3D in this case.  Also note that this is desktop only, a fast mobile version would have been a great option to have.

The LEGO Movie | Glue Escape Racing Game

Just out of interest, Intel originally created a physics engine for Adobe Shockwave to go alongside their 3D engine ( Shockwave 3D ) for v8.5.  Before releasing 8.5, they licenced Havok physics and shipped it as an Xtra for offline and online usage.

Intel purchased Havok several years ago, so it would be cool to see a similar effort made for Flash.

[Neverbirth]

I'm with pshtif and makc3d, there are already some libraries and ANEs out there, are you sure developing your own ANE or integrating physics in the core runtime is going to be beneficial and you have the resources to not leave it in oblivion or severly outdated? maybe in the long run it's cheaper to improve math performance/add new numeric data types/add generics/add native triangulation and geom functions. In the old days some of these were rejected because it broke compatibility with ECMA standards, does it really matter anymore? why not your own "ECMA standard" (does it matter if it's not even a standard? I guess getting a standard qualification costs money)? AFAIK, Micosoft did so with C#.

Just thinking aloud, I'd love to get more into gaming, but I make (a lot of) other types of apps, so physics is not that important to me, and the things I've proposed would also benefit other things, like encryption, which would also benefit games, although in other areas.

[Varnius]

Not a priority. Improving overall runtime performance should be a priority as it would benefit all AS3 libs, physics ones included.

[Mr__Chamberlain]

I don't think it's really the responsibility of the Flash Player and/or AIR runtime to implement physics (at a built-in level, at least).

An ANE extension project (particularly like the one demonstrated in the Bullet vs. Away Physics video in the comments) would certainly be awesome, provided it's cross-platform on both mobile and desktop.

Like others have mentioned, overall improvements on number-crunching performance in the FP and AIR runtime would be more desirable than simply focusing on just the area of physics, since it could benefit multiple aspects like faster for-loop iterations, collision detection, sound generation / effect-processor, file reading/writing/parsing, AND physics, etc.

It would be interesting to see other posts/questions from Adobe like this towards some of the other popular voted features that the community requested in the uplist page.

Personally I would like to see how much interest there is for a better Audio API (for handling DSPs, sound effect processing, MIDI I/O handling), again this could be a crossplatform ANE. But I won't wander off on a different topic too much here, just thought I'd mention it!

Thanks for listening to your community, Adobe!

[rafael_lima_30]

Not why advanced physics with NVIDIA PhysX support like on Adobe Director 12?

For Desktop and Mobile: Adobe Director

[shawnb81]

I'm all for the addition of a native physics system, based on Box2D, that gives us native speed.

But, I'd also like to suggest that you make sure that you are committed to polishing and improving the new API's, and not leave them stranded at v 1.0.

For example, GameInput API is rife with bugs, and there seems to be no interest or pro-activeness on the part of Adobe to fix them. Zeh Fernando has put in a ton of work in standardizing the GameInput API, and he has been quite vocal about the issues, and as far as I know, no one from Adobe seems to care at all.

Here's a link to his gitHub repo, where he lists current issues with the API:
zeh/key-action-binder · GitHub

know that Flash's GameInput API is still severely ridden with bugs. You may run into some of them. Here's some more information.

• Supported devices are not detected properly when added or removed (Bug #3709110😞 no workaround
• Using GameInput add Timer overhead every second in Windows (Bug #3660823😞 no workaround
• GameInput devices simply stop working when running on Android/OUYA: need to initialize things in the first frame of SWF (fixed in AIR 13.0.0.36/Flash Player 13.0.0.130?)
• Quick button presses may not be properly detected on Macs (Bug #3702039😞 no workaround (need to test sampling rate changes and if button activation can always be assumed from the up event)

In addition to those, I have run into a major bug on nVidia Shield, creating huge lag in inputs. The bug is nearly 12mths old, and is very severe:
Bug#3673122 - Shield controller massive lag

I'd love to see the AIR team being much more pro-active about bug fixing. It seems to be like pulling teeth sometimes to actually get something fixed. I would think that the team, after putting in a big effort to implement GameInput in the first place, would be extremely pro-active in seeking out feedback and fixing the bugs in the first 3-6mths since release, to harden the API, but instead no one seems to care, and the onus is all on us to "file a bug report and vote", which seems code for "might get fixed, one day, maybe"

We love AIR so much because of it's consistency, but new API's need to be as consistent as old ones, and need constant iteration and improvement as well. I know it's flashier to add a new bullet point to the marketing check list, but consistency and reliability are much more important in this chaotic and fragmented landscape.

/2 cents

[_arieln_]

I think the initiative is good!, we ended doing our own tiny physics lib for Flare3D because we couldn't find any solution that was suitable for our needs (Flare3D Collision detection and Physics simulation library. - YouTube) , it is super fast for some tasks, but it lacks of some mayor features already available in commercial or free libraries like Nvidia PhysX or Bullet.

The only 3d physics lib available right now is the Away3D port of Bullet, which is good, but slow, and not suitable for mobile at all.

There were other libs like JigLib (discontinued?), or Oimo which is very fast but too simple.

There are options for 2D like Box2D or Nape, but not much for 3D.

I don't think building an ANE is a good idea, Flash/AIR is not only desktop or mobile, is a cross platform solution and should remain that way.

Some more thoughts....

Building the collision detection tools only with native speed, could be good in the way we would have freedom to implement those as a building blocks, but physics is not only about collision detection...in fact...that's the easy part problems comes when integrating solvers, caching contact points, balancing the beast, tuning and hacking it to make it work....so having a single algorithm to detect collisions, its also limiting in sort of lots of different ways.

So, my conclusion is, having a well integrated 3D lib, native speed, full feature set, integrated with the runtime and ready to use, could be the way to go.

[Mark.fromOP]

Would love to see a native physics engine that runs smooth on mobile, but also like the idea that others suggested of supporting a third party existing engine.

[moccamaximum]

With some of the AAA-Gameengines going Free-to_use (Cryengine, Unreal 4) or migrating to a renting model. I get the feeling Adobe is a little LTTP.

The moment Unity adopts a similar pricing model, Flash will not only be the most expensive but also the most "underpowered" Gameengine to integrate physics.

No thanks, bring back some really useful stuff (like AS2 support ) in CC++ (or whatever it mayb called) and leave the "serious" gaming stuff to adults.

[ccaleb]

Hi Chris,

Here are my thoughts:

1. I'd like to see 2D physics integrated into the Flash & AIR runtimes if it would provide significantly faster performance than using a 3rd party library.

2. My preference would be an implementation of Box2D. I know Nape is an awesome physics engine but I'd rather Flash natively supported Box2D because of its popularity across other languages.

3. I'd only really be interested in physics being integrated into the runtime if it were to be properly maintained. For example, if there are updates to Box2D then I'd expect to see the updates to the ActionScript API also.

4. I would probably prefer to see physics integrated within the runtime rather than a separate ANE.

5. I use AIR primarily these days and target mobile. However, it's important that the physics engine is available across both Flash Player and AIR.

6. Some features that I'd really want to see over and above the absolute basic 2D physics engine stuff:

i. Ghost Vertices via b2ChainShape. (http://www.iforce2d.net/b2dtut/ghost-vertices)

  ii. Collision Filtering via categories and bit masks. (http://www.iforce2d.net/b2dtut/collision-filtering)

  iii. One-way walls.

  iv. Sensors (http://www.iforce2d.net/b2dtut/sensors)

  v. Joints - including revolute, distance, line, weld, pulley, friction, gear etc

Thanks.