Hi Vijeesh, here is some explanation how the SLOT mechanism works currently:
it is a list of SLOT classes. A slot class contains the following members: * string name * double value * string sValue (string value) * enum direction: TO_OBJ | FROM_OBJ * enum type: STRING | DOUBLE If a software module wants to store some values which are directed TO the visual Objects ( e.g. object3_LAT), it searches in this list for the slot with the corresponding name, type and direction and stores the value in it. The object updater for example reads on every update in this slot list for a slot with the appropriate name and read the value to apply it to its own object. This has the the following implications: * Supposed to be very slow if lot's of variables are used: if someone searches in the list, he has to perform many string comparisons. * Only strings and doubles can be stored but no complex data structures ( e.g. cigi containers) My approach with the "slots" was only a "first shot". I would be very glad if we could discuss this, maybe also with other users in the forum. It would be great to construct a more sophisticated and usefull architecture to manage the data of the IG. After that I would implement this solution asap, but currently I have no idea in which direction we should proceed. Thank you! Cheers, Torben ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38007#38007 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
