[Opal-commits] opal todo.txt,1.46,1.47
Status: Inactive
Brought to you by:
tylerstreeter
Menu
▾
▴
[Opal-commits] opal todo.txt,1.46,1.47
|
From: tylerstreeter <tyl...@us...> - 2005-03-01 05:04:35
|
Update of /cvsroot/opal/opal In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21242 Modified Files: todo.txt Log Message: fixed bugs in xml blueprint loading; added ragdoll xml file to sample app Index: todo.txt =================================================================== RCS file: /cvsroot/opal/opal/todo.txt,v retrieving revision 1.46 retrieving revision 1.47 diff -C2 -d -r1.46 -r1.47 *** todo.txt 26 Feb 2005 10:22:22 -0000 1.46 --- todo.txt 1 Mar 2005 05:04:24 -0000 1.47 *************** *** 2,20 **** ================= - * fix crashing problem when instantiate ball joint from example.xml - * look at scons dylib-building problem on os x * add offset transform to instantiateBlueprint * fix memory allocation across dll boundary - - Blueprint - - BlueprintInstance - volume collision check results -> put results in a specific class ! * certain function calls (e.g. setStatic) during collision events crash the system - solution: create an event queue and call the functions at a safe time - per step, or per frame? - replace 'garbage' system with delayed destroy events * Add a boolean to Solid that determines if it generates contacts at all (the docking volume shouldn't collide with anything but should generate collision events still). --- 2,25 ---- ================= * look at scons dylib-building problem on os x * add offset transform to instantiateBlueprint + * add a "scale" constant to instantiateBlueprint + - applies to shape sizes and transforms + * fix memory allocation across dll boundary - volume collision check results -> put results in a specific class ! * certain function calls during collision events crash the system ! - definitely bad: ! - setStatic, setPosition, setTransform, setVelocity, setSpace, addShape, setSleeping, simulator::destroySolid/Joint, etc. ! - maybe bad: ! - setEnabled, translateMass - solution: create an event queue and call the functions at a safe time + - don't use events when it's already "safe" (i.e. not in collision detection mode), just apply them instantly; i.e. have a "safe" boolean that's set to false only when in collision detection - per step, or per frame? - replace 'garbage' system with delayed destroy events + - alternative solution: just make collision callback calls happen at the end of the step; but this could be a problem because sometimes you might want to ignore contacts... but maybe it wouldn't matter if we don't return the boolean from the collision events and used some other contact-generation flag system (i.e. the "category/collide" bits); how should we handle this? * Add a boolean to Solid that determines if it generates contacts at all (the docking volume shouldn't collide with anything but should generate collision events still). *************** *** 23,26 **** --- 28,35 ---- * reenable collision detection for static-static, static-sleeping cases (or have an option) + * make trimeshes work + + * get rid of custom motors? + - for one thing, we can't use them in xml For Version 0.4.0 *************** *** 31,43 **** - non-fatal errors just print a warning - * add 'web' and 'doc' modules to repos - - maybe just add 'web' module that contains docs - - post either zipped docs or hyperlinked pdf of docs - * implement sensors ! - RayCastSensor (i.e. "PSD (position sensitive detector)" or "rangefinder"): measures distance from sensor to first intersection (attach to a solid [be sure to ignore collisions with the attached solid] or nothing) - not updated regularly; must be updated manually by user ! - VolumeSensor (i.e. "proximity sensor?"): similar to RayCastSensor, but for a volume; finds all Solids colliding with a given (attached) Solid - not updated regularly; must be updated manually by user - ContactSensor - hold a queue of contact events (attach to a solid, to a single shape, or to nothing?) --- 40,49 ---- - non-fatal errors just print a warning * implement sensors ! - RaycastSensor (i.e. "PSD (position sensitive detector)" or "rangefinder"): measures distance from sensor to first intersection (attach to a solid [be sure to ignore collisions with the attached solid] or nothing) - not updated regularly; must be updated manually by user ! - VolumeSensor (i.e. "proximity sensor?"): similar to RaycastSensor, but for a volume; finds all Solids colliding with a given (attached) Solid - not updated regularly; must be updated manually by user + - should this be combined with trigger solids? probably not: ProximitySensors are one-time, triggers are always updated (triggers are actually just solids with a ContactSensor and don't generate contact joints) - ContactSensor - hold a queue of contact events (attach to a solid, to a single shape, or to nothing?) *************** *** 49,52 **** --- 55,62 ---- - InclineSensor (i.e. "inclinometer"): measures angle between initial and current orientation + * dynamic number of contact joints? + - depends on types of objects + - contact filtering? + * event handling/callbacks - collisions *************** *** 59,63 **** * should all modes with multiple options (e.g. spring motor, accel sensor) take bit flags? ! * separate Joint into separate subclasses? * separate Motors with different modes into separate types? --- 69,73 ---- * should all modes with multiple options (e.g. spring motor, accel sensor) take bit flags? ! * separate Joint back into separate subclasses? * separate Motors with different modes into separate types? *************** *** 109,115 **** - shapes simply use a material name - * try to fix weird inheritance with Joint, ODEJoint, HingeJoint, ODEHingeJoint, etc. - - possible solution: remove ODEJoint; make common ODE Joint functions global functions in a hidden namespace - * handle blown frame cases: - desired frame rate (max dt)? ask ace... --- 119,122 ---- *************** *** 134,140 **** --- 141,149 ---- - ragdoll (launched out of a canon?) - + * search code for TODOs * blueprints could have a single boolean space parameter like "insert the whole bp into a space or not" + - this could even just be a bool passed to the instantiate function Long-term Ideas *************** *** 161,261 **** - doesn't need to be updated every step (maybe once per second) - Website Contents - ================ - * change log somewhere? - - * documentation - - manual - - general description of main objects - - tutorials - - basic tutorial showing all types of object creation - - user-derived classes - - doxygen source docs - * user projects - - rhino - - radius - - cabin - - switcher - * contact - - our names, bios, email addresses? - - Preliminary Manual Notes - ======================== - OPAL is a high-level abstract interface for physics engines in games and other real-time 3D applications. It simplifies common physics tasks and provides a physics engine-independent API that can be extended to support new physics engines. - - ------------------------------------ - - The main objects in OPAL are: simulators, solids, joints, and motors. Create a simulator, have the simulator create solids for you, add shapes to the solids, and add forces to the solids. Solids can take an initial matrix transform. Shapes added to a solid can take a matrix transform as an offset from the solid's center. A solid can return its transform matrix for drawing purposes (if a solid has multiple shapes, be sure to save their offset matrices for drawing later). Solids can be static, meaning that they don't move around in the simulation. - - Objects - - classes - - Simulator - - Solid - - Joint - - Motor - - Sensor - - Blueprint - - Data objects - - SolidData - - ShapeData (many different sub-types) - - Shape type - - JointData - - MotorData (many different sub-types) - - SensorData (many different sub-types) - - Blueprint: contains lots of Data objects - - other structs - - Material - - RayHit - - collision event - - Force - - Joint axis - - Joint limit - - Document - ======== - * doxygen - - put manual, etc. on main page - - document all namespaces - - use multi-line comments? (single-line appears in short description) - - finish documenting all functions, data members - - post on website - - * specific object type properties - - memory management: user managed vs. OPAL managed - - initially enabled or disabled - - user-created classes - - ContactSensor - - JointBreakSensor - - custom Motors - - * Most objects can be created in two ways - - create the object (automatically uses default values); change specific parameters - - setup a Data object and pass it into the object's init function - - some objects (e.g. Joints) must have init called before using them - - * Shapes can be added to solids in two ways - - add a ShapeBP to a SolidBP, then create the Solid - - create a Solid, then add a shape by passing it a ShapeBP - - * custom motors cannot be saved to/loaded from an XML file - - * for derived classes (custom motors, event handlers), put OPAL_CALL in front of public function names - - * most objects are created and destroyed by the Simulator, but some are user-managed - - examples of user-managed: - - most structs - - custom motors - - event handlers - - * all angles are in degrees - - * be aware of floating point accuracy issues - - use the same precision for OPAL reals and ODE dReals - - * two ways to create objects - 1.) have the simulator create the object with default settings, then set its parameters manually - Solid* s = sim->createSolid(); - s->setStatic(true); - s->setTransform(Matrix44r()); - 2.) have the simulator create the object by passing in a blueprint --- 170,172 ---- |
