Commit 26198767 authored by Jan Möbius's avatar Jan Möbius

Docu update

git-svn-id: http://www.openflipper.org/svnrepo/OpenFlipper/branches/Free@5477 383ad7c9-94d9-4d36-a494-682f7c89f535
parent 4d561120
......@@ -94,7 +94,8 @@ WARN_LOGFILE =
# configuration options related to the input files
#---------------------------------------------------------------------------
INPUT = . \
../ObjectTypes
../ObjectTypes #\
# ../ACG/Scenegraph
INPUT_ENCODING = UTF-8
FILE_PATTERNS = *.c \
*.cc \
......
/** \page dataStructure Datastructures
*
* \section Overview
* All objects in OpenFlipper are handled by the core. To create and delete objects use
* the functions provided in PluginFunctions and BaseObject.
*
*
* All Objects have to be derived from the BaseObject. For the predefined Objeccts this is
* already the case. In BaseObject a tree structure is implemented. You can use the functions
* in BaseObject to search for items and access them. A root Object is created by OpenFlipper
* which is the root of the object tree. You can get it via PluginFunctions::objectRoot().
* which is the root of the object tree. You can get it via PluginFunctions::objectRoot(). There
* is also a groupobject which holds no data and is used for grouping different objects.
*
* All objects in OpenFlipper are handled by the core. To create and delete objects use
* the functions provided by the LoadSaveInterface.
*
* \section Loading data and existing types
* If you want to load or delete data from within your plugin and you only use existing types
* you can derive from the LoadSaveInterface. This interface provides load and save functions
* to tell the core that you want to access existing data types.
*
* \subsection DataAccess Access to data from within the Plugins
* From each plugin you have to get access to the data. Functions to get the right data are provided in the
* PluginFunctions Namespace. Here are all functions which should be used to access the data. Most of the
* time you will use the ObjectIterator defined there. If you need consistent data access during the plugin
* lifetime (e.g. you have to track one mesh during the plugin lifetime) you should use the identifiers made
* available in this namespace which never change.\n \n
* It is possible that the vector containing the objects changes during the plugin lifetime (added or deleted objects).
* Only the identifiers will stay constant. If one of these changes occurs, the main application will call
* BaseInterface::updatedObject() of all Plugins containing the id of a changed object or -1 if an object
* has been deleted. LoadSaveInterface::objectDeleted() will tell you if an object is deleted.
* If you have to keep track of these changes, implement these functions.
*
* \section basicObjectTypes Basic object types
* \subsection baseObjectDescription BaseObject
......@@ -15,15 +35,35 @@
* functions. It creates a tree structure of all available objects, includes object
* selection, name and type information. It does not contain any code to visualize
* objects.
* Each object derived from BaseObject has a datatype function BaseObject::dataType.
*
* Additionally you can add data to each object by using the perObjectData class.
* See PerObjectData
*
* \subsection baseObjectDataDescription BaseObjectData
* This class is derived from BaseObject and includes basic visualization functions. It creates
* the basic scenegraph nodes for the object ( TODO : See per Object Scenegraph structure ).
*
* For every object, the top scenegraph node is the ObjectData::SeparatorNode*. All other
* nodes ( including per object custom nodes ) have to be added below this node. Additionally
* an ManipulatorNode is added below the separator node. This manipulator is used to move
* or transform the object. Normally this node is managed by the move plugin. If you
* use per object nodes which should be transformed along with the object you can attach
* them below this node ( BaseObjectData::manipulatorNode() ).
*
* Additionally per object scenegraph nodes can be managed automatically by BaseObjectData.
*
*
* \subsection MeshObjectDescription MeshObject
* MeshObject is the class representing triangle or poly meshes. It uses OpenMesh as its
* dataStructure.
* data structure.
* It is based on BaseObjectData and adds additional scenegraph nodes. First it creates a materialNode
* used to set the meshes rendering material properties, followed by a texture node ( MeshObject::textureNode() ). A shader node ( MeshObject::shaderNode() ) is than
* added to manage the systems and user defined shaders. Below the shader node is the mesh node ( MeshObject::meshNode() )which actually
* renders the mesh.
* Additionally some nodes to render selection, features or modeling areas are added by the MeshObject
*
* See MeshObject for the detailed function documentation.
*
*
* \section creatingCustomObjectTypes Creating custom object types
......
......@@ -4,9 +4,13 @@
*
* This is the developer documentation for the OpenFlipper project.
* OpenFlipper is a flexible geometry modeling and processing system.
* Only basic functionality like gui and data managment is done by the core of the application.
* All additional functionality is provided by plugins. The core also manages the communication
* between the plugins and their load/unload.
* OpenFlipper consists of the core application and a set of plugins. Only
* the minimal required functionality is implemented inside the core. Plugins
* can be written to extend OpenFlipper and provide new data types,
* processing functions or user interface modifications. All these plugins
* are managed by the core. This manual describes how OpenFlipper plugins
* can be created and how they can communicate with the core. There are of
* course examples for a quickstart into OpenFlippers plugin interface.
*
* This manual is divided into the following pages:
* - \subpage uiconcept "User Interface Concepts"
......@@ -17,38 +21,6 @@
* - \subpage dataFlow "Dataflow"
*
*
* \section BasicPlugins Basic Plugins
* \subsection Datacontrol Datacontrol
* Manages the available objects in a table. Allows modification of visibility and source target selection.
*
* \subsection Texturecontrol Texturecontrol
* Manages the available textures and their update.
*
* \section DataStructure DataStructure
* All data is stored in a tree structure containing ObjectData Objects. When a new object is created,
* the ObjectData::dataType is set to the correct value. \n
* Visible objects have to be derived from the BaseObjectData class. This class provides the basic nodes for the Scenegraph
* and name or path handling. \n
* For every object, the top node is the ObjectData::SeparatorNode
* You should add all custom nodes which belong to an object below this node. Below the Seperator Node is a
* ObjectData::ManipulatorNode. This Node is controlled by the MovePlugin. If you want your objects to move
* with the main object, place them below this node.
* For meshes ( PolyMesh or TriMesh ) the MeshObject classes are used. Below the ManipulatorNode is a Status Node and a texture node for a mesh.
* Below the texture node is a material node and below the material node is a meshnode.\n
* For additional nodes the vector ObjectData::additional_nodes is created. You should not access it directly but use PluginFunctions::addAdditionalNode
* and PluginFunctions::getAdditionalNode.\n
*
* \subsection DataAccess Access to data from within the Plugins
* From each plugin you have to get access to the data. Functions to get the right data are provided in the
* PluginFunctions Namespace. Here are all functions which should be used to access the data. Most of the
* time you will use the ObjectIterator defined there. If you
* need consistent data access during the plugin lifetime (e.g. you have to track one mesh during the plugin
* lifetime) you should use the identifiers made available in this namespace which never change.\n \n
* It is possible that the vector containing the objects changes during the plugin lifetime (added or deleted objects).
* Only the identifiers will stay constant. If one of these changes occurs, the main application will call
* BaseInterface::slotObjectUpdated() of all Plugins. If you have to keep track of these changes, implement it in
* this function.
*
* \section DefaultOptions Default Options and Options loaded from OpenFlipper.ini
* OpenFlipper.ini is read on application startup. Most of the options will also be accepted if another inifile is opened at application runtime. There can be multiple OpenFlipper.ini files. The application will look in the base path of the executable and in your home directory under ~/.OpenFlipper/OpenFlipper.ini \n
* Currently supported options:\n
......
This diff is collapsed.
......@@ -264,8 +264,8 @@ class DLLEXPORT BaseObjectData : public BaseObject
* This function can be used to store an additional Scenegraph node. If you add nodes there, you do not
* need to keep track of deleted, added objects, as this will be done in the main application.
* You have to create the node yourself as this function does not know the type. You should add the
* new node below the manipulatorNode if you want that it moves with the rest of the data. Otherwise
* add it below the seperatorNode of the object.
* new node below the manipulatorNode ( BaseObjectData::manipulatorNode() ) if you want that it moves with the rest of the data. Otherwise
* add it below the baseNode ( BaseObjectData::baseNode() of the object.
*
* @param _node Node to add
* @param _pluginName Name of the current plugin
......
......@@ -57,6 +57,14 @@
//== CLASS DEFINITION =========================================================
/** \brief Object Payload
*
* This class is used to add arbitrary data to objects
* in OpenFlipper. You can derive any kind of class from
* PerObjectData and attach it to an object. See
* BaseObject::setObjectData() for more details.
*
* */
class DLLEXPORT PerObjectData {
public :
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment