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

[adampasz]

Not a huge priority for me. Only a small subset of games/apps. need a full-blown physics engine.  I would prefer to see more effort put into polishing existing APIs, fixing bugs, and improving mobile device integration (iOS mute button, native dialogs, SMS, etc.).

[makc3d]

I am sure you know that Apple went for built-in 2D engine by now: http://www.bytearray.org/?p=5314

[dmennenoh]

I would vote 2D and to have an implementation of Nape personally. I've used both B2D and Nape and find Nape much easier to use - plus it's loads faster than B2D.

[Euklide]

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

3D physics only.

• Are you looking for solutions for desktop or mobile?

Currently, desktop.

[Gary_Paluk]

Hi Chris,

I see little point to native physics as an integrated library. Bullet Physics is already available as both an ANE and a compiled SWC, in fact, I just integrated Bullet with Zest3D and it was able to be compiled with Crossbridge. Whilst the performance can be slightly better, this would cause a fixed API and physics engines are very much a decision that is granularly based on the level of accuracy that you need and the dimensionality of the physics world-space. A better option might be to expose a hardware physics API that allows access to the PhysX GPU along with a fallback.

Probably important to note that those aren't too great either, the overhead talking to the FlasCC compiled SWC actually slows things down so the GPU case is definitely a better option, Zest3D has physics integrations that performs more like this on mobile and running in pure AS3:

• Zest3D Physics Galaxy Tab 10.1 - YouTube

Personally I think that, at this time, there is much more win factor from spending the development time on any of the following:

• Direct OpenGL|ES2 context access with GLSL shaders
• Crossbridge update (This is essential to the future of FlashPlayer IMHO)
• PhysX GPU API
• AS4 and/or compiler updates @see Haxe performance
• AMD Mantle/MTL support (hidden from developer or profile parameter)

Regards

Gary Paluk

http://www.plugin.io

[esDotDev]

I'd disagree, if you look at all the main alternatives to AIR, they all have baked in Physics support: Corona, Unity, Swift etc, if it's good for them why not for AIR?

If Adobe really want to make this great though, they need to give us tooling support in Flash Pro, then you'd have something on the level of Unity ease of use, which is pretty damned great.

[Gary_Paluk]

One of the greatest things about Flash/Air is that it doesn't try to lock you into a specific engine like your aforementioned tools. Air is basically a runtime packager and not a game engine solution so third party libraries exist such as Starling, FeathersUI, Away3D, Zest3D, Flare3D, Genome2D etc. All of these platforms have different implementations and that should also be the case for physics solutions. For example, I might just need a fast approximated physics engine or maybe I need a more rigerous RK4 modelled system. Engines like Unity have a single solution which make it impractical for so many other tasks but exposing the PhysX API is generalized, similar to the generalized GPU graphics API.

Next up is being locked into the development environment, what a huge fail that would be. You could say goodbye to all AAA game companies ever wanting to touch Flash again. The workflow of such companies simply wouldn't correlate to having to drag and drop assets in Flash Pro, it would be suicide. Exporting assets from real-world 3D asset production tooling such as 3D Studio Max, Maya or even Blender is preferable and these tools can be used for the creation of scenes. The support offered by the leading libraries already have the capability and tooling that you are asking to be locked into Flash Pro.

These engine systems are still evolving and that takes time, I wish it were faster and the road to a great production workflow for my own engine could be met more quickly, but locking down solutions is IMHO probably one of the worst ways to destroy the great platform flexibility of the Flash and Air products.

[esDotDev]

You wouldn't be locked into the dev env, there would still be an API you could code against. Adding tooling support would just be an easy win, a case of building on your strengths. I'm envisioning the ability to use flash pro to basically make "prefabs" out of Movieclips, and export with a SWC. It would be hot.

As for the "greatest" things about AIR go, I guess we differ there. My top features of AIR is not openness, it's consistency, reliability and a robust hardened API. Coupled with a great tooling support for building 2d UI and assets. A native physics lib reinforces all of those strengths, and also eliminates a major glaring weakness.

[Gary_Paluk]

