[Opal-commits] opal todo.txt,1.42,1.43

[tylerstreeter <tyl...@us...>]

Update of /cvsroot/opal/opal
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10148

Modified Files:
	todo.txt 
Log Message:
added MotorData and JointData classes

Index: todo.txt
===================================================================
RCS file: /cvsroot/opal/opal/todo.txt,v
retrieving revision 1.42
retrieving revision 1.43
diff -C2 -d -r1.42 -r1.43
*** todo.txt	21 Feb 2005 15:54:43 -0000	1.42
--- todo.txt	23 Feb 2005 03:58:24 -0000	1.43
***************
*** 1,52 ****
- Objects
- 	- classes
- 		- Simulator
- 		- Solid
- 		- Joint
- 		- Motor
- 		- Sensor
- 		- Blueprint
- 	- Data objects
- 		- dependencies
- 			- Solids -> nothing
- 			- Joints -> Solids
- 			- Motors -> Joints, Solids
- 			- Sensors -> Joints Solids
- 		- SolidData
- 			- enabled
- 			- variable number of ShapeDatas (*actual or references?)
- 		- ShapeData (many different types)
- 			- Shape type
- 			- maybe have a MeshData too to assist Mesh creation?
- 		- JointData
- 			- enabled
- 			- Joint type
- 			- 2 SolidData references
- 			- anchor point
- 			- 3 Joint axes (unneeded axes will be ignored)
- 		- MotorData (many different types)
- 			- enabled
- 			- Motor type
- 			- constant number of SolidData references
- 			- constant number of JointData references
- 		- SensorData (many different types)
- 			- enabled
- 			- 0 or 1 SolidData references
- 		- Blueprint: contains lots of Data objects
- 	- other structs
- 		- Material
- 		- RayHit
- 		- collision event
- 		- Force
- 		- Joint axis
- 			- vector/direction
- 			- limit
- 			- limit enabled
- 		- Joint limit
- 			- low, high value
- 			- hardness
- 			- bounciness
- 
- 
  For Version 0.3.0
  =================
--- 1,2 ----
***************
*** 61,66 ****
  * all objects have an init function that takes a data object
  
- * should simulator create functions take data objects to initialize things automatically?
- 
  * look at scons dylib-building problem on os x
  
--- 11,14 ----
***************
*** 80,88 ****
  * all modes with multiple options (e.g. spring motor, accel sensor) should take bit flags
  
- * all structs have constructors (that use default params)
- 
- * all object constructors:
- 	- instead of setting params from defaults directly, create a BP (which automatically uses the defaults params), then call loadFromBP
- 
  * "BP" (blueprint) structs/classes
  	- all parameters use defaults from Defines.h
--- 28,31 ----
***************
*** 103,108 ****
  		- BPs can be requested by name/ID
  
- * joint setup: put setSolids, axes, and anchor in a single function
- 
  * reenable collision detection for static-static, static-sleeping cases (or have an option)
  
--- 46,49 ----
***************
*** 120,125 ****
  * 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).
  
- * for objects with multiple types (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 (or loadFromBP) to create different types?
- 
  * change description (on website and sf project page) to highlight the main attractions
  	- cross-platform
--- 61,64 ----
***************
*** 192,195 ****
--- 131,139 ----
  
  * change the internal_dependsOn functions -> have bidirectional references (dependency lists) so we don't have to search lists for dependencies
+ 	- dependencies
+ 		- Solids -> nothing
+ 		- Joints -> Solids
+ 		- Motors -> Joints, Solids
+ 		- Sensors -> Joints Solids
  
  * Put BlueprintManager stuff into the Simulator itself and remove BlueprintManager?
***************
*** 281,284 ****
--- 225,252 ----
  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
  ========