Hi Markus, >From the description you have provide I would suspect your problem is down to running out of memory either on the application side or on the GL side. The fix to osg:::Image::setData() I've made just affects whether a texture object is updated as expected, it won't effect memory usage.
The solution you used for disabling the DEEP_COPY_IMAGES is sound for reducing memory usage, and in general I'd recommend that as much of the scene graph is shared as possible, especially ones associated with OpenGL objects as these consume the most memory. There isn't really anything the OSG can do to avoid memory exhaustion issues resulting from creation of too much scene graph, it's really down to the application developer to manage their scene graph to the constraints that the hardware they are targeting. Robert. On 20 July 2013 19:09, Markus Hein <[email protected]> wrote: > > Hello all, > > I'm reading about problems regarding cloning the image data. Our app uses > osg-3.0.1 built under VS 2012 with platform_toolset setting: v110_xp. > We got problems under cloning of some of our model nodes (first using > CopyOp::DEEP_COPY_ALL) . This was leading to crash the app. Memory handling > in earlier VS2012 version was not safe, there was some issues listed on MS > webpage. We found a workaround to avoid crashes, using > CopyOp::DEEP_COPY_ALL & ~CopyOp::DEEP_COPY_IMAGES instead. It is the better > way to go for our app and it saves tons of memory. > I haven't tried to debug image cloning inside of osg code, but I think > that our issue can be related to this topic, maybe something goes wrong > under image cloning in osg ? Maybe using shared image data from several > cloned models isn't safe? I don't know. > The good thing here is that using cloning option : CopyOp::DEEP_COPY_ALL & > ~CopyOp::DEEP_COPY_IMAGES saves so much memory, because we want to share > all image data but we need to separate parts of the nodestructure of cloned > models. > > > I will try out the latest updates from trunk branch to check if our > problems was related to this issue. > > regards, Markus > > Den 18.07.2013 22:18, skrev Robert Osfield: > > Hi Paulo, > > Thanks for the extra explanation. I have just done another code review and > think that it could be the lack of a dirty() call in the Image::setData() > method that is leading to discrepancy. I have added this to Image.cpp and > checked it into svn/trunk. The new Image::setData() looks like: > > void Image::setData(unsigned char* data, AllocationMode mode) > { > deallocateData(); > _data = data; > _allocationMode = mode; > dirty(); > } > > Could you try this out? > > Robert. > > On 18 July 2013 16:57, Paulo Silva <[email protected]> wrote: > >> Hi Robert, >> >> well I didn't run the code in debug mode because that would require me >> to recompile osg in debug, and I thought since no one else seems to be >> complaining maybe, as you say, it's something on my part. >> >> Now, as I understand it, cloning an image should be an straightforward >> operation. >> But for some reason I'm getting different results using >> >> Image* a = osgDB::readImageFile("a.png"); >> >> tex->setImage(a); // shows image "a.png" on screen >> >> ... >> >> Image* b = osgDB::readImageFile("b.png"); >> >> Image* new_image = dynamic_cast<Image*>(b->clone(CopyOp::DEEP_COPY_ALL)); >> >> tex->setImage(new_image); // still shows image "a.png" >> >> ... >> >> Image* c = new Image; >> >> c->allocateImage(b->s(), b->t(), b->r(), b->getPixelFormat(), >> b->getDataType()); >> >> memcpy(c->data(), b->data(), b->getTotalSizeInBytes()); >> >> tex->setImage(c); // now displays "b.png" correctly >> >> Now, I wonder what could be wrong in that usage of clone. I guess it >> could be the lack of a call to dirty() as you have in allocateImage, but I >> think I tried to add that after the clone and if I remember correctly it >> made no difference. >> >> As far as I am concerned, since I have one method working I'll skip the >> debugging for now. >> >> What I can say is that maybe the clone/copy constructor should be >> implemented in terms of allocateImage. >> Code duplication only leeds to maintenance problems down the road. >> >> Thanks, >> Paulo >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > > _______________________________________________ > osg-users mailing > [email protected]http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
