All businessman are crazy about the pie chart. Here is Pie3D powered by dojox.gfx3d. The interface for the end-user is pretty similar with dojox.chart.bar3d: just add the data via addSeries, set the light, then call render, boo, you are all set.

There is a long design struggle between dojox.gfx and dojox.gfx3d. The 3D pie chart is a Cylinder, but crippled intentionally, for example, only rotation around Y axis is supported. Last but not the least, it is much easier for user to specify the rx, ry and height, instead of scratching their heads to find the right rotation angle. dojox.gfx would suffice.

On the other hand, dojox.gfx3d brings schedulers and reusable gradient from Cylinder. The schedulers may be essential if we want to highlight some slices by moving them a little bit away from the center. Plan to throw one away; you will, anyhow. dojox.gfx3d is selected. Please checkout the code.

One picture is worthy two thousand words. The idea is inspired by the Microsoft Excel’s canonical bar3d graphics. Features include:

• Multiple-series are supported
• Lighting
• Rotation, of course you can, but you need to be aware how difficult to find the right angles.
• Animation, check calibration section
• User-interactivity, theoretically if we could figure out how to interpret the mouse movement

And there is still a long long way to go…

Z-Order

To be honest, the data series is optimized for the Z-Order rendering. The cubes are misplaced if the difference of two values are huge. This issue could be addressed by override the Z-Order of the bar.

Calibration

The best scenario for the chart users is to fill the data, let the plotter figure out the range of X, Y, Z, and the user may override the “smart ticks” if necessary. We supports the latter only. Personally I regard there is an industry standard for ticking. Just need more time to dig it.

Other missing features

Other missing features include, but not limited: grid, labels, ticks, titles and legend. Most of them are infrastructure of chart.

As always, the snapshot of code, it is in dojox.chart namespace and depends dojox.gfx3d.

Recently, I am involved in Gentoo Guide translation. This is more or less like a new domain for me since I’ve never worked in localization. It is quite amazing to see how different pieces integrated to make our lives much easier. This HOWTO is merely the summary of this documentation, left here for personal record.

Head over to the source

You can use git to sync the repository, or download it from online CVS repository. In fact, there is a simpler way to do so referred to Gentoo XML Guide: just add ?passthru=1 to the targeted GuideXML. For example, I am translating the Gentoo Linux ALSA Guide, fetch the original xml via:

.

However, we need the other pieces like xsl, css, dtd, so we may need checkout all of them from the repository:

Using po to translate

po is the standard for translation. We are using po4a as suggested. First, let’s move to the right path, i.e $ROOT/gentoo/xml/htdocs/doc, and the translated xml is going to stored in doc/zh_CN.

emacs has built-in supports for po mode. I am using vim, and found the po.vim plugin is quite neat as well.

Check before commit

po or GuideXML are designed for machines, not for human being. It is much easier for eyes to catch the errors when reading rendered HTML.

Before your checkin, ensure you have read through Translators Howto for Gentoo Documentation.

Happy localizing.

This release targets to the final review of GSoC, more test cases are developed to fix the potential bugs in alpha1 release.
The following bugs are fixed:

• The matrix operations in OpenGL-like coordination system are verified, small bugs fixed.
• Fix the view bug in BSP
• Fix typo in toStdFill.

Improvement includes:

• Build dojox.gfx3d against the latest dojo TRUNK, r10315
• Move lighting.js to gfx3d namespace, using dojox.gfx3d.lighting now.
• Implement a new draw governor, named as Drawer(the name keeps reminding me IKEA or HomeDepot, any better suggestion?)
• Refactor the Scene to take the advantage of the new redraw policy

The Drawer

When an object is invalidated, moved to a new position or transformed by user script, the viewport would add this object to its todo list, and ask it to render itself in the next render function call. Since the viewport has no idea whether this change would cause the render order obsolete, the conservative drawer would assume so, and ask all the objects in the viewport to redraw themselves. On the other hand, in most chart application, the Z-order never change, so chart would redraw the modified objects. It makes a difference, according to the test case test_rotate.html, the conservative drawer takes ~30% CPU time, while the chart drawer takes ~22% CPU time. It is worthy notifying that the drawer candidates of Viewport and Scene are open for other optimization.

Here is the snapshot of alpha2.

This alpha release is a non-embarrassing release after huge refactory, ready for the community to review and start commit it to the trunk. This release makes the following major changes:

• Take OpenGL coordination as the default, i.e the X-axis starts from left to right; the Y-axis starts from bottom to the top; the Z-axis starts from inside to outside of the screen; the orientation is in the left-bottom of the viewport.
• Add OpenGL-like functions: createTriangles(.., “strip”), createTriangles(.., “fan”), createQuads(.., “strip”), …
• add setScheduler to Viewport and Scene, so users may override the default zOrder scheduler by bsp.
• Merge setTexture and setFill to setFill

fix the following bugs:

• bsp sorting bug
• Add intensity in ambient light source.

and the following optimization:

• Optimize the Cube, only three surface are rendered.
• Optimize the Cylinder to eliminate rendering the back cap

And there are still a long way to go:

• Verify the coordination system
• Verify the lighting effects
• Redraw optimization

Attached is the tar ball, just untar it in $DOJO/all/truck/dojox, gfx3d directory is created, and gfx/lighting.js is overwritten.