Skip to content

Massive 3D Particle System in Flash Molehill

July 18, 2011

Evolution of Molehill

I’ve been working on Molehill for more than a year now.

Since the very first iteration, to what we have now… wow there was a huge evolution.

  • Evolution (countless changes) in the API and features
  • Evolution in performances
  • And a lot of evolution in the community.
I have never seen such a great group of people working at the same time on a pre-release, in all possible application of the tech.
Still! When I look at the demos out there today, there is not much!
You can take a look at “The big list” by Lee Brimelow

An old thread

can you remember the debate about PixelBender vs pure AS3 vs haxe?
Let me help you remember! There was a nice attempt by a lot of people on the net to do a massive particle system with flash.
A lot of comparison have been done between different way by the “masters”, and to honor theses efforts, I tought I’de make something with Molehill out of this old thread.

PixelBender+Alchemy option (by Ralph Hauwert)
Pure AS3 option (by Joa Ebert)


Revamping an old post

It’s always fun to play with particle system when using a new tech.

Today I’m presenting to you one of the very first proof of concept I made with molehill, using a technique we developed at Frima Studio. (Already one year ago!)

So I went in my archive and fixed all the API changes that were made since then.

There was also an old blog post going with it that I never released due to the “to early stage” of molehill pre-release, and the technological advantage of open-sourcing such as technique.

But since then there was a lot of development… First the presentation at Adobe Max 2010 of the  ZombieTycoon trailer, Then The featured release of a couple of Zombie Tycoon levels, the  session at Flash Gaming Summit 2011 and the session for the San Flashisco user group. And internally at frima, the tech never stopped to grow!

We are going to present at Adobe Max 2011.  I’m sure it’s going to be awesome this year (again!).

The Particle System

This is a very simple particle system.
The particle position are defined using a classic “Strange attractor” algorithm.
Each particle is made with a quad and  is facing the camera (Billboard)


THE most important thing when doing a particle system is to have a good batching process.
Particles are often in very high numbers, and they must be drawable in batch to keep the performances high enough.

When we first started thinking about it, it was pretty obvious that to create something nice with billboards, we would have to transform each quad to make it face the screen (Transform by the Inverse ViewProjMatrix).  While this might sound obvious and simple to do, when processing the vertex in a vertex shader that process them one by one with no index or whatsoever defining what corners we are processing, it’s not “that” obvious!

The problem

The transformation needed on the four corners of your quad is not the same! but you can only define “one way” of doing things in your shader. (No if statement). Hence, if you can’t differentiate what you are processing, how can you make the good transformation to each vertex??

After a couple iteration where the CPU was doing the matrix transformation and re-uploaded each position each frame… We went in another direction. (It was WAY to heavy!)

The vertex shader let you define constant that you can access within the shader. Sadly, you have only 128 Float4 of theses.
So no real way of “batching” large amount of particles by making a list of transformation for each vertex. The best you could do is a couple of dynamic particle at the same time.

The trick

The thing you can do is mix between your vertex arguments (position, scale, uv, etc. defined for each single vertex ) and the Vertex shader constants (limited).
In your vertex arguments, you can define an ID for each corner of a quad: 1,2,3,4.
Then, assign the exact same 3D position (center of the quad) to all 4 vertex.
By setting only one position (4 time the same position) it means that it require the exact same transformation for all corners of your quad. (yeah!) But then, you have to be able to “re-construct” your quad inside the shader

In the Constants, you define an offset.xy from the center to each of the corners.
And then, when processing the vertex in the shader, it can read the ID of the current vertex, which can then be use to access the offset matching the current vertex in the constants.

