Update of /cvsroot/opal/opal
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5467
Modified Files:
readme.txt todo.txt
Log Message:
removed the Ray Shape; it should only be used for raycasting, not as an actual Shape attached to Solids
Index: todo.txt
===================================================================
RCS file: /cvsroot/opal/opal/todo.txt,v
retrieving revision 1.49
retrieving revision 1.50
diff -C2 -d -r1.49 -r1.50
*** todo.txt 4 Mar 2005 23:26:53 -0000 1.49
--- todo.txt 5 Mar 2005 21:26:23 -0000 1.50
***************
*** 2,9 ****
=================
! * look at scons dylib-building problem on os x
! * add scons examples to readme
! - mention that paths might need to be full paths
* fix memory allocation across dll boundary
--- 2,10 ----
=================
! * remove ray and plane from the usual set of shapes?
! - Simulator::createPlane; this might cause problems since the plane needs Material, collision group, etc.
! - ray is just used for raycasting anyway, it'll be used in the raycast sensor
! * look at scons dylib-building problem on os x
* fix memory allocation across dll boundary
***************
*** 25,39 ****
* 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
=================
- * custom sensors?
-
* search and replace existing assert() calls
- fatal errors print a message and assert
--- 26,36 ----
* reenable collision detection for static-static, static-sleeping cases (or have an option)
+ - solution: probably use collision groups for this
* make trimeshes work
For Version 0.4.0
=================
* search and replace existing assert() calls
- fatal errors print a message and assert
***************
*** 46,54 ****
- 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?)
- use callback functions
- user-derived class
- vital part of "trigger volumes"
- VelocitySensor: linear vel (i.e. "velocimeter") and/or angular vel ("gyroscope") sensor
- AccelerationSensor (i.e. "accelerometer"): linear and/or angular acceleration sensor
--- 43,54 ----
- 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)
! - CollisionSensor
! - hold a queue of collision events (attach to a solid, to a single shape, or to nothing?)
- use callback functions
- user-derived class
- vital part of "trigger volumes"
+ - not available in XML because they're derived; ignore these when saving and loading
+ - JointBreakSensor
+ - not available in XML because they're derived; ignore these when saving and loading
- VelocitySensor: linear vel (i.e. "velocimeter") and/or angular vel ("gyroscope") sensor
- AccelerationSensor (i.e. "accelerometer"): linear and/or angular acceleration sensor
***************
*** 73,76 ****
--- 73,80 ----
* separate Motors with different modes into separate types?
+ * use custom motors?
+ - for one thing, we can't use them in xml
+ - if we use them, should we also have custom sensors?
+
Build System
============
Index: readme.txt
===================================================================
RCS file: /cvsroot/opal/opal/readme.txt,v
retrieving revision 1.35
retrieving revision 1.36
diff -C2 -d -r1.35 -r1.36
*** readme.txt 3 Feb 2005 21:07:56 -0000 1.35
--- readme.txt 5 Mar 2005 21:26:23 -0000 1.36
***************
*** 30,33 ****
--- 30,53 ----
Use the provided SConstruct (on any platform) to build a shared library for OPAL. A target physics engine is required (e.g. "scons ODE"). Type "scons -h" to get a description of targets and build options. The "install" target can be used to copy the headers and compiled library to some user-defined location.
+ For example, to build the OPAL library with ODE support, type:
+
+ scons ODE
+
+ This should generate opal-ode.so or opal-ode.dll, depending on the platform. Note that it builds the optimized version by default. To build the debug version without XML support, type:
+
+ scons ODE debug=true XML=false
+
+ You can specify additional include and library paths like this:
+
+ scons ODE extra_include_path=/path/to/includes extra_lib_path=/path/to/libs
+
+ Finally, to install the OPAL headers and library, do this:
+
+ scons ODE install prefix=/path/to/install/dir
+
+ This will create "include" and "lib" directories if they don't exist in the given prefix. The "install" will automatically make sure the built library is up-to-date. You can actually just type "scons ODE install prefix=/path/to/install/dir" to have SCons build and install everything.
+
+ Be aware that any paths used here should be full paths, not relative ones.
+
------------------------------------
|
