I ran into the same problem some time ago with osg 1.6. Same was true in 1.8. Haven't tried 2.0. See this thread:
http://www.mail-archive.com/[email protected]/msg07877.html I never got the suggested method to work - instead I relegated all OSG stuff to my applications main thread. In my case I didn't need to separate the OSG stuff into separate threads, so I didn't care too much. I should also point out that I use a low-latency real-time patched linux kernel......which may have had something to do with the threading difficulties. I suspect the suggested method will work fine with ordinary kernels. Good luck! Dan Adrien wrote: > Hi, > I've some problem with OpenSG thread, > In my main function I create 3 node, a geometry > node, attach to the material group node, attach to > the transformation node. > At that point no problem, my object corectly appear in the scene. > > Then I need to update it's geometry with information got via the network, > I implemented in my class a method that construct and return a > geometry node: > > NodePtr grimageMesh::createGeometry(){ > NodePtr N = Node::create(); > GeometryPtr geo = Geometry::create(); > GeoPositions3fPtr points =GeoPositions3f::create(); > GeoIndicesUI32Ptr index = GeoIndicesUI32::create(); > GeoPLengthsPtr lens = GeoPLengthsUI32::create(); > GeoPTypesPtr type = GeoPTypesUI8::create(); > > beginEditCP(N, Node::CoreFieldMask); > N->setCore(geo); > endEditCP(N, Node::CoreFieldMask); > > beginEditCP(geo); > geo->setPositions(points); > geo->setIndices(index); > geo->setLengths(lens); > geo->setTypes(type); > endEditCP(geo); > > // construct the geometry modifying the lens, index and types > ... > > createSharedIndex(geo); > calcVertexNormals(geo); > return N; > } > > and then I have to sub the previous geometry node on it's parent > (the material node) > and add this new one instead, this is made by the setGeometry() > function: > > void grimageMesh::setGeometry(NodePtr N){ > beginEditCP(GrimageMeshMaterial); > GrimageMeshMaterial->subChild(GrimageMeshGeo); > GrimageMeshGeo = N; > GrimageMeshMaterial->addChild(GrimageMeshGeo); > endEditCP(GrimageMeshMaterial); > } > > If I call these methods in the Display() function it works fine : > > NodePtr N = G->createGeometry(); > G->setGeomtry(N) > > But as the creation of the geometry take some time, it reduce the > display loop speed, > so I would like a thread does this : > > here is what I made : > In the main function I call LauchGrimageThread() that initialize > the thread : > > int LaunchGrimageThread(void *args){ > > ... // some other stuffs not important here > > GT = dynamic_cast<Thread *> > (ThreadManager::the()->getThread("GrimageThread")); > GT->runFunction(GrimageThread,Thread::getAspect(),args); > return 1 ; > } > > void GrimageThread( void* args) > { > while (true) { > > NodePtr N = G->createGeometry(); > GTLock->aquire(); > G->setGeometry(N); > GTLock->release(); > > usleep(1); // let the display loop acquire the mutex > } > } > > And the last thing is to apply the thread change list in the display > function : > > GTLock->aquire(); > Thread::getCurrentChangeList()->merge(*(GT->getChangeList())); > GT->getChangeList()->clearAll(); > GTLock->release(); > > Unfortunately this work a few second, where I can see my object > "moving", wich means the geometry is correctly > updated, but after some time it segfault. > This problem come from the geometry. If I don't add my object to the > scene root node but still update it no segfault . > And if I add it, but if in the GrimageThread() function I call > createGeometry() between the Lock aquires() > and release() it also works. But it that case there is not point to > use a thread as the display() loop have to wait > the calcul of the new geometry to aquire the Lock and aplly the change > list. > > So why is there problems? If the main processus interupt the creation > of the geometry launched by the thread it's not > a problem, as we are working on local objects not part of the scene > graph, when the traead will get the processor again > it will continue to construct the geometry. We only want that he is > not interupted when he will update the scene graph > by removing the old node and adding the new one. > > Does anyone know where this problem comes from? > > Thanks, > Adrien > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ------------------------------------------------------------------------ > > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > -- Daniel J. Sperka, Ph. D. UC Davis Center for Neuroscience ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
