Soya3D exporting/importing tools for Blender

Summer of Code proposal for the Python Software Foundation by Palle Raabjerg

My name is Palle Raabjerg, I'm a student of Software Engineering at Aalborg University in Denmark, currently on fourth semester. Aalborg University focuses on a group based educational model, which means that each semester, I am working with a new group on a project which lasts throughout the semester, with about four courses to support us in the subject that semester. The first two semesters was a "basis" year with a focus mostly on mathematics and its applications and usages in computer science, with, amongst others, two pure mathematics courses, a course in C programming, Discrete Mathematics and a course in Computer Supported Calculations. And also a few courses concerned with project planning and group project management.
Third semesters project was focused on "the development of a bigger application", in which we made an enigma-encrypted database with web interface and web services. Courses included Algorithmics And Datastructures, Object Oriented Programming, Databases, and another course on group planning and development. Fourth semester (my current semester) is concerned with designing a programming language and creating a compiler to go with it. The specific task of my group is to make our language compile to a turing state machine which can then be interpreted by a virtual machine. The courses include Languages And Compilers, Syntax And Semantics, Database Systems and Computer And Network Architecture.
I am also a proponent of Free Software (In the Stallman sense), and an avid user of Blender, and I have recently become very interested in Python and Soya for private game development projects.

My proposal is about writing Soya3D importer tools, and about improving, or rewriting the Soya3D exporter tools for Blender.

Currently, no Soya3D importers exist for Blender. This means you cannot import any Soya3D or Cal3D models into Blender. This can be inconvenient for both the game developer, as he needs to publish the .blend files to allow people to modify models, and for a gamer community surrounding a project, as they can't modify models unless the developer publishes the .blend files. (Note: This might be a perfectly okay and even preferable situation for some proprietary game developers, but Soya3D is built on a philosophy of openness and freedom, making this a more important feature.)

The Soya3D exporter tools basically consists of the blender2soya and blender2cal3d scripts. blender2soya is currently used for static (non-animated) models, and blender2cal3d is used for exporting animated skeletal models to the Cal3D format, which can also be used with Soya.
These two scripts lack many features, however, and still contains known flaws.

If I am assigned to this project, I will create Soya3D and Cal3D importers for Blender, and I will work on both exporter scripts to fix and to add, amongst others, the following features:

For blender2cal3d:
Scale keys Better handling of objects - Currently, when importing a Cal3D model, you need to have the entire model in a single object.
Spring support
Material color/texture export - Currently, only UV mapped images are supported for texturing.
And various other features which are supported by both Cal3D and Blender, but not the exporter.

For blender2soya:
There are talks about a redesign of the format Soya3D uses for models. In this case, I would be involved in this redesign, and the blender2soya script would have to be rewritten.
Actual feature improvements would include:
Material color/texture export - Same as above.
Better handling of objects - Currently, objects are just merged into the same mesh during conversion, instead of handling it as separate objects in the engine
Level features - Support for explicitly exporting environments as levels. For instance, having the possibility of defining "solid" surfaces for collisions and placing enemies/objects with attributes associated with them. (Note that while I feel certain I can do all the other improvements inside the given time frame, I am not sure whether I can actually finish this too, on top of the rest. I may begin adding features for this, when all other improvements are done, though)


First, all individual classes and methods would be documented through the use of pydoc, a good tool for creating detailed code documentation for Python.
Secondly, the overall class design, and the ideas behind it would be described and illustrated by the creation of a separate document by the use of LaTeX for formatting, and possibly Dia for UML diagrams.
Any particularly interesting pieces of code may be included for documentation here as well.

Time plan

The first four days, preferably an entire week, will be dedicated purely to reading about, and experimenting with the Cal3D and Blender APIs by creating prototype exporters and importers with few features. By my experience, any time lost during this phase, will be gained by avoiding many stupid mistakes during the main development.
After this, I will begin work on the Cal3D export and import scripts. It is possible, or even likely, that a new Soya format will be under development by the Soya team in the meantime. Therefore, development on the Soya export and import scripts will wait until the Cal3D scripts are finished and the Soya format possibly finalized.

Benefits for the community

Soya3D would obviously benefit greatly from artists having better and easier access to conversions to and from Blender. and with regards to the Cal3D exporter and importer, not only Soya3D, but also several other projects would benefit from a Cal3D importer and a better Cal3D exporter for Blender, since Cal3D is a library used by other projects than Soya3D. Blender may also, as a consequence, become a more widely used modelling tool for Cal3D models in general.

Benefits for me

First of all, I am myself a user of Soya3D, Blender, and therefore, these exporters. So from that perspective, I certainly have an interest in a better exporter.
And since I am a student at Software Engineering, I will also be doing this for the learning experience. Admittedly, I am inexperienced in a lot of the theory concerning exporters and 3D on a programming level. However, as a Software Engineer, an important skill is to be able to learn and adapt to new technologies fairly quickly, and the best way of improving this skill, is by involving myself in places I haven't been before. Also, this would be my first major involvement in a Free Software project, apart from the Danish translations I have done for a few other projects.

Why me?

So why me, if I say I am inexperienced in this area? What qualities do I have?
For one thing, I would prioritize writing readable and extensible code. This may not sound impressive, but I have seen quite a few people get their priorities wrong in this field. I.e. when working on something like a compiler, I have seen people readily sacrifice readability to get what probably amounts to a few microseconds of performance during compilation. I will not do this, unless performance is absolutely necessesary, which it isn't, in neither exporters nor compilers. (I may track down and fix hotspots if an export starts taking minutes, but that's an entirely different story.)
And it is particularly necessary for an exporter to be readable and extensible, since it has to work with two APIs (Cal3D/Soya3D and Blender) that may be subject to changes and extensions between versions. I wont be there at any time to maintain and fix the exporter, so it's important that other people can take over and continue the work whenever Cal3D, Soya3D and Blender changes.
And even if I haven't been involved much with any open source projects so far, I do have a few years of experience with group based work (by virtue of group based model of Aalborg University), and I have learned from this to be always open about criticism and suggestions, even while arguing strongly for my own ideas. I believe this may also be a good quality in an open source project.

Best Regards,
Palle Raabjerg