A few days ago, our latest Away Media work  was made public. This time it's www.mydreamdevice.com, a website where you can arrange existing 3D models into all kinds of creations. The site is a simple but fun way to promote Qualcomm's Smartbook computer: you can create your dream device with components that all exist miniaturized in the Smartbook. Right after the site became live, people started to effectively use the tools we provided, but not precisely in the way we had in mind. But hey, I have to admit that I couldn't stop laughing after seeing some of the obscenities that were created! Too bad there has to be a moderator :-/

Our main focus was to make the manipulation of 3D elements as simple as possible and as least "techy" as possible. It's pretty amazing how hard this is to do once you get involved with the task: you need to manipulate things in 3D with a 2D interface BUT you can't introduce abstract concepts, a complex interface, just 3 or 4 buttons! It was quite a challenge, but I think we did a reasonable job. While doing this I studied a lot of 3D interfaces in different softwares. They vary a lot and are usually very effective but they all require you to "learn" how to use the rather complex controls. None seem to have what we tried to accomplish here: A set of controls that you don't need time to adapt to, just a few clicks and tests and you're ready to go after a few seconds. In real life, you don't need to know about X, Y, Z in order to manipulate objects, so why would you need to be familiar with 3D tools in order to effectively drag things around in virtual 3D. I must admit though that the only way I see to do this perfectly is to actually have a 3D interface, but I guess that won't happen for a while. Anyway, there is a lot behind the apparent simplicity of the results and the topic of natural, simple interfaces for 3D editing is very interesting.

Another nice thing that we dealt with in the project is OBB collisions and collision response. I wrote about how to detect OBB collisions before, but not about how to resolve them. The challenge here was to make the colliding objects respond physically, without having the user loose control of what's in his grasp, which is the typical response a real physics engine would cause. In the end, the physics are so simple that its nice not to have to use a full 3D physics engine.

It has been very nice to work with such level of designers from Cocomino (www.cocomino.com). I really hope we create more cool stuff with them!

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

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!

Click on image to view the demo (view source enabled).

Its just a basic implementation of the method of separating axes for 3D OBB's (oriented bounding boxes). It detects collisions between cubes in a way that is slightly more advanced than spherical collisions, which are merely based on distances and radii. Collisions are not resolved in the demo though, only detected.

The point of the experiment is to show that it isn't hard at all to detect collisions between 3D objects if considering only their bounding boxes for their 'physical volume' is enough; if we just need to detect if objects are colliding or not, we don't actually need to bring in a heavy, cpu thirsty, 3D physics engine.

The code is not optimized (in fact quite the contrary so that its easy to read), but it runs quite smoothly with 15 cubes, where each cube is checked with all others for collision. If, for example, a character needed to be checked for collisions against static objects in a 3D scene, we would just need to compare his bounding box with the scene's static bounding boxes, so a large number of physically active objects could be used to describe a pretty complex scene. Furthermore, if any of these boxes were axis aligned, they are no longer OBB's, but rather AABB's (axis aligned bounding boxes) and collision checks could be made much faster. Something like this I imagine:

return (obj1MinX < obj2MaxX) && (obj1MaxX > obj2MinX) &&
(obj1MinY < obj2MaxY) && (obj1MaxY > obj2MinY) &&
(obj1MinZ < obj2MaxZ) && (obj1MaxZ > obj2MinZ);

The experiment is clarifying in understanding how the method of separating axis works, and I guess it gave me a quick glimpse at how a advanced physics engines like JigLibFlash might work. The code is heavily commented, so have a look if you're interested in understanding OBB collisions.

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].

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

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.

[UPDATE] You can find a couple of demos for this in THIS post in the Away3D site.

One of the things I've been wanting for Away3D for a while is the ability to warp a textfield onto a bezier path and animate the text along the path. The proper way of doing this is not just to position and rotate the characters to fit the path, but to actually deform them to adapt to the path. To do this, the x dimension of the text is transformed into an arc-length parameterized value along the path's length and the other 2 dimensions are then recalculated in this new space.

When it comes to a feature like this its usually much harder for me to develop, but this time I must admit it was pretty simple thanks to THIS amazing almost cheat-like resource from Jay Clegg.

Click on the image to see the demo (use the keyboard and mouse to move around). I plan to refine this and upload a full demo/example soon. For now, If you wish to play with it, take a look at the new "AlignToPath.as" class in the geom package of Away3D for fp10.

So Jason asked me if I could think of ways to improve his site, and that's how all this audio research started. The first thing that came to my mind was having the ability to slow down the playback of his videos, maintaining the audio's frequency characteristics as much as possible, i.e. trying to maintain the audio's pitch. Slowing down the videos is great for understanding what's going on in the playing, and even to play on top of the videos, but if the pitch changes in the process, playing over it sounds simply awful, and becomes impossible... Hence, audio time-stretching would be ideal here. We are planning to produce a pretty advanced online application for the site with this feature amongst many others that will hopefully enhance the music learning experience.

What is relevant in all this to the Flash side of things, is that I am producing a media player engine which I'm calling 'WarpPlayer'. This engine should hold the core functionality of the application we are building with Jason. The player should be able to handle multimedia in an advanced manner: use dynamic audio, mix several audio tracks, be able to time-stretch audio, and sync the playback to multiple flv's or f4v's in Flash. An application based on WarpPlayer could hence play video in slow motion and time-stretch its audio, much like the way Quicktime does this with its A/V controls.

Here is a demo of the first capabilities of WarpPlayer: DEMO.

The player needs to pre-load all its assets for now (multiple sound tracks and multiple videos) before it can actually start playing, so please be patient. However, my next goal is to make it be able to start playback as soon as a small portion of its assets have been loaded.

Try playing with the small audio mixer in the left, switching video views, or the tempo controller to the right of the player.

Anyone interested in WarpPlayer becoming open-source, please leave a comment below!