Flex / Spark Organization Chart (v2)

Rebuilt from scratch

Due to the popularity of the original organization chart (post can be found below) and the demand for it, I’ve rebuilt the component and made it available as open source.
Not that I love creating hierarchical data charts (though I must admit, it is fun), but the previous version was not ready to be openly released.

It didn’t follow Flex standards, the datasource had to be an XML file, etc… Not that the component is no good, it was just too specifically designed for the client back then.

In short, here’s the new version, and it boasts quite a few good features :
- Full Spark component architecture, meaning everything you see can be spark-skinned.
- Support for massive amouts of nodes
- Data can be any IList, in the demo it is an ArrayCollection. As with any Flex/Spark component, direct changes to the dataProvider collection result in the component updating itself, and vice-versa.

Layout calculations through Alchemy

Besides building it on Spark, the other new feature is that it crunches most calculations using Alchemy.

The layout is done with Alchemy, using a recursive function, which calculates every x and y position of each node.
Afterwards, another Alchemy function will return only those nodes that need to be rendered.

For example, you have a dataprovider of 1000 nodes, Alchemy will position each node, resulting in a viewpane of 10000×1000 pixels for example, yet the component itself in the Flash player is only 400×400 in size. For that 400×400 rectangle, Alchemy will return which nodes fit into that pane.
As a result, the player will never render all 1000 items, yet only those viewable.
As you scroll, the rendererd nodes will be recycled as Alchemy returns different nodes as you scroll.

To gain as much speed as possible, Alchemy function calls are kept to a minimum, and changes to the dataProvider are transferred directly into Alchemy memory.
When done calculating, the component in its turn will read all data from Alchemy by reading directly from the Alchemy memory ByteArray.

Design freedom

As noted above, the whole component can be skinned as you would any other Spark component.
Now 3 states are supported, minimized-normal-maximized.
In the demo, the maximized state implements an Image component and a DataGrid component.
The line connectors between 2 nodes can also be altered with the skin, where you can specify if lines should enter or exit from top, bottom, left or right of the node.

Bottleneck?

Even though I’m happy with the result, since you have to keep in mind that the whole chart starts out with all nodes expanded, the current bottleneck appears to be the rendering of many nodes on screen at once. The current skin does use a lot of gradients, but I’ll try to make it go smoother over time…

*** update *** I upped a version boasting 10000 items, which might criple performance on lower end computers.

Click on the image below or here to go to the style explorer.
If you are looking for the source, I’ve placed it at google code.

It’d be appreciated if you post your performance experience, I’ve set the item count on 5000 for the moment, which should make it run reasonably adequate on most computers.

XMas in summer

How do you render a 3D Christmas tree in Flash?

Papervision is an option, but don’t expect the 3D tree model to look realistic…
This project has a mini, custom-built 3D tree renderer.
It rotates particles around a 3D cone shape, replace those particles with random Bitmap objects of branches, rotate and colorize them randomly, and you get a decent 3D tree feeling.

This build uses 1600 particles, some are dynamic, an they represent pictures which people can upload, sphered within xmas balls.

Click the image to view the 3D tree.
note that the webservice which loads the uploaded xmas balls is currently unavailable, so only the non-decorated tree is shown.

The Sims 1 graphics in Flash : IFF to AS3 Sprites

Sims 1 BBQ

See also the ever excellent wikipedia entry on Interchange File Format.
Source here, but unfinished, and as mentioned above, very VERY old! But maybe still useful for someone… (used it to learn AS3 coming from AS2 back then)

Astar pathfinder with Pixel Bender and Alchemy

draw a maze with the mouse

The biggest limitation was that everything is always grid-based. You would simple flag certain nodes in the grid as walkable and not walkable and then calculate the best path.

Why Pixel Bender for a path finder?
My initial goal was to have the astar pathfinder run on a pure black and white bitmap data object. This way a designer could simply place complex objects on a map and a developer could easily transform the map to a black and white collision map.
The next step of course would be to have Flash analyse this bitmap and create a grid for pathfinding accordingly.
Using getPixel in a loop would be very slow, especially in very large bitmaps, so Pixel Bender was obviously used here.
A cool bonus is that Pixel Bender also runs asynchronously in a seperate thread from Flash.

How does Pixel Bender create the grid?
The Pixel Bender kernel script takes 2 parameters, one being the black and white bitmap obviously, the other being a node distance value. This node distance is the effective distance between 2 individual nodes in the grid. For example: a bitmap of 600 pixels width would output 30 columns in the node distance is 20 pixels.

As you probably know, Pixel Bender loops over each individual pixel.
For each pixel, the node to the top-left of that pixel is found. Then the script will test if the current pixel happens to be in a straight line between 2 adjacent nodes.
If it is, another test will determine if you can walk from node A to B, this is not the case should the pixel be black.

For each pixel, a result is kept. The output of the Pixel Bender kernel script is image3, so that gives 3 values for each pixel to use.
The first value is a binary value, this binary value is a collection of bit flags for the pixel, namely : is walkable or is not walkable, if the pixel is on the straight line to the node on the right/bottom-right/bottom/top-right.
The other 2 values are used to store the col and row of the top-left node.

For quick updating I also divided the black and white bitmap into areas, each area is 200×200 pixels large and is processed by its own ShaderJob. This way, when the black and white map is updated, I can process these updates by area instead of having to re-process the image as a whole each time.

Now for Alchemy…
Thanks to Ralph Hauwert’s excellent post on how to optimize the use of Alchemy and Pixel Bender, I decided to try the same with this experiment.
Flash will write the Pixel Bender result straight into Alchemy memory, where it is then processed in C to a usable grid.
The actual astar algorythm was also ported to C since the algorythm potentially runs a very large loop when using low node distance values or large black and white collision maps.

As a result
The path finder does run faster than in pure AS3, but not by a great amount. You can test it here.
The initial choice is to set the node distance property. The lower the value, the more nodes Pixel Bender will generate and thus the more data Alchemy has to crunch to display the astar path result.

Please note that…
the initial choice can really result in a slow pathfinder if you select ‘intensive’ for example. In most practical implementations the less-intensive settings are more than enough.

Credit to mr. Doob for the excellent Stats class

c code used in Alchemy
Around 90% of this app was built in C for use in Alchemy, below is the source.
It’s a bit cryptic sometimes, mostly due to some efforts in trying to optimize code execution with Alchemy.
Flash is only used to paint the maze and display the result from Alchemy & PB.

Alchemy C source