PDA

View Full Version : Demo competition right here on ActionScript.org!


Amn
04-22-2009, 05:19 PM
Folks, I have a proposal for a competition. All who want can participate.

The competition is to create a small SWF demo. Preferrable language is ActionScript 3, although it is interesting to know that someone uses something else than ActionScript to generate the SWF. However a strict requirement is that the SWF version is at least 9, i.e. running under the AVM2 (if you do not know what AVM2 means, you probably should not take part, however you are very welcome to be an observer). Otherwise it would be difficult to compare different virtual machines in action doing the same demo.

The demo is very strictly defined:

Visually simulate a 2-dimensional field of initially randomly positioned disc-shaped particles of equal diameter of 10 pixels with initially random speeds of up to 200px/second, colliding elastically with each other. They must be confined within a 800x600(px) sized frame, i.e. they must bounce off its edges. They must also bounce off each other the way elastic collisions between equal-size disc shaped 'particles' are implemented, i.e. according to a) law of conservation of linear momentum b) law of conservation of kinetic energy and c) naturally, upon collision, normal forces are perpendicular to the surface of collision. This is your classical and MUCH simplified pool table ball mechanics. The theory of elastic collision is available on Internet, and is explained throughly for us to apply. We would use the http://en.wikipedia.org/wiki/Elastic_collision as reference description and guideline. How you implement it and how you trade in accuracy for speed etc is part of the point of your contribution. Think of the wikipedia article as an ActionScript interface - the implementation is yours as long as it 'implements' the interface ;-)

The animation must be realtime, although naturally the Flash Player will only give us so much framerate. So, what I mean is that particles are animated by real time, no matter framerate. i.e. some sort of distance = particle_speed * (getTimer() - t0). If you change the framerate, they will still move as fast as they would otherwise, just not redrawn as frequently. If you do not understand, ask me and I will try to explain.

So, to sum up:

Strict requirements, must be honored:

1. A field of n particles,
2. Initially randomly positioned within the 800x600 frame
3. Initially random constant velocity vector of up to 200px/second
4. Disc-shaped, 10px in diameter
5. Moving in 2 dimensions
6. Bouncing off the 800x600 frame
7. Bouncing each other on collision as outlined in http://en.wikipedia.org/wiki/Elastic_collision
8, You have to have an account on this forum

Also remember, that certain approximations of simulation is unavoidable, f.e. sometimes particles will get 'entangled' together when they collide INTO each other, as opposed to colliding WITH each other. If you cannot solve it, don't. If your particles overlap, make a choice. We want your contribution for visual treat of it, we do not want you having a weekend long headache and your girlfriend/boyfriend leaving you for someone who spends less time reading on molecular dynamics simulation. Remember, even REALLY BAD simulation will do as long as the points above are honored, except #7 which can be really hard to do, so just be creative and dont break your head trying, but try nevertheless - after all elastic collision is part of the visual treat here.

Stuff you can do as you please:

1. Color of particles and the rest, obviously, if you want. If it slows your demo down, tough luck, read on judges' priority below :-)
2. You choose (obviously) the mathematical precision of your demo, if you want to trade in precision for speed, you may do so, but it will be taken into consideration by the judges, especially if it affects visual quality (more on judging below).
3. You can add stuff BEYOND the strict requirements, if you feel you are too cool for school and have the competition already in your pocket. Feel free to add flying text, sound effects, logos and all that jazz, as long as you are aware of the priority the judges will have :-)
4. You do not have to submit ANYTHING but the SWF. Your tools of choice, language choice and the source code itself will not be asked for during the run of the competion. You can play the mystery game and as long as you produce and provide the SWF, how you made it is your secret. Just make sure it is you who made it ;-)
5. Framerate :-) Since this is realtime, framerate may or may not help you the way you thought it would, because we will be judging speed of your realtime animation (read above).
6. You may demand Flash Player 10, instead of 9, if your demo has to use the 10's features.

We have to choose a good judge or two here and now. Preferrably someone with relevant qualities. Obviously judges cannot participate in the competition. Just reply if you feel like judging.

Judges will have to judge the following, in descending priority:

1. Amount of particles present
2. REAL frames per second (Flash Player WILL slow down if it cannot calculate fast enough, so you will not be able to cheat this one) - how smooth it is
3. Visual perception of accuracy of simulation of collision detection and consequences. You may use 'int' types if it helps your speed, but if it all gets weird artifacts, judges will not ignore this.
4. The visual and artistic factor - colors, eye-candy etc. This is least priority, so spending too much time on this obviously will have be futile?

Judges must only judge on the basis of SWF displayed in the Flash Player. Obviously the same test platform has to apply for all contestants. I have not decided on the rating system yet.

I personally will contribute / give out a meaningful prize. And before all skeptics here take a long hard look at me, let me say I WILL participate myself, and I do not need this for a) School assignment (school is long over for my part) b) Client expecting implementation. THIS IS ALL JUST FOR FUN!

