Hello Weiyu, Weiyu Yi wrote: > One of my imagining about the reason of the first problem is that: > > The redraw() takes more time than normal when the data to render is > changing by another thread and redraw() is doing something to make the > data consistent > Is that correct?
no, if you change the scene while redraw is running you may get incorrect results or crash the program, but it does not detect concurrent modification and account for it. As an example, why the program may crash, consider you are removing a Node from the scene while it is being visited by the RenderAction. When the RenderAction calls the leave callback for that type it now suddenly operates on an object that is not part of the scene and indeed may just have been deleted (because its ref count dropped to 0). > 2009/11/14 Weiyu Yi <[email protected] <mailto:[email protected]>> > In my programm, one thread is used to detect the collisions and call > the callbacks if collisions happen, and the main thread is used to > controll the scene and render it with OpenSG. I exploit > boost::thread for the multirheading mechanism > > but now I have some problems: > > 1) When I use the multithreading mechanism by mutex, which is > provided by boost. Callback for collision detection thread and main > thread may change the scene at the same time, so I have the mutex > them. but while renderring the scene, it runs sometimes very slowly, > the redraw() function sometimes takes the 10x more time > than normal, Why should it happen? Principle it has only read > access to the scene daten and in my code mutex has no affect to it: while it is true that rendering is in principle a read only operation on the scene, in practice there is some data that is being written (to cache it for the next frame), for example if bounding volumes have become invalid, rendering first forces them to be updated, so that it can do accurate frustum culling. From your description I can not really tell if you hold the mutex during redraw or not. Do you? Have you tried not holding the mutex during redraw()? As you said it basically is read only and depending on your collision thread actually changes (if it's just a matrix in some transform you should be ok, if you deform geometry or add/remove nodes etc. it is dangerous to run without the mutex). > ****************************** > Func Time(microsec) > main::redraw(): 3663 > main::redraw(): 10232 > main::redraw(): 1572 > main::redraw(): 1497 > main::redraw(): 1511 > main::redraw(): 1408 > main::redraw(): 45564 > main::redraw(): 1622 > main::redraw(): 1509 > main::redraw(): 1439 > main::redraw(): 1508 > main::redraw(): 43036 > main::redraw(): 1769 > main::redraw(): 7248 > main::redraw(): 1757 > main::redraw(): 1492 > main::redraw(): 1574 > main::redraw(): 2367 > main::redraw(): 1629 > main::redraw(): 13290 > ****************************** > > 2) I add the code like: > > OSG::UInt32 aspectId = 0; > OSG::ExternalThread::get(0)->initialize(aspectId); > > with a callback in the collision detection thread > > Could I use the multithreading mechanism of OpenSG when I have > declared the external thread to OpenSG? e.g like: aspectID=1. and > some necessary function like getChangeList()->applyAndClear() ? yes, that is what the mechanism was built for. Keep in mind though that a new aspect (one that has not been used before) starts out empty. So you need to sync your scene first from aspect 0 to aspect 1 (e.g. to get models you loaded in aspect 0), and then regularly from aspect 1 to 0. If you also make changes in aspect 0 you need to be a bit careful when you sync those back to aspect 1. Generally it is easiest to use a producer/consumer scheme for the threads where rendering is the consumer and other threads simply modify the scene based on their calculations. In that case you often only need to sync in one direction instead of moving changes in both. Cheers, Carsten ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
