BSP-Tree vs Z-Buffer

The standard zbuffer which we're using now renders from front-to-back for pixels, such that if two polygons intersect it will show the intersection properly and no time is wasted drawing pixels that are blocked by other polygons.

The zbuffer has downsides - beside slowing down the GPU, it's not always accurate (especially if the range of vision is deep), it doesn't allow proper display of translucent polygons, and sees all polygons as a random "soup" with no object-level abstraction.

PySoy inherited intra-object BSP tree calculations from Soya allowing large objects (such as a whole level as one entity) to use BSP tree optimisation. This can easily be extended to all entities such that every object can have unseen polygons pruned and the faces rendered in the proper order.

If objects cannot intersect with a physics model which forbids it then objects can be sorted by a BSP-tree dynamically, then each object can be rendered individually by it's precomputed order. Further optimisations can be made to only recalculate the object-level BSP-tree when objects have moved sufficiently to justify it (with a dynamic accuracy based on CPU load).

Just some ideas to chew on, nothing that's going to get into 1.0...

1.0 focus

With the target a week away and still quite a bit away from being ready, I've started ripping up the API and trying to put together something more coherent. Soya has accumulated *SO* much extra baggage in it's namespace: copies of root level classes with only slight difference in function (ie, Shape, SolidShape, CellShadingMesh, etc), convience values such as WHITE, BLACK, and TRANSPARENT mixed into the root namespace, oh and let's not even touch the ODE issue yet.

The renaming process is also the opprotunity to clean the code up. Many of these copies remove redundant code, thus decreasing the amount that will need to be debugged later, and making things generally easier to read.

At the very least I'd like to see a beta released by the target date, though we should keep in mind that the API in 1.0 will haunt us for months (or even years) to come.

New Physics

Maybe I'm insane, but I've been mulling over some ideas to fully integrate ODE with PySoy, not for collision detection, but for rigid body physics.

This new model would let ODE handle velocity, rotation, etc for all Nodes and Entities directly in the Scene (Nodes treated as a group of joined entities) with the controller applying forces to various objects to affect them.

This new model, which includes Cal3D characters, would allow much more dynamic characters (adjusting walk cycles to terrain, able to trip over things, etc) than was feasable previously while allowing character speed to be set just with animation speed (ie, no more animation+movement syncing needed) since the animation of their feet would propel them forward.

I don't think this has ever been done before, certainly not in a free software game.

Forking Flurry

It seems I was the last one to see it, but it became nessesary for a Soya3d fork to be created in order to build it into a community project.

I've spent the last 28 hours sorting the website business out. Redirects from the various parts of the old soya3d.org now point to their respective elements at pysoy.org, some of which are in read-only states until everything is done. Having external links working has been my top priority.

On the PySoy site we have permissions issues in the DB being sorted through. I'm working through them as quickly as possible but it's going to take me a few more days to get everything working stable again. It's a large website, after all, with many plugins added.

I'm also working to get the mailing lists up. GNU Mailman has changed the way it wants to be installed (-D MAILMAN flag to apache?). I'm getting this done in my free time, between work for paid clients, so it'll be done as soon as it can.

.soy progress

The new 2-tier format is written out now, seperating object level from object-data level. This was pseudo-done in the former draft (blockid 0-127 == object level, 128+ object-data level) but this is far, far cleaner.

This allows objects to be quickly skipped-over on read/import, adds a much larger id-space both for types of objects and types of data within each object, and cleaner discard/recovery methods based on Palle's experience implementing the importer. We should have the blender importer/exporter up to something resembling this spec by tonight.

Check the updated .soy file format spec and give constructive criticism.