And back up!
Small news. I've decided to keep the blog up since it might be a good reference for some as3 topics. I was convinced of this when I realized that I sometimes use my own blog as a reference. It's handy. So yes, it shall be up here and I will try to post anything that I consider might be useful or interesting.
Lidev shutting down
Several months ago a friend told me: "Hey, you're doing some pretty cool stuff with Flash... Why don't you open up a blog?" To be honest, I didn't even have a clear idea of what a blog was at the time, but I followed his advice and created lidev. At first I was amazed that people were actually coming here, reading my posts, and even providing me with feedback that would catalyze the playground or even hook me up with other "flashers" and/or open new paths of research.
After some time of zero activity here, I believe that the cycle has come to an end now. Not sure why, I just feel it. Perhaps its time to break the routine a bit and focus on new paths of learning, and start thinking about new projects, more concrete, more specific. Lidev has been a wonderful place for me to get a grasp on how information can be shared between us and how a very vast net of knowledge can be sustained in such a way. Beyond that, it's cycle has closed.
Before the shut down, I wanted to thank anyone who has visited lidev, had fun with it, interacted and helped me grow and learn. A big thank you also to all the other bloggers out there who put up exquisite posts about Flash and programming in general. And of course, a big hurray to open source development and sharing of experiments, source and geeky Flash knowledge!
Li
Faster Voronoi Noise
On my last post about this topic I was using a very inefficient triangle filling method; for each triangle joining the center of a Voronoi cell with one of its boundary segments, I was performing a per-pixel distance check and, depending on such distance, the amount of white for the analyzed pixel was determined.
I realized that, since the distance was being checked linearly, a gradient fill would actually do the trick. It works, and a lot faster. Also, since this runs with gradient fills, the method can generate a very large variety of different "Voronoi noises", try playing around with the source and you'll see.
This demo uses Alan Shaw's AS3Delaunay library. It runs just as fast as the one I used previously (Controul's) which is amazingly fast for pure AS3, but it is actually much more comfortable to use. Controul's Voronoi class is kind of encrypted because of all the optimizations it has, and returns only the Voronoi segments data. Shaw's Voronoi class can be asked for just about anything, from Voronoi segments to Delaunay triangles, spanning tree, nearest neighbors, etc. Thanks for this Alan!
I wonder if using drawTriangles() or bitmap fills could make this even faster. Any suggestions would be highly appreciated!
Basic Fractal Tree
Another obsolete experiment! Click on the image to view it (view source enabled).
The concept is simple: alternate squares and triangles to produce a fractal tree-like structure. On each step, either triangles or squares are drawn in the edges of the last set of drawn elements. If the last set was triangles, squares are drawn and vice versa. Two squares can sprout from a triangle and a single triangle can sprout from a square, hence, triangles are the cause for bifurcations. That's it! Pretty simple, yet beautiful; the simple rules produce some very complex variations. I hope it is inspiring to produce more complex fractal beings.
Play around with the parameters:
[growthRate: Time in ms between the creation of each step] [maxSteps: The number of recursive iterations. Be careful not to go above 25! It could crash your browser] [Triangle base factor: From 0 to 1, controls the inclination of the triangles. 0.5 makes the tip of the triangle be above the mid point of the base] [Triangle height factor: Relationship of the height of tris to their base] [Square height factor: Relationship of the height of squares to their base].
Voronoi Collisions?
So, it's Saturday night, my flat mates are all heading out to cool party 'A' and cool party 'B'. Unfortunately, I have to stay indoors in quarantine since I was blessed with a flu last Thursday. Damn it! I hate it when I fall Ill just before the weekend. It's so unfair!
Anyway, I needed something to do and I think I watched practically every single new film in megavideo, so I decided to have another play with our friend Voronoi. The experiment revolves around the following question: If voronoi diagrams provide so much information about the spacial distribution of a set of points in space, couldn't this information be used to detect collisions between circles?
Apparently the experiment above says 'yes' (click on the image to run it - view source is enabled). What you would normally do to have a bunch of circles collide with each other is, on each frame, evaluate the distance of each circle to all others in some sort of nested loop. If the distance is smaller than the sum of the radii of the 2 circles being compared, you have a collision. I think that everyone involved in programming with at least a small affinity with physics has had a go at this. Even though the collision check is very simple, the amount of distance calculations is brutal. 'n' circles means 'n' to the power of 2 collision checks per frame. Of course, there are optimizations as dividing the space in a grid and only checking for collisions in the current cell and neighboring cells, which can reduce the calculations a lot.
So even though the experiment looks like what we've all seen (and/or done) 1000 times, the implementation is completely different, at least for me. On each frame the position of the circles is used to construct a Voronoi diagram. This produces a set of line segments attributed to each Voronoi focus point (which are the centers of the circles). If you compare the distance of such point to its related Voronoi edges in the Voronoi cell, with the radius of the circle, you can detect when the circle is colliding with something. If you do have a collision, you can use the vector involved in the collision check to exert a force on the circle, so once you know that something is colliding, there's no need to do any complex calculations to resolve the collision; the voronoi diagram also provides the info for you to resolve it!
I'm sure that the physics in the demo is not exactly right, and that the code could run much faster if optimized (its just an experiment after all, a proof of concept). I didn't worry much about physics correctness or using inlining or any other Flash Player optimization techniques, I preferred to keep the code clear and simple to understand. Currently its resolving collisions for 250 circles and it runs ok. I wonder how many circles it could manage if optimized, and if it would be faster than the more commonly known approaches. I have a feeling that this could be some sort of BSP collision detection system.
Uses of this? None, absolutely NONE what so ever!! Perhaps only providing a visual programmer some time to be entertained while on quarantine Saturday night :s
Voronoi Noise
Click on the image to see the demo, right click view source enabled.
'Morley noise' or 'cell noise' can be produced by laying out a random set of points and then coloring each pixel according to the distance to the CLOSEST of the layed out points. This can involve a pretty serious amount of calculation since for each pixel, distances have to be calculated to all the points in order to use the smallest distance to obtain the color value. To speed things up, the points are usually layed out in cells so that a pixel only needs to be checked against the point in the cell and neighboring cells. This reduces calculations. There's a good explanation of this HERE.
What I've done is an attempt to be even quicker. I'm using Hrito's amazingly fast implemantation of a fortune's algorithm ported from c, that finds the Voronoi edges of a random distribution of points. I altered his code a bit so that it can output triangles also. I defined these triangles as a vorono edge joined to the focus points of its neighboring cells. With this, the experiment sweeps the triangles and fills 'em up. Each pixel already knows what point to calculate its distance to, hence reducing the calculations even further. The code has some graphical glitches and is only for demonstration purposes so I can assure that it can be made way faster and better.
Uses of this? I think a LOT. Besides what has been discussed above, this sort of algorithms could be used to obtain very fast Delaunay Triangulations, which can be used for a milliard of things in 3D; they provide an optimal triangulation method for a given set of points. I'm, eager to experiment in these.
Wishlist
I've created a little poll in order to see how you guys think development on the textfields branch should be prioritized. You should see it at the bottom of the right sidebar. I'd appreciate your votes and suggestions!
Note: If you think of something that doesn't show up in the poll, please comment it in this post.
Chaos Presentation
Im setting this up tomorrow in the Tecnoescena 08 Art Festival in Buenos Aires. Im expeting to see really cool things there. Check the site out at: www.tecnoescena.com.
I couldn't go without this little WiiMote-flash demo I made with my friends Alejandra Banfi and Pablo Dompe (click on the image to view it -space for fullscreen mode and click to change animation-). Its extremely simple really, the beauty of it is on how complex imagery can be formed by very basic drawing rules. Being able to control the animations with the WiiMote adds a little more fun to it...
HOW? Its just the Graphics API drawing curves responding to some recursive 2D objects. A redraw method is also being called constantly to release the Graphics cache and copy its latest product into an image in the background. The main branch of an animation follows the mouse cursor and the smaller ramifications and subramifications move around in an angular, randomized fashion.
Tweaking just a few parameters produces endless variations!!
Blog!
So, I finally decided to open a blog. The idea behind it is pretty simple: As a web developer specialized in Actionscript, I want to have a place to show my work, and also share, discuss and spread anything interesting regarding Actionscript development.



