[osg-users] Optimizer improvements
Hi everyone, Recently I've noticed some issues with the optimizer which I'd like to fix. However, I'd like to request some feedback on what the best course would be. I have a file like this Code: Group Transform Group (UniqueID 1) Geode 1 StateSet (UniqueID 2) Geometry 1 Geode 2 StateSet (UniqueID 2) Geometry 2 Geode 3 StateSet (UniqueID 2) Geometry 3 Transform Group (UniqueID 1) I would like to optimize this to: Code: Group Geode StateSet Geometry It is not possible to do this in a single pass with the optimizer. Using optimizer settings FLATTEN_STATIC_TRANSFORMS_DUPLICATING_SHARED_SUBGRAPHS MERGE_GEODES MERGE_GEOMETRY REMOVE_REDUNDANT_NODES COPY_SHARED_NODES gets me quite far: Code: Group Geode StateSet Geometry 1 Geometry 2 Geometry 3 Geometry 4 Geometry 5 Geometry 6 , but the final geometry nodes aren't merged because the Geometry is still sharing the same vertex arrays (1 and 4, 2 and 5, 3 and 6). The COPY_SHARED_NODES setting helps to reduce the different nodes (because they are then merged), but it doesn't do anything to the data inside Geode nodes. Note that if I save the last file to disk, and then reconvert with the same optimizer settings, then the contents of the geometries is fully written to file, and on the second conversion OSG doesn't know that the geometries were linked, so happily merges them. The 'correct' solution I think is to add a function to CopySharedSubgraphsVisitor that also duplicates the contents of a Geode node. After that the MERGE_GEOMETRY setting should kick in and merge the resulting geometries into a single geometry. I hope someone can give me some input on the best way to handle this issue. If I wasn't clear enough about the problem, please let me know and I can post a complete osg file. Thank you! Cheers, Rick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26734#26734 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Increase image-quality - increase 'Draw' time
Thank you both for your replies. I think this little bit from Robert might be the issue: robertosfield wrote: However, if OpenGL FIFO fills up because the rate at which you are pushing data into it exceeds the rate at which it's been emptied then the application thread will stall and the draw dispatch times will go up. Sometimes you can see some rather no linear draw dispatch times due to small changes in load on the GPU suddenly causing the app to stall. Even when this happens there is still a bit of leeway before you start dropping frames. The workload on the GPU has increased, and I can only assume that it's now not processing the commands as fast as it used to. So since the output is taking longer, and the input is equal, the driver will need to wait for the queue to empty a bit every now and then. We're not changing the amount of data read back from the GPU (I doubt we even read back anything), I'm not changing anything in the program. Brian, if I'm locked to VSync (which I'm not in my test case), and the GPU has more work to do than the CPU, I do NOT expect the command submissions to take longer if I enable these quality options. I'm sending the exact same amount of data and commands, so why would the driver suddenly take longer to queue those commands? The GPU will of course need more time to execute those commands, but I wasn't expecting that to show up under the 'Draw' time, since that time is the 'GPU' time. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25852#25852 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Increase image-quality - increase 'Draw' time
Hi everyone, We were just doing some performance testing when we noticed that increasing the image quality in the NVidia control panel (adding anisotropic filtering, anti-aliasing and multi-sampling) makes the time spent in the 'Draw' section increase greatly. This wasn't something we were expecting. The time in GPU also goes up, but that is to be expected. We're assuming the extra time is spent in the driver somewhere, but we have no clue why. Would anyone dare to hazard a guess? Thank you! Cheers, Rick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25798#25798 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Enabling osgSim::DOFTransform animation
Hi, Recently we've implemented a model of a building with moving doors by adding osgSim::DOFTransform nodes for the doors (the geometry added as child of the DOFTransform). While this works quite well, there's an issue I've had with enabling the animation to open the door. When setAnimationOn(true) is called, the node is set such that is will be visited by the UpdateVisitor. On the first pass through DOFTransform::traverse the delta time is calculated from _previousTime and the timestamp in the UpdateVisitor. However, _previousTime has never been set before, which means that the first frame of animation is erratic. For the doors this behavior is not acceptable, and I feel that this should be fixed in OSG. I've made a quick fix by checking the _previousTraversalNumber and if it's set to -1 then the DOFTransform::animate function isn't called, only the _previousTime and _previousTraversalNumber are updated. On the second animated frame the delta time is then correctly calculated. (when calling setAnimationOn(false) I now reset _previousTraversalNumber to -1). Is this issue recognized as an issue by other people so that I should make a proper fix and submit it, or am I missing something which would enable the proper behavior of the doors? Thank you! Kind regards, Rick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=18381#18381 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Positioning PrecipitationEffect
Hi Jason, Thanks for the update. That's exactly what I'm seeing as well. However, as far as I can see in the code, the effect is positioned correctly around the camera. Cheers, Rick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11956#11956 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Positioning PrecipitationEffect
Hi Robert,
You asked Jason for a repro case back then. I've been simpifying my test case
such that is is now a simply plane.
plane.osg
Geode {
DataVariance STATIC
nodeMask 0x
num_drawables 1
Geometry {
DataVariance STATIC
PrimitiveSets 1
{
DrawElementsUShort TRIANGLE_STRIP 4
{
2 0 1 3
}
}
VertexArray Vec3Array 8
{
181920 -10 445.602
-10 181920 445.602
-10 -10 445.602
181920 181920 445.602
}
}
}
I run the precipitation example with the following options:
osgprecipitation plane.osg --fogColor 0.0 0.1 0.3 1.0 --particleSpeed 0.05
--rain 0.1 --particleColour 0.5 0.5 0.5 0.5 --fogDensity 0.01
--particleSize 0.15
You'll need to tilt the camera slightly to see the plane, and then if you zoom
way in you'll see the precipitation. (Note, I'm not using it for rain or snow,
hence the extremely low particle speed)
I hope this helps.
Kind regards,
Rick
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=11958#11958
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Positioning PrecipitationEffect
Hi Robert, I'm assuming nothing has happened on this front after the last message? I'm seeing the same effect here on a terrain database which is about 80kmx80km. If I get far away from the center of the bounding box (note: not the origin of the model) the rain becomes patchy and then disappears. I'm looking through the code, but it's a little unclear to me what it's supposed to do. You wouldn't happen to have a link to a high level description, paper or similar that the implementation is based on would you? As our database is in the GB range I'm afraid I'm not able to attach it. Thank you! Cheers, Rick PS. I'm having trouble locating Jason's attachment. On the forums his mail shows up, but no attachment, and in the mailing list archive I am unable to find the email with the attachment. Your reply to that email is here (http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg23436.html), but the mail with the attachment doesn't show. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11890#11890 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RTT and viewport offset
Hi, I've encountered an issue with rendering to texture and then displaying that texture with a viewport that doesn't start at 0,0. I'm using osgPPU for this, but I believe the issue is in OSG. In osgUtil/RenderStage.cpp, in RenderStage::runCameraSetUp the width and height are calculated as: int width = static_castint(_viewport-x() + _viewport-width()); int height = static_castint(_viewport-y() + _viewport-height()); This width and height is then used to create RenderBuffers for the missing attachments. If the viewport starts at non-zero values, this means the created RenderBuffers will not have dimensions (vp-width, vp-height) whereas the attached texture likely will have those dimenstions. Thus the FBO will then generate FRAMEBUFFER_INCOMPLETE_DIMENSIONS_EXT error. Removing the additions of _viewport-x()/y() fixes my issue. I was wondering if there was a good reason for doing it the way it's done. Kind regards, Rick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9797#9797 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multisample Coverage in FBO
Hi, I'm looking into using Multisampled Coverage in FBOs in our application, and I've run into an interesting snafu. According to the extension specification coverage_samples cannot be larger than color_samples. This is enforced in OSG in two places: osgUtil/RenderStage.cpp(352) and osg/FrameBufferObject.cpp(254). However, those two places take opposite actions to resolve the issue. The first one, osgUtil/RenderStage.cpp(352), decreases colorSamples to match (coverage)samples. The second one, osg/FrameBufferObject.cpp(254), increases (coverage)samples to match colorSamples. I haven't looked too hard at the code around this, but shouldn't this check only happen in one place (presumably FrameBufferObject.cpp)? RenderStage.cpp seems to lead into FrameBufferObject.cpp anyway, so it's doing a redundant check. I'm looking forward to hear your thoughts on this. Kind regards, Rick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=9608#9608 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager failed when loading ive with outside image
Sorry for the delays, but here I am. Robert, I've not been able to test my issue with the Registry turned off. It simple takes too long and a non-variable amount of time to see if that would avoid the issue. We were getting the crash when running for anything between 2 and 24 hours. As far as I can gather the OP here has tested this though, since he states the crash does not occur if he disables Image caching. Hope to help, Rick -- Read this topic online here: http://osgforum.tevs.eu/viewtopic.php?p=4638#4638 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users Digest, Vol 17, Issue 97
Hi Robert,
I can confirm that enabling Registry caching of images with paged databases
causes the issue. We haven't tried to disable the caching, but from what I've
seen I believe that if the cache is disabled the same issue *may* occur but
even earlier, precisely becaue an undecorated Image* is returned. The
ReadResult eventually goes out of scope, which should delete the pointed to
memory, causing a dangling pointer to exist. (Note that I haven't tried this,
it's purely my understanding of the issue).
The crash occured pretty much 100% of the time, but the time-till-crash was
unreliable. Sometimes it would crash within minutes, other times it would take
hours.
I concur with your assessment for the fix, but I don't believe it's only
relevant to the .ive plugin. I believe many plugins can encounter this
behaviour. Wrapping the return value of osgDB::readImageFile (and further up
the callstack I first posted) with a ref_ptr should fix the issue.
Kind regards,
Rick
-Original Message-
Hi Rick,
Just to confirm the issue, if you enable Registry caching of imagery
and use paged databases that have external image files, then you get
the below crash. If you don't use the Registry cache what happens?
How reliably does this crash occur?
My hypothisis is that the object cache is being cleared by another
thread just at the wrong time for this particular section of .ive
plugin. If it is correct then use of Registry::readImage(...) that
returns a Registry::ReadResult rather than a Image* would be safe as
ReadResult uses ref_ptr internally.
Robert.
On Tue, Nov 25, 2008 at 1:49 PM, Rick Appleton
[EMAIL PROTECTED] wrote:
Sorry for the delay on this.
Here's some more information. Below is a complete callstack which should be
similar to when the issue happened. Basically we are loading a Paged terrain
database which uses IVE files for data, and DDS textures for images. A quick
search in OSG reveals that osgDB::readImageFile is called from many plugin
loaders, so I suspect they would have the same issue.
osg48-osgDBd.dll!osgDB::Registry::readImageImplementation(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
fileName=textures/TxMosaic.dds, const osgDB::ReaderWriter::Options *
options=0x01f0ceb8) Line 1706C++
osg48-osgDBd.dll!osgDB::Registry::readImage(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
fileName=textures/TxMosaic.dds, const osgDB::ReaderWriter::Options *
options=0x01f0ceb8) Line 217 + 0x14 bytes C++
osg48-osgDBd.dll!osgDB::readImageFile(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
filename=textures/TxMosaic.dds, const osgDB::ReaderWriter::Options *
options=0x01f0ceb8) Line 43 + 0x1d bytes C++
osgdb_ived.dll!ive::DataInputStream::readImage(std::basic_stringchar,std::char_traitschar,std::allocatorchar
filename=textures/TxMosaic.dds) Line 950 + 0x44 bytesC++
osgdb_ived.dll!ive::DataInputStream::readImage(ive::IncludeImageMode
mode=IMAGE_REFERENCE_FILE) Line 1003 + 0x2c bytes C++
osgdb_ived.dll!ive::DataInputStream::readImage() Line 976 + 0xc bytes
C++
osgdb_ived.dll!ive::Texture2D::read(ive::DataInputStream *
in=0x00dbec2c) Line 54 + 0x8 bytes C++
osgdb_ived.dll!ive::DataInputStream::readStateAttribute() Line 1159 +
0xc bytesC++
osgdb_ived.dll!ive::StateSet::read(ive::DataInputStream *
in=0x00dbec2c) Line 173 + 0x8 bytes C++
osgdb_ived.dll!ive::DataInputStream::readStateSet() Line 1066 C++
osgdb_ived.dll!ive::Node::read(ive::DataInputStream * in=0x00dbec2c)
Line 124 + 0x8 bytes C++
osgdb_ived.dll!ive::Geode::read(ive::DataInputStream * in=0x00dbec2c)
Line 67 C++
osgdb_ived.dll!ive::DataInputStream::readNode() Line 1507 + 0x2d
bytes C++
osgdb_ived.dll!ive::Group::read(ive::DataInputStream * in=0x00dbec2c)
Line 74 + 0x8 bytes C++
osgdb_ived.dll!ive::DataInputStream::readNode() Line 1499 + 0xc bytes
C++
osgdb_ived.dll!ReaderWriterIVE::readNode(std::basic_istreamchar,std::char_traitschar
fin={...}, const osgDB::ReaderWriter::Options * options=0x01f0ceb8)
Line 98 + 0xb bytesC++
osgdb_ived.dll!ReaderWriterIVE::readNode(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
file=veluwe.ive, const osgDB::ReaderWriter::Options * options=0x01efeb88)
Line 69 + 0x23 bytes C++
osg48-osgDBd.dll!osgDB::Registry::ReadNodeFunctor::doRead(osgDB::ReaderWriter
rw={...}) Line 1374 + 0x40 bytes C++
osg48-osgDBd.dll!osgDB::Registry::read(const
osgDB::Registry::ReadFunctor readFunctor={...}) Line 1527 + 0x22 bytes C++
osg48-osgDBd.dll!osgDB::Registry::readImplementation(const
osgDB::Registry::ReadFunctor readFunctor={...}, bool useObjectCache=true)
Line 1596 + 0x13 bytes C++
osg48-osgDBd.dll!osgDB::Registry
Re: [osg-users] Multi-threading bug related to Registry
are you invoking in this instance? .osg? .ive? Others? Robert. On Mon, Nov 17, 2008 at 1:23 PM, Rick Appleton [EMAIL PROTECTED] wrote: There is a nasty multi-threading bug related to osgDB::DatabasePager and the _objectCache in osgDB::Registry. This is the situation. * Thread 2 stack (DatabasePager thread): ReaderWriter::ReadResult Registry::readImplementation ReaderWriter::ReadResult Registry::readImageImplementation ReaderWriter::ReadResult Registry::readImage osg::Image* osgDB::readImageFile osg::Image* DataInputStream::readImage(std::string filename) osg::Image* DataInputStream::readImage(IncludeImageMode mode) osg::Image* DataInputStream::readImage() void Texture2D::read(DataInputStream* in) .. - After reading in the file in Registry::readImplementation the refCount of the new Image is 1 (ReadResult contains a ref_ptr). - This Image is then inserted into Registry::_objectCache with the default timestamp (0.0), which increments the recCount to 2. - The ReadResult object is returned, so no net change in refCount, until the stack is unwound up to osgDB::readImageFile. - osgDB::readImageFile takes a normal pointer to the Image, which does not change the refCount. When osgDB::readImageFile returns, the ReadResult object goes out of scope, deleting a reference to the Image. refCount is now 1. - Stack unwinds until back in Texture2D::read at which point the normal Image* is passed into Texture2D::setImage which assigns the Image* to the internal ref_ptr. At this moment the refCount is increased back to 2. Imagine that somewhere during the stack unwind between osgDB::readImageFile and Texture2D::read a thread switch takes place. * Thread 1: The main thread then reaches DatabasePager::removeExpiredSubgraphs which does the following at the end of the function. - Calls Registry::updateTimeStampOfObjectsInCacheWithExternalReferences, which goes through the objects and increments the timestamp if the refCount1 (this is not true for just loaded Image, so timestamp remains 0.0). - Calls Registry::removeExpiredObjectsInCache, which goes through all the objects and compares the timestamp with the expiry time. Because the Image was added with timestamp 0.0 (and the timestamp was not updated), it is added to objectsToRemove. - Registry::removeExpiredObjectsInCache then removes all the objects in objectsToRemove from Registry::_objectCache. This causes the refCount on the Image to decrement to 0, causing the actual Image object to be freed. At this point Thread 2 has an Image* to freed memory, but does not realize the object has been freed. In our case this eventually led to crashes. There are two solutions to this: - Instead of using the default timestamp of 0.0, set the time explicitly to the current time. This makes sure the item is not immediately discarded from the Registry. Even if not all loads are finished before the new item times out, the item will have been acquired by some other place in the code, so the refCount will be larger than 1 when the timeout occurs. This requires the current time to be passed into readImplementation. A proper solution would be to pass in the timestamp of the DatabaseRequest into the read* functions. That requires modification of a lot of functions though. - Changing the return types of the sequence above so there aren't any normal osg::Image* passed around, but only ref_ptr. This makes sure that refCount never goes to during the loading process. This option also requires the modification of a large number of functions. We chose a slightly less proper solution following the first option. We've added a function to set the time in Registry once a frame, and call that just before DatabasePager::updateSceneGraph (which calls DatabasePager::removeExpiredSubgraphs). Please feel free to contact me for more info as needed, Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multi-threading bug related to Registry
There is a nasty multi-threading bug related to osgDB::DatabasePager and the _objectCache in osgDB::Registry. This is the situation. * Thread 2 stack (DatabasePager thread): ReaderWriter::ReadResult Registry::readImplementation ReaderWriter::ReadResult Registry::readImageImplementation ReaderWriter::ReadResult Registry::readImage osg::Image* osgDB::readImageFile osg::Image* DataInputStream::readImage(std::string filename) osg::Image* DataInputStream::readImage(IncludeImageMode mode) osg::Image* DataInputStream::readImage() void Texture2D::read(DataInputStream* in) .. - After reading in the file in Registry::readImplementation the refCount of the new Image is 1 (ReadResult contains a ref_ptr). - This Image is then inserted into Registry::_objectCache with the default timestamp (0.0), which increments the recCount to 2. - The ReadResult object is returned, so no net change in refCount, until the stack is unwound up to osgDB::readImageFile. - osgDB::readImageFile takes a normal pointer to the Image, which does not change the refCount. When osgDB::readImageFile returns, the ReadResult object goes out of scope, deleting a reference to the Image. refCount is now 1. - Stack unwinds until back in Texture2D::read at which point the normal Image* is passed into Texture2D::setImage which assigns the Image* to the internal ref_ptr. At this moment the refCount is increased back to 2. Imagine that somewhere during the stack unwind between osgDB::readImageFile and Texture2D::read a thread switch takes place. * Thread 1: The main thread then reaches DatabasePager::removeExpiredSubgraphs which does the following at the end of the function. - Calls Registry::updateTimeStampOfObjectsInCacheWithExternalReferences, which goes through the objects and increments the timestamp if the refCount1 (this is not true for just loaded Image, so timestamp remains 0.0). - Calls Registry::removeExpiredObjectsInCache, which goes through all the objects and compares the timestamp with the expiry time. Because the Image was added with timestamp 0.0 (and the timestamp was not updated), it is added to objectsToRemove. - Registry::removeExpiredObjectsInCache then removes all the objects in objectsToRemove from Registry::_objectCache. This causes the refCount on the Image to decrement to 0, causing the actual Image object to be freed. At this point Thread 2 has an Image* to freed memory, but does not realize the object has been freed. In our case this eventually led to crashes. There are two solutions to this: - Instead of using the default timestamp of 0.0, set the time explicitly to the current time. This makes sure the item is not immediately discarded from the Registry. Even if not all loads are finished before the new item times out, the item will have been acquired by some other place in the code, so the refCount will be larger than 1 when the timeout occurs. This requires the current time to be passed into readImplementation. A proper solution would be to pass in the timestamp of the DatabaseRequest into the read* functions. That requires modification of a lot of functions though. - Changing the return types of the sequence above so there aren't any normal osg::Image* passed around, but only ref_ptr. This makes sure that refCount never goes to during the loading process. This option also requires the modification of a large number of functions. We chose a slightly less proper solution following the first option. We've added a function to set the time in Registry once a frame, and call that just before DatabasePager::updateSceneGraph (which calls DatabasePager::removeExpiredSubgraphs). Please feel free to contact me for more info as needed, Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager questions
Thank you Robert for the quick reply. I see the point in having a single osgDB::DatabasePager for a single osgViewer::Scene. However, this immediately raises the question which DatabasePager osgDB::Registry would point to, as osgDB::Registry is a singleton and only has a single pointer to a DatabasePager. Should we ignore the osgDB::Registry::getOrCreateDatabasePager function? I don't see it being used anywhere in OpenSceneGraph. Kind regards, Rick -Original Message- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Thu 10/30/2008 12:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] DatabasePager questions Hi Rick, The osgDB::DatabasePager::instance() exist for backwards compatibility with osgProducer from the OSG-1.x era. In OSG-2.x's osgViewer library there is one osgDB::DatabasePager per osgViewer::Scene, and the Scene is used internally by osgViewer::View to manage the sharing of a single scene graph between multiple View's. The coupling of DatabasePager and Scene ensures that there is only ever one pager working for one scene graph. It also allows multiple scene graphs to be managed, each with their own dedicated pager. In terms of user management, this is all done behind the scenes in osgViewer, it'll just automatically assign and set up and interact with the pager, you needn't do anything yourself. If your scene graph contains PagedLOD then it'll automatically start up and run in the background. The only time you need to know about the DatabasePager is when you want to adjust parameters to optimize the behavior to your type of data/application, but the since the defaults have been chosen to work well for most datasets users typically won't need to tweak parameters. Robert. On Thu, Oct 30, 2008 at 10:57 AM, Rick Appleton [EMAIL PROTECTED] wrote: I've only recently started using OpenSceneGraph, so am probably mistaken about this, but I feel there's some issues with osgDB::DatabasePager. It seems the design of osgDB::DatabasePager allows for multiple instances of it to exist side-by-side. Scene creates one instance in it's constructor, and if you call Registry::getOrCreateDatabasePager without setting a pager up, it creates another instance. The first uses the Database::create function, whereas the second uses a simple 'new'. This has caused us some issues as we only expected there to be a single instance of osgDB::DatabasePager. What is the reason for explicitly allowing this functionality? It may simply be to do with the way we have the DatabasePager setup, but my lack of a higher view of the code is making it hard to understand what's supposed to happen. Can anyone clarify how the DatabasePager is supposed to be used for me? Kind regards, Rick Appleton ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager questions
Thanks again for the quick reply. All is clear now, and I'll fix our code to not use the Registry DatabasePager. Rick -Original Message- From: [EMAIL PROTECTED] on behalf of Robert Osfield Sent: Thu 10/30/2008 1:36 PM To: OpenSceneGraph Users Subject: Re: [osg-users] DatabasePager questions Hi Rick, On Thu, Oct 30, 2008 at 12:17 PM, Rick Appleton [EMAIL PROTECTED] wrote: I see the point in having a single osgDB::DatabasePager for a single osgViewer::Scene. However, this immediately raises the question which DatabasePager osgDB::Registry would point to, as osgDB::Registry is a singleton and only has a single pointer to a DatabasePager. Should we ignore the osgDB::Registry::getOrCreateDatabasePager function? I don't see it being used anywhere in OpenSceneGraph. Oooh, those methods are deprecated, and completely forgotton about... thanks for pointing this out. I've just removed them from the Registry to avoid future confusion. I'll check this in after a clean build. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org winmail.dat___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
