Enrico wrote: > Hi Marcus, thanks for the hasty ansewer. > > You told me: > >> Lookign at GrabForeGround::draw() there is also no CPEdit() on the >> image, so that might be it (i.e. you must do a workaround and register >> the image data as changed), if you're actually able to get any data back >> (check that first). >> > > I gave a look at the GrabForeGround::draw() code and I noticed that the clue > point is a well known glreadpixels. > > Unfortunately, since I am quite new to clustering and client server data > transmission, I am not really getting your points when you talk about CPEdit > and image data checking. > Ok. The tutorial has a page on multithreading & clustering, which gives a pretty good explanation about this, if you want a more in-depth explanation. Since you are looking to do some slightly advanced stuff, I recommend it.
http://www.opensg.org/doc-1.6.0/Multithreading.html http://www.opensg.org/doc-1.6.0/Clustering.html Short version: OpenSG records (by the help of the user, with begineditCp/endeditCP in versions <= 1.8, mostly automatically in 2.0) which fields on which objects (fieldcontainers) that has changed in a list (called ChangeList). This changelist can then be applied either to another local thread in your process, or sent over the network to one or more servers. If you have a static scene, all that get's transmitted per frame (once the initiali distrubution is done) is the camera's orientation. (Also, purely personally, I find the client/server terminology a bit confusing, since there is usually one server and several clients in a system. OpenSG uses the X-windows terminology, which, in a clustering environment, makes for the opposite, where one client app has several rendering servers. See the clustering page's picture.) > How may I check that data are present on my client? Try modifying a simple field on some object, such as the color of a material or so. Only do this on the servers (remote renders). Read the value on the local client and see if it changes. Then you know that you are getting the changes back. Make sure that works before moving on to the next issue. > As for now all I can see > is that the image on the client side is not resized accordingly to the > viewport and that adding a > > beginEditCP(image,osg::Image::PixelFieldMask) > grabforeground->setActive(true) > > redraw() > > grabforeground->setActive(false) > beginEditCP(image,osg::Image::PixelFieldMask) > > does not help very much > > > how may I register the data change? > Almost correct. use endEditCP the other time. Or the convenience macro CPEdit, as in: { CPEdit(image,osg::Image::PixelFieldMask) ... } This creates a object on the stack which calls endEditCP in it's destructor. Also, before I start misleading you too much, I'm only giving advice based on my non-cluster OpenSG experience. There might be other fallacies here which could prevent you from achieving what you want. I hope Dirk & Co are keeping an eye on this thread. :) If all else fails, you could always send the image back via some other transport, such as http/ftp or whatever, instead of OpenSG's clustering system. :) Cheers, /Marcus ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