We have to agree on prize, and I am funding it from own pocket up to 20$, which I guess is a price of a DVD or Audio CD. Hey, "Blade Runner: The Final Cut" on Blu-ray for little over $15 :-) If we add up our coins, it can certainly be more, but let us keep the fun part. This is not about winning a MacBook Pro :-)

Judgement Day on Thu, April 30 8pm GMT. Good time, or?

1st and 2nd place only. 2nd place - no prize, at least not from my shallow pocket, but feel free to make a pot, preferrably smaller than the pot for 1st place :-) When winners are announced, they are encouraged to provide the cool details of implementation, the source code and list their tools of trade. Which is part of the point of doing this on public forums where people ask and answer questions.

Umm, I don't know if I missed anything but I can edit this later/add stuff.

If this can be made Sticky, I guess why not?

Does this fly? :D

Amn
04-22-2009, 05:25 PM
I will freeze the original post when we have settled on the rules so that we have strict requirements that do not change and people don't have to look up in fear of unannounced changes after they have taken on the challenge.

Thankyous will be exchanged later ;-)

ASWC
04-22-2009, 05:34 PM
This should probably be on another forum.

Amn
04-22-2009, 05:44 PM
This should probably be on another forum.

Skeptic, huh. Which one would you suggest? I went to GREAT length outlining what the nature of the demo is, along with motivation at some point, and why I think it is a good idea. Naturally, always someone who disagrees, but I cannot think of a better place, maybe also because I have been here for more than 5 years. Also, did you read the post or just the title and first paragraph?

Cheers.

ASWC
04-22-2009, 05:46 PM
I don't think I judged in any ways your post. There's the general forum and the quick challenges forum that would fit better this kind of post. Typically on the AS3 forum people ask or answer questions.

Amn
04-22-2009, 06:05 PM
Typically on the AS3 forum people ask or answer questions.

True, I guess, but then again, AS3 forum is for AS3 specific stuff, and this certainly qualifies. Also this forum gets more exposure from the people who not necessarily visit to absolutely ask or answer questions. My own habit is to visit this place to see the general development of ActionScript 3 and its associated troubles, hurdles and achievements. I have not been in a General Discussion for as long as I can remember...

I leave this one up for moderators to decide.

CyanBlue
04-22-2009, 07:45 PM
It's true that AS2 & AS3 forums are the ones which have the most traffic in this forum, but each sub forums are created our desire to make this site more informative to general public... Why create sub forums if nobody uses those, right? Besides, those who participates in the forum regularily visits most of the sub forums and check out the new threads that interests them... ;)

I think this topic is an awesome subject and hope to see some great discussion going... I am moving this thread to Just for Kicks Challenges forum... I'll remove these unnecessary replies later on... Thanks...

Xegnma
05-01-2009, 12:52 AM
@Amn: You've just outlined a common computer graphics and animation problem. Here's a link to a paper on particle field simulations. The first couple of sections cover an often used technique to solve the problem:
Algorithms for Particle-Field Simulations with Collisions (http://www.cs.uwaterloo.ca/~jwlwan/papers/SigETAL01.pdf)

Plus here is an implementation in Java done by one of my former professors:
Bouncy Ballz Applet (http://theparticle.com/applets/swarm/BouncyBalls/index.html).
Source is provided as java classes at the bottom.

Should be a good starting point for folks interested in the challenge.

(P.S. This has been done several times in AS2, so show a little respect for elderly languages ;) )

Amn
05-01-2009, 09:49 AM
1. I KNOW I outlined a common problem, I am occupied with graphics programs since I used masm and tasm assemblers in 1993. This is just for fun, and particles are fun to watch.

2. I know the common algorithms for particle simulations, including the event queue and field subdivision. Your paper is easy to read however, I am keeping it, thanks ;-)

3. Part of the point is doing it in AVM2, because it gives more performance and this is about visual display. Also AS3/AVM2 is what is used these days, so why not keep it modern?

4. The Java demo is nowhere near as fast as what I can already display with UNOPTIMIZED AVM2 already. But this will remain my secret until (if ever) we bring this to a close. Point here is, one thing is reading papers and writing by-the-book code, another thing is implementing it wisely and optimizing it from there on.

So far we have only skeptics here, although you do bring about some valid points and opinions of course. But you have to understand that I had made some extensive preparations for this thread, and not just written it out in a hurry, so most of the stuff you mention have already crossed my mind three times. This includes the choice of the algorithm, the wealth of papers on the subject including Wikipedia's pages, and choice of language syntax (your choice!) and Flash Player 9+ and AVM2 as platform.