I think the main issue wasn't really addressed in your reply. What if I want to use the accuracy of RK4 for one of my driving games, but a very fast solution for my million particles with gravity and plane collision. Would your API have support for rigid bodies, soft bodies or both and then what about fluid dynamics? Cloth simulation? Hair? Voronoi calculations? Would it be 2 separate APIs, one for 3D and one for 2D? My point was addressed by my mention of granularity in the original post. It would be cool to get your ideas about the practical implementation to the vast array of considerations but giving access to the PPU would allow developers to create plenty of their own solutions, similarly to the way that they have built their own 2D and 3D engines.

[esDotDev]

Personally I'm referring to a 2d physics engine. Most games that come out of Flash are 2d are they not? I'd like to see some numbers on that, but my guess is about 90%+ is 2d.

In general, it's really hard for Flash to compete with Unity in terms of 3d when you look at the authoring environments and (especially) Unity Asset Store. It still has many advantages when it comes to 2d though, most of which are related to the asset workflow in Flash Pro.

[chris.campbell]

Thanks for the feedback so far.  At this point, we're going to focus on the swc/crossbridge/ane approach and see if we can help make these scenarios (and existing solutions) as performant as possible.  A number of people brought up the point that we have, at times, added features and then seemingly stopped development on them (I'm looking at you gameinput...)  We believe this is a fair criticism and something we want to avoid if possible.  We'll also go back to these features, like the items raised by shawnb81, and see if we can fix some of the critical long standing issues.

[Gary_Paluk]

Hi Chris, don't those solutions already exist? You see an ANE and SWC solution presented in the video above. Isn't Away Physics, that you fund, the same as that crossbridge solution already? A point that I want to raise however is that the geometry buffer of an engine may be interleaved, so, my point is to raise the issue of how to access that data and provide it to the pointer system of the CModule. I suggest being able to describe the vertex data, along with a stride offset thus making it possible to use none interleaved and interleaved buffers.

I'm trying to understand if it is the full engine (such as Bullet) that you want to provide, or faster mathematical methods that are useful when dealing with physics systems? Such as ray calculations, point<->point, line<->point, line<->line, tri<->point, tri<->line, tri<->tri collision checks etc?

Regards

Gary

[makc3d]

@Gary he says "help make these scenarios (and existing solutions) as performant as possible". I.e. improve those existing ANEs/SWCs

[Gary_Paluk]

Yeh, I'm not sure where they think that they will get the performance from unless Adobe commit to fixing the errors with crossbridge including issues with pthreads. I really hope this means that Abobe will recommit to the crossbridge compilers. What do you say Chris?

[Neverbirth]

I hope that working on your own physics library make you work on improving maths performance, add better data structures (if we have a Vector.<T> class, why don't we have a Dictionary<T1, T2> or HashSet<T> ones? although having generics we could use would be the best), etc.

"Yeh, I'm not sure where they think that they will get the performance from"

Well, Haxe has always shown that our code, running under the same VM, can be faster and without relying on alchemy. Some of those bottlenecks are because of the compiled bytecode, but others because of the language itself. Would be nice to see a modern benchmark comparing a Haxe SWF and an ASC 2 one.

Having generics would be an instant win, you'd avoid tons of castings operations, and code would be better organized and more reusable. The same goes for more numeric data types, and some type of const where the actual value is always embedded in the code would also improve performance. I get why consts currently work as they do, but I don't always need them to behave as they do, and there are benchmarks that show there is performance improvement to gain from there.

I think I'm being very rational and realistic.

[Gary_Paluk]

I think the state of the compiler is a different topic altogether, as for having generics, it's obviously a feature that would of been desirable but at the same time, I can't help but feel that there was something stopping that from happening when they introduced the Vector type.

As for - "Yeh, I'm not sure where they think that they will get the performance from"

That is in reference to how they could make the C++ code run faster when compiled with Crossbridge. I don't believe that there is not too much that could be done there without the entire overhaul of the system that you're suggesting, but this is not within the scope of what is being proposed here. I assume that it was these types of compiler/language issues that ASNext and the new VM would have set out to fix but Adobe have already stated that is not continuing with that. Without a reversal in that decision, we could possibly expect better compilation but I doubt that we would get generics. (What is stopping generics Chris?)

Anyway, back onto the topic of physics systems.

[Neverbirth]

"(What is stopping generics Chris?)"

My understanding is that Adobe has always linked ActionScript and ECMAScript (in my point of view, an effort to move ES implementation forward), and back in the day generics would make AS differ too much from ES and were discarded.

I don't ask for a complete overhaul of the system, again, Haxe supports generics, abstract classes, etc and the resulting binaries run in the AVM 2 (even if they add some work arounds for some of those features). Having support for some of those things not only make AS a better language, they make us more productive developers, and that could mean more and better public libraries as well.

I know the main topic is physics systems, but the topic is also "should we spend resources on a physics library?", to what I reply "if you have resources to spend on something that would help 80% of your end-users, why not spend those resources on something that would help the whole 100% of your users?".

[makc3d]

> I don't ask for a complete overhaul of the system, again, Haxe supports generics, abstract classes, etc and the resulting binaries run in the AVM 2

why should adobe make another haxe?

[Neverbirth]

>why should adobe make another haxe?

Last time I checked those language features were not exclusive to, nor an invention from Haxe heh. Just using Haxe as an example, because it allows you to use those features while still compiling ActionScript bytecode, meaning there is room for improvement without sacrifing what is already available.

[dmennenoh]

I'm sure I'm missing something, but isn't AS3's Vector class much the same as generics in, say, C#? The syntax is even very similar, and generics (at least in C#) are used for much the same thing as Vector in AS3 - storing lists of same typed items.

[Neverbirth]

> I'm sure I'm missing something, but isn't AS3's Vector class much the same as generics in, say, C#? The syntax is even very similar, and generics (at least in C#) are used for much the same thing as Vector in AS3 - storing lists of same typed items

That's my understanding as well, and why I asked if we have a Vector.<T> class, why not Dictionary.<T1, T2>, HashSet.<T>, etc. Guess a LinkedList.<T> would also be benefecial as well.

[zwetan_uk]

"Would your API have support for rigid bodies, soft bodies or both and then what about fluid dynamics? Cloth simulation? Hair? Voronoi calculations?"

humm to want everything you may obtain nothing ...

adding a physic engine ok great , but you have to keep your feature list close to the essential

first and foremost, to have too much 3rd party libraries can be a weakness

having only 1 starling library is good, if you had 2 or 3 competing whith each other it would not really go anywhere

or at least the general development would be much much slower

look what happened to the 3D libraries for the last few years ... I mean before you had somethign like Stage3D,

it really serve no one to have different people spliting forces doing about the same thing in different environments.

In fact, look at what Adobe did with Stage3D, they provide the raw native engine which can be evolved toward more specific 3D engines, you should expect the same for a physics engine; eg. something native, raw and very basic but that bring the speed to implementation of physics engine on top

asking for stuff like cloth simulation is a bit ridiculous IMHO

[Oussama_Gammoudi]

Hi,

- I think that flash future is in gaming & so an integrated physics lib like Nvidia Physx is a must.

- For 2D there are many solution already with great performance, but when it comes to 3D, preformance is a huge problem.

- Ane open source project has to be left to the community so that the adobe team effort can be focused on things that the community cant possibly do like the integrated physics.

- Saying that the current most games are 2D is in reality because creating a physics based 3D game is just a big of a pain because of the lack of a good solution. Having an integrated 3D physics will make flash a viable option for online hardcore 3D gaming.

Regards

[caiocanalli]

Hello Chris,

An integrated physics engine would be a great addition. However, many applications built in Adobe Air are not games, but rather tools. I think an improvement in runtime, it would be a better resource, as would affect all other fields.

We already know that Adobe dropped the idea of ActionScript 4, then the power of change is in the hands of his team, which has direct access to the runtime. I have applications that use Starling / Feathers, and they work well, but it is visible that are not native apps. Even a transition between screens, depending on the device, it becomes ugly. Anyway, you are doing a great job, and I believe it will be better. His concern and direct communication with developers is encouraging. Shows that Adobe is worried about its developers and they are important. Thank you.

[makc3d]

novoasaoooo wrote:

many applications built in Adobe Air are not games, but rather tools

Adobe said they focus on games and video, which means issues related to other types of apps are not interesting to Adobe. I know it was years ago but I do not remember them ever retracting this statement.