Exit xml, Enter .soy

I did a number of tests last night, and even in pure Python (where XML is highly optimized) it was far, far too slow. It was also several orders of magnitude larger than it should be, even gzipped, which is bad when transfering over the network in realtime.

Another problem, too, was the Mesh API. If the Blender exporter was to have the ability to send pre-optimized data (from Blender itself) into a soya.Mesh, it dictated a very complex API which would allow both editing and exporting to be done at reasonable speeds.

So it's all ripped up now (literally, I took the newsprint draft pages and ripped them up) and I started work on an extensible binary block format comperable to AIFF, RIFF, TIFF, PNG, etc. This will allow new features to be added while both newer files compatable with older software and newer software compatable with older files. IE, full backward and forward compatability. The draft spec can be found at http://www.soya3d.org/wiki/Formats/soy

The format is being designed with full optimizations already made; not only the various data structures already seperated, indexed, and linked, but ordered. That is, it can take advantage of vertex buffer optimization (with no specific software/format support for it).

It's structure overhead is very low, I'm guessing real world uses will pit it lower than 1% for size. With support for it implemented in C/Pyrex loading and saving should be simple. It also allows a much more relational data layout tree than Soya currently uses; it'll be possible to include multiple data objects (UNIX cat command can do it, just like Ogg) in a single file and reference them with path/filename#name just as you do in HTML.

While still in heavy development (and unfinished), comments and feedback are requested.

Drafting an XML format

I'm a bit suprised at myself, just last year arguing that XML was being over-used, now attempting to implement an optimized XML format for Soya.

The job isn't simple, since I'm working on soya.Mesh at the same time and these are intricatly linked. On one side we have Blender/etc which already have neighbors, normals, etc computed. On the other we want the data to be user-editable in it's text format. And lastly, Soya needs to be able to load and save this format more efficiently than Cerializer.

Blender importers/exporters should be able to drop data into this format without using Soya. It should survive extension for future Soya features and be permissable both in a file by itself and bundled with other data.

Subversion mirroring

I have a full Soya trunk mirror running (updated every 5 minutes) at www.soya3d.org now. This is useful for both the source browser and branching (for those without GNA! access).

Unfortunetly, because this isn't a full mirror the revision numbers are out of sync. A full mirror would require setup from GNA!'s side as well as some directory rearrangement on both ends so all the data can exist harmoniously.

SoC Python ranking finished

Well, Soya got 2 projects this year. They are:

• Soya3D Collision API : Improving ODE integration in the core by David Pierre-Yves


• Soya3D exporting/importing tools for Blender by Palle Raabjerg

Of the previously mentioned interesting non-Soya proposals, Base multidimensional array type for Python core and Python interface for writing Mozilla (NPAPI) plugins (which mentions a Soya interface as a goal) also made it into the set of 25 proposals to be accepted.

We're awaiting Google's confirmation of these, but unless one of the applicants is found ineligable, all four of these should be approved.

There's a bit of disappointment in the air over the other 4 Soya proposals that didn't make it due to the unexpected low number of project slots offered by Google, but 2 is better than none.

The Cut

I think we just finished one of the most hard decidions we've had so far. Out of the remaining 5, only 2-3 are likely to be approved. All of the remaining proposals are excellent, and each of the students very qualified, so the choice comes down to which projects are most needed for Soya.

We had a public Soya meeting where students had a chance to discuss their projects in more depth, then us mentors discussed them for another hour. I won't post what the outcome was, but we've ranked the proposals in preference. From here, it's up to the other PSF mentors and admins to decide how many slots we'll receive and possibly even re-order them.

Tomorrow at approximately 8PM EDT we'll have the tenative results. Tuesday Google will be posting the winning proposals. Only then will the final results be known (after all, one of the students could be disqualified/etc).

SoC final cut begins...

"N"'s are out. PSF was allocated 25 proposals, tied with Apache for the maximum.

One of the Soya proposals has dropped out of the range due to negetive feedback from last year's mentors re: the student.

The remaining 5 Soya proposals are hovering around the #25 marker and may move radically over the next 48 hours.

Also, it's possible the #25 may be boosted to 26 or 27 before the end.

It's all up to the other Python mentors now. Wether they vote to downgrade the Soya apps or promote others in their slots will detirmine which get approved.

SoC update

We're still waiting for numbers from Google. They're apparently still working on the tools to generate the number of projects each organization will receive (tweaking variables/etc).

There's been some dire numbers being thrown around, such as 75% of the orgs receiving 5 or fewer projects, but the PSF should certainly be in the upper 25%. The lowest Soya app is now rated at #28.

Note, however, if the number PSF receives is very low - 30 or 35, a chaotic re-ordering is likely and anything is possible. I'm still betting on a higher number; it'd be entirely unfair for smaller orgs with 2-4 mentors to receive a roughly 1:1 student:mentor ratio while larger orgs to have fewer than half as many projects as mentors. We'd end up with a good number of mentors jaded from the time-consuming last few weeks not producing anything productive.

Summer of Code project ranking

We're expecting our nearly-official "N" (number of projects) from Google tomarrow. Python Software Foundation is requesting 70 proposals, it's very unlikely we'll receive fewer than 50.

Out of over 200 applications, the lowest Soya app we're considering is ranked at 31. 6 out of 7 isn't bad at all. One application for a water-wave-effects class was removed from consideration when we received a much stronger proposal for roughly the same project.

Currently ranked at 39 is an extremely interesting project by Marcin Pertek for building a Mozilla/Firefox plugin interface for Python. Basically, if completed, we could write Firefox plugins using PyGame, Soya, or any number of other gui/widget modules.

Of course, for security, we need a .xml file format for 3d objects before Soya is used for building Plugins. Another great example for why we need to stop bundling code with data via Python pickles.

Andrew Bouchard has another interesting proposal up (currently ranked 34) for an artificial intelligence suite in Python. His focus is primarily robotics though there's only a marginal difference between game ai and robotics ai when you work with cal3d directly.

The most interesting PSF proposal, ranking solid at 9, is Karol Langner's "Base multidimensional array type for Python core". Anyone who's needed to use an array[x][y][z] for 3d data storage can surely see the value of having these types replaced by an optimized multidimensional list in Python core. Prehaps we'll see this with Python 2.5.

I think these are all a sure bet to be approved. We'll know for sure on Monday.