En aquest fitxer es descriuran les decisions i idees madures sobre com ha de ser S2. Les especulacions o idees de fumeta per madurar estan a Saphyre2 Objects i Saphyre2 Drug Induced Happy Ideas.
El disseny de Saphyre2 es basa en:
- Multiunivers (Multivers): Els objectes físics viuen en universos que són completament independents. L'univers alocata i simula els seus objectes de forma completament autònoma, i ha de permetre activació i desactivació, així com altres opcions de configuració locals (dimensions, escala, etc...)
- Multisistema: Diversos sistemes dinàmics (System) poden ser simulats alhora en cada Univers, cadascun amb el seu propi model físic i estratègia de simulació (solvers, freq actualització, etc...)
- Multimodel: Un mateix objecte físic (Object) pot representar-se amb diversos models (Model) matemàtics (== cjts d'equacions diferencials). Un Object pot canviar de Model per motius interns o a petició de l'usuari (tècnica de LOD, per exemple) en l'inici de qualsevol pas de la simulació. Els Models podran ser accedits a traves de coordenades de configuracio/maximals, generalitzades, DOF, etc...
- Restriccions genèriques: Sobre els Object es poden definir diverses restriccions (igualtat, desigualtat, juntes mecàniques, no-interpenetració, limits angulars, etc..). La definició d'aquestes restriccions es farà sobre els Object de forma genèrica, però la seva formulació matemàtica per a simular-la pot dependre del tipus de Model amb el qual es simula l'Objecte en cada moment.
- Blocs de processament + Blocs de Dades + DAG: Tota la seqüència de càlculs estarà dividida en blocs de processament independents que només es relacionaran entre ells per mitjà d'un fluxe de dades completament predeterminat. Això està orientat a una futura paralelització dels càlculs.
- Homogeneitat: Els diversos tipus de Models, Connectors i Constraints suportats es tractaran de forma homogènia, sense casos especials, a traves de les interficies de les classes base abstractes (Model, Connector i Constraint). Les particularitats de cada subclasse nomes afectaran a la inicialitzacio dels objectes i a l'associacio d'objectes a Systems i Solvers (cada Solver pot resoldre un problema matematic concret).
Saphyre2 can simulate several Universes in parallel, each one being completely independent from the rest.
All animated Objects live in the Universe, but are grouped into Systems in order to animate/simulate them properly and efficiently.
Some aspects of each System can be configured:
- Precision
- Timestep
- Simulation scheme/algorithm
- Integration Method
- Constraint Solver
- Internal Collision/Contact Detection Frequency
- Contact Solver
- Collision Solver
The criteria for grouping objects into systems are:
- Objects that interact directly (through constraints, force fields, etc..) should be in the same System.
- Objects whose natural Model can be simulated using the same scheme/algorithm should be in the same System.
- Objects that are likely to be created/enabled/disabled/destroyed together should be in the same System.
Inside each System the Objects (their Models, in fact) can be furtherly grouped/partitioned for efficiency purposes (decoupled objects can be simulated independently)
The System is the smallest simulated unit in Saphyre2.
A physical Object may be represented for its animation/simulation by different mathematical models (sets DOF and their equations of motion).
Switching the Model that represents a certain Object for can be useful for several reasons:
- Internal reasons (ex: to simulate 2 the interaction between Objects whose natural Models are not comptible.
- LOD technique (on user petition)
As Objects live in the Universe, Models live in Systems. A Model can only be in one System at the same time, but it can be transferred into another one if needed.
Does a Model exist outside of a specific System? Yes, even though for efficiency purposes it may be better to make Models local to the System in which they are simulated, for flexibility I'll make them global BY NOW... this may change in the future.
- Todo:
- Enumerar en quins casos te sentit que un Model canvii de System (Systems amb limits espaials, per exemple, per simular habitacions autònomes, etc...)
Theory about model-switching can be found in GILLESPIE97.
Si es vol que Model pugui representar un obj tan complexes com un cotxe (Car) llavors s'ha de considerar la seva conversió a una sèrie de Models i Constraints en coordenades maximals, que no correspondria a un altre Model sinó a un System. AIXO ES MOLT IMPORTANT!
El Model en coordenades generalitzades podria estar sotmès a Constraints no integrades en el propi model (no usades per eliminar DOF analíticament, ja sigui pq són no-holonòmiques o pq involucren altres Models o senzillament pq no ho sabem fer), i aquestes també s'haurien de convertir en canviar de Model.
Un personatge articulat seria un altre bon exemple d'objecte físic que podria tenir un Model en coordenades generalitzades molt complex convertible a un cjt d'objectes simples en coordenades maximals i constraints entre ells. En aquest cas, la jerarquia interna del model seria més complexa que en cas del cotxe, i els requeriments de controlabilitat i capacitat d'integració entre cinemàtica i dinàmica serien molt importants.
Sobre els Object es poden definir diverses restriccions (igualtat, desigualtat, juntes mecàniques, no-interpenetració, limits angulars, etc..). La definició d'aquestes restriccions es farà sobre els Object de forma genèrica, però la seva formulació matemàtica per a simular-la pot dependre del tipus de Model amb el qual es simula l'Objecte en cada moment.
Tasks, Subsystems, Data Flow...
For more information on entities see Saphyre2 Objects.
Several short examples:
- Dynamic vehicle with kinematic tower on top
- Vehicle on rails
- Vehicle with deformable wheels (simplified deformable model linked to rigid chassis)
- Articulated character with flapping wings
- Stacked boxes
- Rope attachable to dynamics objects
- A climbable rope ladder
- A door opened by a mechanical device (pulleys and counterweights)
- A robot with curve animation and IK controllers
Several detailed examples follow in the next subsections.
A particle (with any geometric shape) has 3 translational DOF. We may want to control its planar movement (XZ plane) while its vertical (Y axis) movement is computed by dynamics (gravity).
The control is performed by speed input by the user (kinematic control), therefore, the X and Z DOF are not free but controlled kinematically.
The final movement is restricted by the non-penetration constraint between the particle and any other object (floor, walls, other particles).
A particle is now constrained to move on a Surface (which may be attached to another dynamics object or not)
A particle (with any geometric shape) has 3 translational DOF. We may want to control its planar movement (XZ plane) while its vertical (Y axis) movement is computed by dynamics (gravity).
The control is performed by speed input by the user (kinematic control), therefore, the X and Z DOF are not free but controlled kinematically.
The final movement is restricted by the non-penetration constraint between the particle and any other object (floor, walls, other particles).
A simple pendulum consists of a mass particle attached to a rigid rod with one end fixed to some point in the space. The System can be furtherly constrained to move on a plane.
This System can be modelled in several ways:
- Maximal/cartesian coordinates and constraints that attach the objects together.
- Particle: 3 DOF
- Rigid Rod: 6 DOF
- PointToPoint Constraint between Particle and one Rod end: -3 DOF
- And either:
- PointToPoint Constraint between Rod and ConnectorPoint: -3 DOF
- PointOnPlane(Surface?) Constraint between Particle and 3D Plane: -1 DOF
- Or:
- Hinge Constraint between Rod and ConnectorAxis: -4 DOF
- Reduced coordinates: There is only 1 DOF, the rotation of the rod/particle around the fixed point
Un cotxe es pot modelar com:
- Coordenades Generalitzades, 1 sol Model amb:
- 3 DOF de traslació (carrosseria)
- 3 de rotació (carrosseria)
- 4x1 de rotació (per cada roda)
- 4x1 de translació (per l'esmorteïdor de cada roda)
- 1 de rotació al voltant de la vertical per les 2 rodes del davant (giren sobre eixos diferents però el mateix angle => mateix DOF!)
Total: 3+3+4*1+4*1+1 = 15 DOF
- Coordenades Maximals, 5 Models + 4 Joints:
- 1 carrosseria (rigid) 6DOF
- 4 rodes (rígides?) 6DOF
- 2 Joints (Hinge - 2DOF rot i Damper -2DOF trans)
- 2 Joints (Wheel - 1DOF rot i Damper -2DOF trans)
Total: 6+6*4 - 2*(2+2) - 2*(1+2) = 30 - 8 - 6 = 16 DOF (1 més pq els angles de rotació de les 2 rodes de davant no estan acoblats... com fer-ho?)
Saphyre2 is divided in several modules:
- S2Math: Math types and algorithms.
- S2Utils: Utility things (Debug modules, etc...)
- S2Core: The internals of S2 animation/simulation framework. See Saphyre2 Core.
- S2API: The public interface to S2. See Saphyre2 API.
- Cold: Simple Substandard COLlision Detection library.
- S2_Debug: DebugStream, DebugRenderer, Streamed output i rendering ampliat amb tipus propis.
- Conversor tipus matemàtics (vec->mat, mat3x3->mat general, conversions entre tipus de llibreries externes...)
Generated on Tue Aug 10 15:58:31 2004 for Saphyre2 by
1.3.5