A few days back I ran into a (at that time) weird problem where transparency was rendered black after a few frames. I had a hard time figuring out what was going on, and I just didn’t have a clue where to start looking. Google wasn’t really helping me out either. So I posted my problem on FlashFocus but nobody came up with the answer to my problem. Peter Elst asked Ralph Hauwert if he already had run into this problem. Mario Klingemann suggested that there might be a problem with the premultiplied alpha. At that time I didn’t know what premultiplied alpha was and seen as the problem resembled the example Mario gave, it seemed quite obvious he was right.

So I took peace with this, and decided to fall back to a non-transparent image format like JPEG. 2 days later Erwin Verdonk came up with the answer to the whole problem… I just had a hard time understanding it…

The root of the problem was me: I had totally forgotten that the draw() method of the BitmapData class didn’t clear the pixels before drawing… Yea, that’s emberassing, right?

But okay… That took care of some problems. I rewrote some of the code, and adjusted some settings.
The speed and the result are quite okay right now. However using 450MB and up of RAM usage might be a bit of a killer.
I’m wondering if I could take care of this using PNGencoder or perhaps JPGencoder.

But for now I’m happy… The final result (for now) can be seen here.

Thanks everybody for helping me out. You guys rock!

PS: The picture used in this experiment was taken by Thomas Heylen. Thanks Thomas!

Today I found some time to mess around with bitmapdata and computeSpectrum again. I’ve been playing with this earlier, but didn’t quite get where I wanted to be. A few weeks ago I came up with a better way of rendering the soundTunnel. That resulted in some crazy cool shit, which I finished off today.

I won’t go into technical details here (yet). I just wanted you guys to see the result.

Demo

Click here
And just to make sure it is actually reacting to the sound, try the following links too

• Song 1: Click
• Song 2: Click
• Song 3: Click (default)
  
• Song 4: Click
• Song 5: Click

Controls

• F: Go full screen
• S: Freeze visualization
• Click: Change color (happens automatically too)

Screenshots

Op MultiMania 2008 heb ik Group 94 gezien, en hebben ze enkele van hun projecten en trukjes blootgelegd. Een behind the scenes van het waarschijnlijk meest gerenomeerde webdesign- en multimedia bedrijf van België (volgens mijn bescheiden mening). Ze lieten onder andere de Nokia – Non Stop Living site zien; een site waar ik al langer van wist. Ik was altijd compleet onder de indruk van de effecten en transitions die deze site te bieden heeft.

Lange tijd heb ik me afgevraagd hoe alles in zijn werk gaat. Op een dag wou ik het weten en begon ik m’n hoofd te breken in Flash en Actionscript 3. Op MultiMania wist Julian (Group 94 member) te vertellen dat de ‘intro animatie’ on-the-fly opgebouwd werd (aan de hand van ActionScript). Ik vond dat best wel een gewaagde zaak, aangezien het toch veiliger was geweest als men die intro had gerenderd, en dan als video had gebruikt in het project.
Maar voor mij maakte dat opeens allemaal niet meer uit: Ik wou het ook voor elkaar krijgen.

Ik heb hiervoor verschillende keren moeten herbeginnen. Maar stap voor stap kwam ik dichterbij wat ik wou bereiken. Ik dacht eerst dat het grootste probleem het ‘in stukken knippen’ ging zijn. Maar dat bleek niet waar te zijn. Integendeel: Dat was zelfs erg makkelijk. Het werd pas moeilijk als ik de individuele onderdelen wou gaan animeren. 360 bitmaps bijna simultaan tweenen is niet bepaald processor vriendelijk, zo bleek.

Eens ik daar geraakt was, was ik al vrij tevreden: het uiteindelijke effect was er al. Nu alleen nog wat machinevriendelijker maken. Maar daar was het probleem. Ik bedacht mij of er geen mogelijkheid was om on-the-fly een sequentie aan beelden te maken. Al vlug gaf ik het idee op, en ben ik nooit aan de code begonnen. In mijn hoofd zag ik namelijk het RAM geheugen door het dak gaan.

Enkele weken later las ik op Keith Peters’ blog dat Julian van Group 94 het effectief op die manier had aangepakt. Ik moest het dus ook proberen op die manier… En wat bleek: Het werkte! (DUHH!)
Ik kreeg het voor elkaar om de animatie te pre-renderen en daarna te laten weergeven. Het resultaat was één smooth-as-fuck animatie. Enige probleem: het RAM geheugen leidde er (zoals ik had voorspeld) echt onder. 900-950MB voor de 380 frames van de animatie.

Ik heb er lang op gezocht, maar de sleutel tot succes bleek gewoon een wat kleinere bitmap te zijn. Door de afmetingen van de bitmaps deels aan te passen slaagde ik erin om 600MB af te knippen. Het resultaat gebruikte 250-300MB, een veel redelijker getal.

Ik ben al erg fier op het gehaalde resultaat. Hieronder kun je de verschillende fases van mijn vooruitgang zien. Ik was van plan om de bron hiervan vrij te geven, maar ik wil het nog even voor mezelf houden om zelf nog wat meer zaken uit te pluizen.

Basic versie: Twee.
Real time animation versie: Zeven.
Full blown prerendering (kan je browser crashen indien tekort aan geheugen): Acht.
Optimized prerendering: Negen.

De volgende stap is nu om te zien hoe Julian en zijn collega’s deze ronde wereld laten ‘openplooien’ tot rechte wereld…  Lijkt me allemaal nog net iets gecompliceerder te worden nu…

PS: als iemand een leukere panorama afbeelding te bieden heeft: aarzel niet om suggesties te posten. Ik ben de huidige zowat beu gezien