You can now recover your quad by offsetting the center of each vertex (Yeah #2!)

So the final algorithm is:


position = argument[0].xyz // Center of the quad
id = argument[0].w //ID=1 | 2 | 3 | 4
Offset = Constants[id]
transform the Offset of the current corner by the Inverse ViewProj Matrix //billboard
Add the result to the vertex position
transform finalPosition by the ViewProj Matrix  //Show on screen

SpriteSheet Manipulation

The technique used here is to modify the UV of each particles in a bytearray, and send it back to the Video Card.

for each(particle in particleList)
	Set Vertex1.uv = particle.nextframe()
	Set Vertex2.uv = particle.nextframe()
	Set Vertex3.uv = particle.nextframe()
	Set Vertex4.uv = particle.nextframe()

The same result could be achieved using a full GPU particle system. with the UV changing over time using an offset in function of time.

But to represent a system where each particle would move independently with physics for example, it was best to re-upload the whole thing.

the texture is a space-core SpriteSheet (sphere with rotating rings around)

The format original was a PNG with transparency
I decided to split that up in two, and compress them with the ATF file format.

SpaceCore Diffuse

As you can see, the background is black.
To be able to use transparency, I made a alpha mask for it:
SpaceCore Mask

I could have used the original png, and kill transparent pixels.
But to do that I need a texture with 4 channels (RGBA). Which means that I cannot use ATF texture compression.
After benchmarking it, doing a sampling in two ATF is faster than doing only one in a uncompressed bitmap.
Hence I went with the compression (and of course, not only it’s faster, but smaller in video memory)
One of the goal of this demo was to determine what was the balance between process on the CPU and GPU.

Final result

Don’t forget to use the latest Flash Player 11 Incubator build
Particle System

If you think of better/other ways to do the same thing, please comments in here! Sharing is good 🙂


I know you guys are hungry for some code!

The whole thing is here


 As I was saying. This demo is now one year old and frima as pushed the limits of Molehill non-stop since it was first pre-released.

Just imagine what we are able to do right now, and how this is going to change the face of the gaming industry!


Yup! I am about to release a new version of FlashPreloadProfiler. It’s now very complete and I will be proud to release it in a couple of days! I hope you will stay tuned!

From → general

  1. The fact that Molehill is still in pre-release is my main gripe. With WebGL available in most modern browsers(Except IE), the delay of Molehill’s public release is way too late.(still don’t see a release date)

    • I suggest not to be too scared with this.
      Adobe is putting a lot of efforts on this tech.
      I’m sure it will be soon enough!

  2. is this same idea like
    don’t get me wrong, i just want to discuss pros and cons for both way.
    and thanks for sharing about transparent trick, curios that can we use 24-bit for masking there?

    btw, my client still use IE, so MoleHill win anyway 🙂

    • Very good question. I’ll have to check it out! Thanks for the link.

  3. Absolutely wonderful! I’ve been sturrgling with the technique to face all quads to the camera billboard style while still being able to use hardware batching and all animations in gpu only. Such amazing work. Thank you. You rock!

    P.S. I am VERY interested in the new profiler. Keep up the great work.

  4. Nice post. Unfortunately due to the lack of Vertex Texture Fetch in Molehill compared to WebGL you cant get a truly GPU only particle simulation such as:

    I may have a go at recreating this in WebGL soon.

    • There are limitation, I agree.
      And it would be pretty awesome.

      But if you take a look at the big picture, there are a lot more limitation in using WebGL 😛

  5. valyard2 permalink

    Can’t you just pass vertex normals to vertex shaders in flash?

    • In a Vertex argument, yes.
      As I was saying, this demo is pretty old 😉
      But yes, you can send the normal in the Args, and the use it instead of using a constant.

      The difference is that you add a FLOAT3 for each vertex, which multiplied by 65K Vertex will add a LOT of weight to the thing. The video memory bandwidth could get a lot more cache_miss
      I might benchmark the two… could be interesting to try it again now that the API as eveloved a lot;)

  6. Manuel permalink

    Hi Jean-Philippe,

    Thanks for this useful article.
    I’m looking for a way to generate an ATF texture. Do you know how i could do this please ?


  7. Intriguing site, i read it but i still have a
    few questions. shoot me an e-mail and we will talk a lot more becasue i could have
    an intriguing concept for you.

  8. I’m genuinely loving the theme/design of your web website. Do you ever run into any browser compatibility troubles? A few of my weblog readers have complained about my internet site not working appropriately in Explorer but looks wonderful in Chrome. Do you’ve
    any guidelines to assist fix this problem?

  9. With havin so much content and articles do you ever run into any issues of plagorism or copyright infringement?
    My website has a lot of unique content I’ve either written myself or outsourced but it seems a lot of it is popping it up all over the internet without my agreement. Do you know any techniques to help reduce content from being stolen? I’d really appreciate it.

Trackbacks & Pingbacks

  1. Introducing open source evoSpicyParticleEngine «
  2. Furious Furball – MoleHill/Stage3D experiment with Source | RossKettle.Net
  3. Fun with swarm intelligence – Iteration 6 | wtfdji

Comments are closed.

%d bloggers like this: