Main Page | Namespace List | Class Hierarchy | Class List | File List | Class Members | File Members | Related Pages

Saphyre2 Drug Induced Happy Ideas

In this file we discuss some ideas (design ideas, possible features, possible implementations...) that are not mature enought to be part of the stable design and therefore must be

Jerarquia de sistemes de referència.

Els objectes haurien de poder estar relacionats segons una jerarquia de sistemes de coordenades... Qui té RefSys?

Conclusion & Decisions

Això pot afectar a la integració amb motors externs (si tenen graf d'escena amb transform nodes...), i no és imprescindible ara mateix, o sigui que ho aplaço per quan ho vegi clar (com quasi tot :)

Objects & Models

Object podria ser una mena de representant d'un objecte físic, i tenir associat a cada instant un cert Model que representaria el model físic concret de l'objecte en aquell moment (partícula, rígid, deformable, etc...)

Això permetria canvis de model dinàmics (quan interactuin o passi alguna cosa especial) però mantenint la "identitat" dels objectes.

Els Controllers, Sensors i Constraints haurien de manipular-se EXTERNAMENT des del nivell Object únicament, no pas Model, encara que possiblement a nivell intern caldrà tenir rèpliques dels objectes específiques per cada Model, però això HA de ser transparent a l'aplicació!!

La multiplicitat de Models per un Object és una mica complicada de gestionar... el més elegant, crec, seria que hi haguessin algo així com Model Proxies, que encapsulessin un Model de tipus A pq funcionés com si fos de tipus B, ocultant tota la complexitat de sincronització (sincronització sota demanda?)

El ModelProxyAB seria un ModelA que internament gestiona un ModelB. ModelProxyAB hauria d'heretar de ModelA per oferir-ne tota la funcionalitat i tenir internament un ModelB a partir del qual s'inicialitzaria i amb el que podria sincronitzar-se en ambdós sentits (mètodes SyncProxy() i SyncInternal() de ModelProxy?)

Això pot semblar que implica una explosió combinatòria (totes les parelles de Models?) però en realitat el num de Models compatibles serà petit.

De fet, la idea dels ModelProxy es pot portar més enllà, i fer-los servir per controlar Models complexos (algo semblant a usar Deformers simples/intuitius per deformar malles complexes en Maya :)

Un Model complex podria ser controlat per un altre del mateix tipus però amb menys resolució (roba amb menys partícules, model articulat amb menys juntes, etc...)

Això admetria, de fet, allò de què parlava a les propostes per RACINE: Fer previews d'animacions complexes mitjançant models més simples (ModelProxy) que capturessin bona part de l'essència del model complex però fossin més fàcils de simular

Ho deixo com a bona idea, de moment, però crec que aquesta idea s'adaptaria bastant bé en l'arquitectura que tinc més o menys decidida.

Conclusió i Decisions

Un Object es crearà amb un cert Model concret, el "model natural". Els DOF de l'Objecte sempre seran els d'aquest Model (la Shape, els Controllers i els Sensors sempre els han de poder llegir)

Això no implica que els DOF del Model que està representant l'Object actualment no es pugui consultar o controlar de forma específica (veure discussió sobre els possibles usos alternatius dels ModelProxy en algun altre lloc d'aquesta documentació)

Motius per canviar de Model:

Els canvis de Model només s'han de poder fer des de l'app en certs punts de sincronització. (segurament, fora del pas de simulació)

Cal veure entre quines parelles de models es poden fer transicions i definir com es faran virtual Model::CreateFrom(Model *p_model) i Model::UpdateFrom() amb polimorfisme per cada subclasse de model?

TOTS els Models s'haurien de poder transformar a Particle, o a Rigid si es vol orientació...

Lightweight Objects

Segurament seria útil poder tenir objectes lleugers per als tipus d'objectes físics usats massivament (partícules i sòlids rígids principalment). Aquests objectes lleugers es diferenciarien de la resta en:

Bàsicament, es tractaria de combinar un Object i un Model concret en una mateixa classe i minimitzar tota la complexitat de bookkeeping que el sistema d'Objectes amb Model variable genera.

Objects, Models & Shapes

Hi ha una mica d'esquizofrènia entre model dinàmic i forma de l'objecte... una superfície implícita rígida i un sòlid rígid comparteixen el model dinàmic però la superfície té equs de forma que permetrien "enganxar-hi" restriccions i el sòlid no!

Model = Model matemàtic d'un objecte físic:

El més lògic i simple és associar una Shape (forma física) a un Object... La Shape pot dependre dels DOF de l'Objecte o no (a nivell global segur, per la posició i orientació com a mínim, però a nivell local si és una shape rígida no dependrà de res més).

L'Object no dependrà per res de la Shape... si hi ha alguna dependència entre la dinàmica i la forma de l'Object, llavors aquesta relació serà a través dels DOF de la dinàmica interna de l'Object, no pas dels paràmetres que defineixen la Shape.

Alguns tipus de Connectors, però, si que podran dependre de la Shape, i indirectament, de l'Object (DOF)

Conclusió i Decisions

Alguns Model serien (S = estat)

Animation/Simulation Stages (més o menys ordenats)

Initialization

In this first stage entities are created and initialized. The main actions that need to be performed are:

Loop

Every timestep the following actions must/may be performed:

Tasks & Subsystems

Enumerar Tasks i Subsystems

Task: Acció que transforma uns inputs fixos (DB) en uns outputs fixos (DB). Ex: Calcular dSdt a partir de S(t) i F(t)

Subsystem: Subsistema encarregat de fer Task complexa (Ex: CollDet)

Composició de Tasks => Animació

TODO:

KarmaPipeline.bmp

Karma Pipeline Illegally Ripped from the User Guide

Multiprocessor & Using the GPU

Cada Task es podria assignar a un cert processador.

La GPU seria un cas especial de processador, que podria fer algunes tasques també... cal veure quines i quina interfície caldria per minimitzar la transferència de memòria entre CPU(s) i GPU. => A Favoritos/GPU hi ha un link a articles sobre càlculs que es poden en la GPU, com resoldre S.Eq linials, simulacions de PDE, etc...

La pipeline es podria paral·lelitzar tenint en compte les branques disjuntes de la seqüència de càlculs que s'hagi de fer, i fins i tot es podrien balancejar els processadors usant estimacions conservadores sobre la duració de cada sub-seqüència de càlculs i els punts de sincronització entre aquestes!!

Ex de Tasks i paralelització:

Directed ANIMATION Graph :)

REDUNDANT... PARLAR-NE A composició de Tasks configurable a Tasks & Subsystems

A cada pas de temps l'animació requereix l'actualització ordenada de tots els objectes (o almenys d'aquells que depenguin d'altres objectes que han estat actualitzats) degut a les segons relacions de dependència de dades. Aquestes dependències es poden modelar amb un graf dirigit (DG), tal com ho fa Maya.

Casos difícils:

Variable Update Frequency for each System.

Control

Even though the actual implementation of useful/high-level controllers for animated objects is beyond the scope of Saphyre2, controllers should be easily built on top of Saphyre2 public functionality (API)

Several control paradigms on the animated objects should be supported:

Regarding Connectors ("geometric features"), they can be classified according to 2 categories:

This can be formalized saying that the Connector definition can be object-dependent and time-dependent: a( q_i, t )

For control purposes, the interesting uses of Connectors are:

Where any of the involved time-dependent Connectors can be controlled/animated externally by any of the Direct Control methods (including Interactive Control)

Thus, time-dependent Connectors should offer their outputs as animable DOF to the controllers.

Note:
Should allow COUPLING between time dependency and Object-DOF dependency?? => This has a low impact on the implementation, so by now the only supported Connectors are:
As some control strategies may try to drive the system into illegal configurations (constraint violation, for example), an error/event notification mechanism is needed to allow Saphyre2 report this kind of situations to the controllers.

DOF & Control

Estaria MOLT bé poder tenir control de cada DOF independent i definible per l'aplicació... algo en plan DAG del maya (o connect del Nebula2). Ex: Usar Animation Curve per controlar 1 sol DOF

Una manera de fer-ho seria que cada Object tingués un cert cjt de Controladors que han de ser considerats abans d'actualitzar-lo, i cadascun d'aquest pogués afectar a un o diversos DOF.

Note:
RESTRICTION: Each DOF can only be controlled by a single Controller at given time.

RESTRICTION: Only the DOFs can be directly controlled.

Caldria algun mecanisme per saber quins DOF controla cada Controlador:

Pensar-hi una mica més i decidir el grau de generalitat i complexitat que es vol, pq es podrien fer més coses com fer que els controladors depenguin uns dels altres, definir ordre d'aplicació (si canvien dades de l'obj que altres Controladors han de consultar l'ordre IMPORTA), etc... => Ja hi he pensat i NO consideraré aquest cas. L'ordre és indefinit, de moment.

Pensant en els objectes deformables i els esqueletals, el número de DOF és generalment elevat. Lo més flexible seria que cada DOF pogués estar controlat independentment (cada vèrtex d'un deformable podria ser cinemàtic o dinàmic)... probablement seria ineficient que fos així (MOLTS Controllers per un sol objecte), però en general això no passarà. Lo important és no fer que es cridi un Controller per cada DOF controlat sinó que es cridin "tots els Controllers de l'objecte" i una màscara indiqui quins són controlats i quins no... però en general no caldrà saber quin és el Controller que controla cada DOF sinó al revés, cada Controllers ha de saber quins DOF controla (passant-li un ptr al vector estat o un DOF_ID o algo així??) => Probablement és molt millor usar un DOF_ID que es mapegi fàcilment a l'estat que no un ptr, que ho limita a una variable concreta. => El DOF_ID pot ser un índex base en el vector estat de Reals, de manera que si el Controller modifica un V3D, la seva sortida s'escriurà en les posicions DOF_ID, DOF_ID+1 i DOF_ID+2 del vector estat.

==> M'imagino que això dels DOF_ID és lo que fa el Maya amb els Handlers de DOF... potser m'hauria de mirar el Maya amb més detall no ?-)

ALERTA: Els canvis en el tipus de gestió de cada DOF (simulat, animat, controlat, etc...) poden ser MOLT costosos (requerir reformar tota una matriu de resolució de restriccions quan un DOF passa de dinàmic a controlat cinemàticament, per exemple)

=> Per tant, en la majoria dels casos no crec que tingui gaire sentit admetre canvis incrementals/arbitraris, és molt més senzill reformar el que calgui tot de cop a partir de la nova situació (el control de diversos DOF pot haver canviat) => Reformar matriu sencera amb els nous DOF dinàmics, no afegir/treure files/columnes per cada DOF que canvia de gestió!

Animacio Cinemàtica

Animar els Object cinemàticament ha de ser fàcil i intuitiu. Caldria admetre:

L'animació cinemàtica s'hauria de poder usar:

Si es vol integrar animació keyframed a Saphyre2 potser caldria donar suport a l'animació (keyframes, interpolació, etc...) d'atributs que no siguin estrictament DOF cinemàtics...

Conclusion And Decisions

Several control schemes must be supported, but their final effect on the dynamics can be abstracted into a small set of cases:

The Saphyre2 Core will only have knowledge of this low-level control schemes. For performance reasons, however, it may be useful to integrate redundant control schemes into the Core (PD-Controllers, for example, can be implemented on top of Force Control, but managing them internally would be faster in most cases)

The bookkeeping overhead produced by the single DOF level control support should be minimized, and several very common cases must be efficiently handled:

Following the PayPerSim (tm) efficiency requirement, a possible implementation would be to have an optional ControlDescriptor structure attached that would be NULL for uncontrolled Objects.

class S2::Object::ControlDescriptor:

Under 2nd order dynamics hypothesis:

Again, the 1st and 2nd derivative computation mechanism should NOT add a significant overhead when not used.

As a programming simplification feature, attaching a general multi-DOF controller (3D velocity-controller, for example) should not fail if part of the DOFs that it tries to control are already controlled, but override their previous control scheme if it was less direct (q,q',q'' in decreasing directness order)

PayPerSim (tm)

The "pattern" used in the S2::ControlDescriptor situation (it must have a name, sure... I'll call it Optional Members and feel incredibly witty all about it until I find the actual name ok ?-) can be applied to other situations:

Decoupling API and Implementation

Hi ha una mica d'ambiguitat entre el que es pot fer amb els objectes (Object, Constraint, Controller, etc...) des de dins de Saphyre2 i des de l'aplicació, i segurament seria millor oferir a l'App una API que només permetés fer les accions necessàries, amagant la interfície interna que pot ser fins i tot inconsistent usar des de l'app. (o això a cal gestionar molt rígidament els permisos de crida dels mètodes (usar private i friend a saco), que tampoc m'agrada.

Saphyre1 tenia una API desastrosa, pq obligava a les Apps a fer subclasses dels objectes de simulació. Això s'ha d'evitar a tota costa (usar Saphyre2 per agregació, no per herència!)

ODE té una API en C molt desacoblada de la implementació i bastant senzilla i coherent, però una mica engorrosa pel meu gust, pq obliga a usar ID's d'objectes i funcions que treballen sobre tipus concrets d'objectes... La trobo coherent però rústica, i no m'agrada com queda escrit el codi.

Mathengine té una API similar a la de ODE, també en C i bastant farragosa des del meu punt de vista.

La pregunta és, quines característiques vull que tingui la API de S2?

Una idea:

En resum, els XXXXAPI oferirien a l'App les funcionalitats i la interfície més còmoda i simple possible, ocultant tota la complexitat interna de S2. Afegiria una mica d'overhead d'interfície/crides a funcions i de conversió de dades, però això no hauria de ser greu pq només es farà com a molt 1 cop per cada objecte per cada dt. Molts mètodes podran ser directament crides a mètodes dels objectes interns.

Aquesta API tb és la que s'hauria de poder accedir des d'scripts, però de moment d'això passo.

Conclusió i Decisions

Veure Saphyre2 API.

Direct Manipulation of Physics Objects from the App.

[OSCAR]: Això està més o menys resolt si s'implementa bé S2API. Els canvis que l'App vol fer al món simulat es podran analitzar en S2API i demanar a S2 que faci les sincronitzacions necessàries (com per exemple testejar si una posició "editada" d'un objecte generaria interseccions, si una velocitat "editada" violaria les restriccions, etc...)

Inicialització i canvis de valors físics des de l'aplicació:

Això és molt important, pq un canvi de posició, per exemple, pot fer que 2 objectes que no xocaven dins Saphyre2 passin a estar intersectant-se fent un canvi extern "discontinu" de posició. El mateix passa amb les velocitats, que si es canvien "a saco" des de fora poden passar a violar les restriccions.

Per tant cal:

Mathengine té una manera de definir "change blocks" dins els quals es poden fer canvis sobre els objectes simulats.

Partitioned Dynamics and Asymmetric Interactions

Interactions between Objects do not always need to couple them tightly and/or affect them in the same way.

We may want to constrain a dynamic particle move on a surface attached to a dynamic Rigid Body and let the movement of the rigid body influence the particle but not the other way round. In this case, the Rigid Body movement would not depend on the Particle's, and therefore could be computed independently (even in a different Solver and/or using a different simulation method).

Shortly, the Rigid Body would act as if it was Kinematic from the Particle's point of view.

Should we fit this in the standard ObjectA <- Interaction (Constraint) -> ObjectB framework by specifying if an object acts as Kinematic or Dynamic in the Interaction or we'd better treat this case as ObjectA controlling ObjectB?

We should also consider the difference between intra-system and inter-system interactions. While the first case should be natively solved (contacts and constraints), the second one couples the simulation of 2 or more systems and therefore must be treated in some way:

Events i Discontinuitats

There should be a mechanism for reporting simulation/animation events to the App. Events that may be interesting for the App include:

An S2API::IEventListenerAPI interface class should be defined to allow the Apps instantiate it and register themselves to S2 for receiving some/all event types.

Discontinuitats

Events => Discontinuitats:

Note:
De moment PASSO d'això de les discontinuitats

Contactes amb fricció simplificada

La majoria de mètodes per resoldre contactes són menys fiables quan hi ha fricció que quan no n'hi ha. Perquè??? És per les propietats de les matrius involucrades, crec, però no acabo de veure el motiu físic si és que n'hi ha.

=> En qualsevol cas, pq no provar algun model de fricció que eviti aquest problema???

a) Forces de fricció i forces normals estan acoblades pel model de fricció de Coulomb, però i si les desacobléssim artificialment:

b) Model de fricció diferent al de Coulomb:

=> JAJAJAJAJA... altre cop: a) és justament el que fa ODE... o algo semblant... ho diu a la documentació.

Contact Tracking

Instead of detecting contacts every timestep, track them (using the motion between timesteps) i order to predict their next position (ideas from WalkOnSurface could be used here...)

I'm pretty sure people is doing this... at least to smooth the contact handling along time (to achieve better continuity)

Instances

Seria interessant admetre instanciació d'objectes pesats:

Bulletproof Mode

There could be a "bulletproof" simulation mode that checked for all possible sources of numerical errors/unstability and adapted to it (or reported/logged the reason to the user/app).

This would be very useful in prototyping simulations. Reporting the source of error would help to tune the simulation parameters to make it stable in the "relaase mode".

This could be implemented as a compilation time option, but it would be far more interesting to have the option to switch the simulation mode interactively, so, maybe implementing 2 code-paths for all solvers that may encounter numerical errors is better.


Generated on Tue Aug 10 15:58:31 2004 for Saphyre2 by doxygen 1.3.5