Point of this competition is not to just learn people how particles collide and how to do it fast, but to apply this knowledge in a workable SWF, and to let them try and approach the limits of Flash Player by tweaking out their code. Also, one thing is reading papers on algorithms, a whole another thing is implementing them in real programs.

If you are as knowledgeable as you honestly seem, why don't you participate? :-) After all with that paper in hand, things should go smooth for you. It can be fun, besides I am guessing its like 5-6 hours of work for you. Well, you decide yourself of course...

P.S. ActionScript 2.0 is not really a language. Well, it syntactically is, but it is more like two thirds of a language. It has half a compiler, other than that it is like every other language. The real language and compiler that did all the work for Adobe until ActionScript 3.0 came out was version 1.

Amn
05-01-2009, 09:53 AM
And thanks for the links of course, regardless.

I guess it is pointless to say that we cannot use others' source code, because obviously Internet is a resource here, and people will find all kinds of readable source code anyway. So, copy-pasting is fine too, but I doubt readable code brings about most speed :-)

newblack
05-03-2009, 04:58 AM
don't really care about the competition, especially with my (non) graphics, but it was fun!

a few unique things about what i did:

continuous collision detection for particles and walls (no speed threshold)
pretty strictly enforced non-penetration constraint
simple broad/coarse-phase collision detection
can parametrize radius/mass
walls don't have to be aligned with x/y-axes
source code! (http://lab.generalrelativity.org/ccd/ElasticCollisionDemo.as)


the large particles help show that there's no penetration (that's what she said)

slow (52 particles):
http://lab.generalrelativity.org/ccd/50_slow

faster (32 particles)
http://lab.generalrelativity.org/ccd/30_fast

super fast (17 particles)
http://lab.generalrelativity.org/ccd/15_ridiculous

non rect (52 particles)
http://lab.generalrelativity.org/ccd/50_nonrect

and the source:
http://lab.generalrelativity.org/ccd/ElasticCollisionDemo.as

Amn
05-03-2009, 10:27 AM
Thank you for you contribution! If these keep coming, we might have a competition after all!
Good demos, and smooth too :-)

C'mon folks, jump on the wagon. At this point there is no definite deadline, hehehe...

Amn
05-03-2009, 10:28 AM
source code! (http://lab.generalrelativity.org/ccd/ElasticCollisionDemo.as)


Penetration or no penetration, you might wanna withhold the source code until much later :-)

newblack
05-03-2009, 02:39 PM
Penetration or no penetration, you might wanna withhold the source code until much later :-)
why? looking at this time line, i doubt anyone else will "enter." i only did because i was sick on a saturday night (well, i'm physics obsessed too...). besides, it has the potential to help someone! that's why i tried to comment the code fairly well.

and i want to see what you've come up with! post it!

Amn
05-03-2009, 03:00 PM
Well, anyone can learn from your source, and people can use it as a template for their own contributions, which, if no other effect, may just warrant for exactly the same algorithm used in every one.

Personally, I think your source looks beautiful. I can also spot a collision even queue. There is room for optimization, but you yourself said you do not care for the competition, which I find kind of strange, given you did submit your demo.

I will post my version 1 very soon, although it still has several classes of bugs. I reinstalled my Ubuntu five days ago, and have not set up my compiler platform yet again. Well, now I did, but it says it can't find "flash.display.Sprite" class :) When I fix that and set it all up I will post the SWF.

newblack
05-03-2009, 04:05 PM
There is room for optimization, but you yourself said you do not care for the competition, which I find kind of strange, given you did submit your demo.
it was fun to do, that's all. and it was the problem, not the competition, that made it fun.

there's definitely a lot of optimizations that could be made, like caching collision pairs, resolving multiple close-to-simultaneous collisions per step, etc. but that's the sort of intuition-based logic that's difficult to follow in code, i think, and i wanted something that was easy to decipher.

good luck getting your ornery compiler running!

Amn
05-09-2009, 06:56 PM
Finally fixed haXe compiler problem, or rather MY problem - I had old version installed, which did not compile my Flash Player 10 SWFs.

Here is a fast mockup, far from complete, and with some minor bugs, but posting this to maybe inspire competition or something, although I am by no means proud of my achievement (yet) :-)

Probably Flash Player 10, but maybe 9, did not sweep for weird undocumented functions yet :-)

Cap 25fps, 500 particles, 800x600. When two particles collide into eachother, they become engangled and no other particles may bounce off these two until these
'untangle'. This is one of the major drawbacks to this demo. Later will put in an event queue, which will solve this and other potential problems.

Amn
05-14-2009, 11:33 AM
Well, I don't know if there is any life in this competition, but I quadrupled the speed of the demo. 2000 particles, 25 frames per second SWF framerate cap so you will not get animation faster than this speed, but your computer may be capable of much more. If you see very smooth animation, you are probably limited by the SWF framerate...

Still the same drawbacks of lack of event queue, so particles fly into each other and tangle up.