Project Title: Implementation of Open Dynamics Engine rigid bodies physics in Blender. Synopsis This project will involve the implementation of the open source physics SDK provided by www.ode.org to provide functionality allowing Blender users to create physics-based animations including collisions, forces, motors and joint constraints. This will improve the flexibility and sense of realism in animations produced through blender by allowing them to apply a set of coherent physical rules, and also potentially benefit the game engine, by providing an interface with a real-time rigid body physics engine through the blender system. Deliverables The goals of this system will be to, by the end of the project duration, provide a working implementation of ODE-based constraint and integration functionality, including collision detection, joints/constraints, forces and motors. The essential criteria of the physics engine might be considered to be the first three items. Discussion of the task Note that all recommendations I make here are just that, recommendations, and are subject to change at the discretion of the mentoring organisation. Collision detection This will be achieved by automatically generating (with physics enabled) a geometric object (or geom) and associated rigid body (with user configurable properties including mass, whether or not physics is enabled for that object, initial velocity, auto-disabling options (perhaps through an advanced menu) and so forth) for every graphical body created in blender. These will be of type sphere, box or cylinder where applicable, generating a triangular mesh to represent more complicated objects. These can then be hierarchically divided into collision spaces to optimise performance by culling the checking of impossible collisions. These collision spaces may be of one of three forms, based on the decision of the mentoring organisation: 1) Simple space (Performs no collision culling but is optimal for smaller numbers of geoms) 2) Multi-resolution hash table space (The most flexible method, resolution may be dynamically scaled depending on number of geoms to optimise speed, accuracy and stability of the simulation) 3) Quadtree space (A tree-based hierarchical division of the simulation world into collision spaces, unnecessary with smaller numbers of geoms but most efficient with large numbers) My own recommendation in this situation would be the use of scaleable resolution hash table spaces, as this will be most widely applicable to the unpredictable creations of the user. Joints/Constraints The joints to be made available to the user would be fixed, hinge, ball and socket, slider, hinge-2 and universal joint (The Contact constraint would not be available to the user, but handled entirely internally through the collisions system discussed above). These could be applied to physics-enabled bodies through a tool which would allow selection of two bodies, a joint type, anchor (pivot of the joint) and axes (as applicable to the joint), properties which would be attached to the joint and available for modification through the interface at a later point. Forces The addition of forces as an element of the Open Dynamics engine integrally attached to the use of rigid bodies would require no additional work, however it might be advisable to allow the user to manipulate the simulation through application of force during runtime by means of, e.g. use of left mouse button to pull and right to push. This would carry a relatively low priority in this project, and might be added as a feature should time allow. Motors Use of motors would also seem to be relatively low priority, but could be useful to the user interested in creating more sophisticated animations, involving mechanical systems or characters/creatures with their own motions. The addition of this could be done with minimal additional workload once the interface for the addition of joints is added, as a variation of this existing interface could be adapted to interact with the existing ODE motor APIs. Step Algorithm Application of the physical rules discussed here would occur through an algorithm repeating at a given interval. The ODE supplies two possible algorithms, which one would need to decide between based on preferences for speed, stability and accuracy. The most accurate and stable is the default step algorithm, however this will run slowly and may function with a higher level of accuracy than is required for purely graphical simulations. The 'Quickstep' algorithm is, as the name suggests, superior in speed, but inferior in accuracy and stability. However, the accuracy, stability and speed of the Quickstep algorithm can be varied by changing the step rate, increasing the rate for higher speed and decreasing it for greater accuracy and stability. This provides greater flexibility than the default step algorithm would, especially if the step rate could be dynamically scaled in inverse proportion to the number of Degrees of Freedom (DOF) constrained in the simulation. Graphical Feedback In addition to allowing an interface for the creation and manipulation of simulated physical systems, the simulation would require feedback from the physics engine to alter the position of the graphical elements corresponding to the simulated rigid bodies. This should be easy enough to implement through the APIs provided with the ODE, whereby the position and orientation of each element can easily enough be passed to the graphical engine and used to ensure synchronicity between graphics and physics. ODE Modifications This more or less concludes the higher-level overview of the tasks to be performed. In addition to these, there are several points on which it might be advisable to make minor modifications to the open source physics engine for reasons of memory efficiency and stability, such as the streamlining of redundant arguments to certain functions (notably the impulse to force conversion function), and additional functionality in the rigid body destructors (allowing removal of attached constraints which are currently put into 'limbo'), and addition of validation to mutators which access variables known to only function correctly with certain values. It would also be necessary to decide at an early point whether the blender implementation of the ODE is to be built to use single or double precision floating point numbers, considering the trade-off between speed and accuracy/stability. Project Schedule As the project development takes place between June 24th (Although I can start development as soon as is necessary) and September 1st, or roughly 9 weeks, I propose initially dividing the development period into two major sections, the first of which will involve implementation of the collision system. This will be preceded, however, by an initial period during which the specification will be worked out in greater detail, including extrapolation from the mentoring organisation on such matters as whether single or double point precision is to be used, what method of solid representation, space representation and user interface is preferred, as well as the choice of step algorithm. All of these are outlined to an extent earlier in this application, and I can offer recommendations on each as required. The collisions implementation period will involve first the application of the ODE APIs to allow the attachment of rigid bodies and geometric objects to the graphical solids created by blender, followed by the modification of the step algorithm to include feedback to the graphical display (which might be used every step, or at intervals depending on speed and memory considerations). After this, collision spaces should be implemented, after which the collisions work may be considered to be completed. Testing will take place throughout the process, and when sections are completed before schedule, the next section will begin immediately, and the schedule will be altered accordingly. The second section will involve implementation of the joints and constraints, which will be roughly divided into development of the interface and application of the APIs. A period of ten days will be allocated at the end for tidying up loose ends and ensuring that all aspects of the project are completed to the satisfaction of the mentoring organisation. Thus, the planned schedule is as follows (Dates provided are subject to change): Week 1 (06/24-07/01): Finalising specification Week 2 (07/02-07/08): Implementation of collision detection APIs within Blender Week 3 (07/09-07/15): Continued Implementation of APIs Week 4 (07/16-07/22): Modification of step algorithm for graphical feedback Week 5 (07/23-07/29): Implementation of collision spaces Week 6 (07/30-08/05): Continued Implementation of collision spaces Week 7 (08/06-08/12): Implementation of constraint APIs Week 8 (08/13-08/19): Creation of constraint interface Remaining Period (08/20-09/01): Final touches, completion of loose ends, and so forth. Within the larger periods (constraints and collisions), the milestones might be considered flexible, but the collisions should be finished by the 5th of August at the latest, and the constraints clearly by the 1st of September. Addition of motors could be done if time allows, following implementation of the higher priorities. Biographical Details I am currently studying Computer Science and Game Design at the University of Southern California, and in the course of my studies, as well as through personal interest, have worked with other 3d systems, including Maya 6, 3ds Max, Worldcraft, Hammer, and the product concerned, Blender. I am familiar with the Blender tools, and have examined the source code, although I have not as of yet made any significant modifications to it. I have worked with C and C++ extensively over the last year, amongst other projects programming an extensive real-time graphical artificial life simulation with ten different species and terrain. In terms of qualifications towards the physics aspect, I have a thorough understanding of the Open Dynamics Engine, and received a perfect 800 score on my SAT II Physics, as well as a score of 100% in a British Edexcel A-Level Physics examination (equivalent to AP). I also took an Edexcel A-level advanced mathematics course on mechanical physics in which I received an A.