Project “animal” is an umbrella project designed to organise and focus development efforts toward new, exciting and, useful features. Given that our development resources are rather limited, this project is an attempt to make the best use of what we've got.

The project will be run in a different way to most development branches. Instead of a single identifiable target, with 1 or 2 developers working on it, this is intended to be a much broader undertaking.

Before implementation of a feature is started in earnest, we would like to see evidence that any proposed new features are going to be worthwhile and useful. It's also important that the design of the new feature has well-formed interfaces, and generally fits in well with the codebase as a whole.

Therefore, ideally each project should go through something like the following stages:

• initial proposal and design
• approval
• prototyping
• detailed design and implementation
• testing and documentation check
• final code review

This is only a rough outline of how a project will ideally go, and is not set in stone in any sense. Some mixing of the different stages is to be expected - for instance, prototyping can go on during the initial design, and extend throughout the implementation. Code documentation should *not* be left to the end or it's very unlikely to happen at all.

This stage should lay out the large-scale design of the proposed feature, including an initial idea of which interfaces are needed, how they talk to each other and how they relate to other parts of the code. This initial design is likely to change a bit after some prototyping and further experience in the problem domain.

Once the initial design is finished, comments from the the wider development community should be sought. Good ideas should be incorporated back into the proposal where possible.

Generally speaking, the first time a feature is implemented you'll get some things wrong. Some of the interfaces won't be quite right, or perhaps the performance will be sub-par. A prototyping stage helps to reduce these problems significantly - it points out pitfalls early on and avoids having to rewrite large chunks of the final implementation.

Prototype code can be part of aqsis proper, or can focus on a few detailed parts of the design in isolation. Studies of the details are often better implemented as separate projects - there is a prototypes directory in svn to communicate such prototypes with other developers.

With knowledge gained from the prototyping stage, the design should be updated. During the implementation, further issues will be found which will feed back into the design as a whole.

Since the process is very much an iterative one of design→code→test→design, it's advisable to have working code to test as soon as possible. Not only does this let us find problems before they get out of hand, but it makes you feel like you're getting somewhere Construct some canonical test cases for the newly working code, and run them often.

Parts of the prototype code may be reusable - it's good if they are. However, if the prototype contains some bad design decisions, it should be scrapped without hesitation, or at least heavily refactored.

Construct extra test cases, try to break the new code! There will be bugs.

Attempts should be made to keep the documentation up to date as the code is written, but inevitably some bits will fall behind the evolving code or be forgotten all together. Check through the new source - all classes should have a description, and all functions should have some documentation, even if they're trivial.

Code reviews are invaluable for increasing the general quality of code. If there's someone outside the project who's willing to take on this task, get them to do it. It's even better if code can be reviewed as it's being generated - this avoids the mammoth and daunting task of doing so at the end of the project, and finds design mistakes in time to fix them.

Each separate sub-project will get it's own branch in svn, branched from the trunk. As usual, projects are encouraged to regularly merge from the trunk into the branch so that the branch doesn't diverge too much as the trunk changes over time.

Fast, reliable, RenderMan-specific raytracing facility for aqsis.

Idea stage.

• BVH-based raytracing

* Highly Parallel Fast KD-tree Construction for Interactive Ray Tracing of Dynamic Scenes, Maxim Shevtsov, Alexei Soupikov and Alexander Kapustin. EUROGRAPHICS 2007.