Hi, I now use a different approach because time is an issue, but the idea was as follows. I wanted to make a node which is multitouch-aware. There is a manager which is receiving all the multitouch events and it keeps a map of the nodes which can be controlled. If an event is received, it asks all the nodes in its map if the ray hits their bounding box and if so, the node will also receive all position updates of that event. The node should also be responsible of handling the event even if it leaves the bounding box. This means that the node needs to keep a set<id> of the events it is responsible for. Therefore I thought it would be good idea to derive from OSGNode. There is no use in syncing the extra data that is needed as usually the multitouch events are only handled on the client. However, the algorithms will modify an OSGTransform core which is attached to the node, and which will be synced. Additionally implementing the stuff in the core doesn't make sense as attaching such a core to multiple parents is not possible and does only make the code more complicated (think about getting the bounding box for example). On the other side, attaching the Transform to multiple nodes might make sense in special cases. I hope that clears it up why I came up with the idea.
My implementation now is a struct which holds the set<id> along with a Node* and some other data, and the manager holds a vector of that struct. So all nodes in the scenegraph which need to be multitouch-aware need to have a node with a transform core which is then added to the manager. Seems to work so far. Aloha, Andi > -----Original Message----- > From: Dirk Reiners [mailto:dirk.rein...@gmail.com] > Sent: Mittwoch, 24. Februar 2010 18:23 > To: opensg-users@lists.sourceforge.net > Subject: Re: [Opensg-users] deriving from OSGNode > > > Hi Andreas, > > On 02/24/2010 10:42 AM, Carsten Neumann wrote: > > > > I'm not aware of anyone deriving from Node before, there may be code > > that assumes nothing derives from Node, although off the top of my > head > > I could not point at anything in particular. > > > >> In my case it seems to make sense as the functionality I > >> am implementing depends only on the bounding volume and there is no > data to > >> sync - only the attached NodeCore (which would be a Transform > NodeCore) > >> would be synched. > > > > hm, maybe. What do you want to do? ;) > > That would be my question, too. In general we tried to keep the Node > backbone > uniform to avoid confusion. What do you need to do? > > Dirk > > ----------------------------------------------------------------------- > ------- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Opensg-users mailing list > Opensg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/opensg-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
