[Opal-commits] opal todo.txt,1.27,1.28
Status: Inactive
Brought to you by:
tylerstreeter
Menu
▾
▴
[Opal-commits] opal todo.txt,1.27,1.28
|
From: tylerstreeter <tyl...@us...> - 2005-02-08 21:55:07
|
Update of /cvsroot/opal/opal In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18602 Modified Files: todo.txt Log Message: added a Sensor class Index: todo.txt =================================================================== RCS file: /cvsroot/opal/opal/todo.txt,v retrieving revision 1.27 retrieving revision 1.28 diff -C2 -d -r1.27 -r1.28 *** todo.txt 8 Feb 2005 04:59:07 -0000 1.27 --- todo.txt 8 Feb 2005 21:54:25 -0000 1.28 *************** *** 18,21 **** --- 18,36 ---- - Force + Object Properties + - user managed vs. OPAL managed + + Document + ======== + * objects with init functions - call init immediately after construction + + * init functions enable objects + + * most objects are created and destroyed by the Simulator, but some are user-managed + - examples of user-managed: + - most structs + - custom motors + + Immediate ========= *************** *** 23,29 **** * add 'web' and 'doc' modules to repos * Questions ! - do all class member functions need to specify calling convention? - does event handler interface need to specify calling convention? does it need a destroy function? * remove huge parameter lists from constructors / simulator construction methods --- 38,51 ---- * add 'web' and 'doc' modules to repos + * fix SCons files (rename source files) + * Questions ! - do all class member functions need to specify calling convention? just public - does event handler interface need to specify calling convention? does it need a destroy function? + - since the Simulator handles all memory internally, do we even need special destroy functions for everything? no, just things that get deleted on the user's end + + * remove destroy functions from most objects; make their destructors public again + + * for most objects (e.g. joints, sensors, motors) should we have multiple create functions that each return different types, or just one create function (which returns a single type ptr), then call init in different ways to create different types? * remove huge parameter lists from constructors / simulator construction methods *************** *** 34,38 **** - Sensor ! - solution: empty constructors, set params to default valFues - if there are necessary params, use an init function - internal-only constructors (e.g. ODESolid) can still take params --- 56,60 ---- - Sensor ! - solution: empty constructors, set params to default values - if there are necessary params, use an init function - internal-only constructors (e.g. ODESolid) can still take params *************** *** 51,68 **** - how do different descs refer to other objects? by name? by int id? - examples: ! - SolidDesc (contains many ShapeDescs) ! - ShapeDesc ! - JointDesc ! - MotorDesc ! - SensorDesc * add "sensors"; could the event handler be replaced with these? ! - ray casting/rangefinder: measures distance from sensor to first intersection (attach to a solid [be sure to ignore collisions with the attached solid] or nothing) ! - contact: holds a queue of contact events (attach to a solid, to a single shape, or to nothing?) ! - velocimeter: linear vel sensor ! - linear accelerometer: linear accel sensor ! - inclinometer: angular pos sensor; measures angle between initial and current orientation ! - gyroscope: angular vel sensor ! - angular accelerometer: angular accel sensor * shape class --- 73,90 ---- - how do different descs refer to other objects? by name? by int id? - examples: ! - SolidDesc (contains many ShapeDescs, or maybe just references to them) ! - ShapeDesc ! - JointDesc: refers to SolidDescs ! - MotorDesc: refers to SolidDescs and/or JointDescs ! - SensorDesc: refers to SolidDescs * add "sensors"; could the event handler be replaced with these? ! - need an update function ! - types: ! - 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) ! - ContactSensor: holds a queue of contact events (attach to a solid, to a single shape, or to nothing?) ! - VelocitySensor: linear vel (i.e. "velocimeter") and/or angular vel ("gyroscope") sensor ! - AccelerationSensor (i.e. "accelerometer"): linear and/or angular acceleration sensor ! - InclineSensor (i.e. "inclinometer"): measures angle between initial and current orientation * shape class *************** *** 86,94 **** * 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). ! * rename motors? ! - "effectors" ! - "actuators" ! ! * remove address accessor to matrix (too dangerous for new users?) - solution: keep and document, or remove? --- 108,112 ---- * 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). ! * remove address accessor to Solid transform (too dangerous for new users?) - solution: keep and document, or remove? *************** *** 97,100 **** --- 115,123 ---- - update instantiation functions + * event handling/callbacks + - collisions + - broken joints + - beginning of step + Build System ============ *************** *** 108,114 **** --- 131,147 ---- ============== + * move includes from headers to cpp files wherever possible + + * change the internal_dependsOn functions -> have bidirectional references (dependency lists) so we don't have to search lists for dependencies + * Joints: - add a JointAxis struct? + * Put BlueprintManager stuff into the Simulator itself and remove BlueprintManager? + + * contact filtering + - averaging + - other methods? + * in the cases where overloaded functions call the original function (e.g. derived setParam calls parent class setParam function), should we keep it this way? or should the overloaded version just do everything? |
