Hi Robert,
We finally solved the problem!! First sorry for the noise! :)
PagedLOD, DatabasePager and the rest of the 2.8.3 is working
perfectly.
The problem on our side was a Java object that kept references to an
osg::Texture2D after applied to the terrain. Java destruction policy
is .. well is Java, so the more tiles loaded the more references not
released (only when finalize called, and this only occurs from time to
time). Now we release resources on C++ after applied so it not depends
on Java.
We really fixed horrible bug here! :)
Thank you and sorry for the noise!.
Rafa.
2010/10/19 Rafa Gaitan <rafa.gai...@gmail.com>:
> Hi Robert,
>
> 2010/10/19 Robert Osfield <robert.osfi...@gmail.com>:
>> Hi Rafa,
>>
>> I think Paul merged improvements made to DatabasePager made to
>> svn/trunk into 2.8.3.
>> The improvements change the way that PagedLOD's are expired, changing
>> it from time based expiry to a system where the number of PagedLOD are
>> capped to a below a users specified maximum, if the number of PagedLOD
>> is below value then it won't expiry any subgraphs, only when new
>> subgraphs are loaded and the new number exceeds the max will the pager
>> start expiring old PagedLOD's. This scheme is far more reliable and
>> controllable than the old time based scheme.
>
> Yes, we knew that and that's why we want to use the 2.8.3 version.
>
>>
>> In your case it could be that the default max value of 500 is too high
>> for your application, in which case you can adjust it down via the
>> OSG_MAX_PAGEDLOD env var or programmatically via the DatabasePager
>> method:
>>
>> /** Set the target maximum number of PagedLOD to maintain in memory.
>> * Note, if more than the target number are required for
>> rendering of a frame then these active PagedLOD are excempt from being
>> expiried.
>> * But once the number of active drops back below the target
>> the inactive PagedLOD will be trimmed back to the target number.*/
>> void setTargetMaximumNumberOfPageLOD(unsigned int target) {
>> _targetMaximumNumberOfPageLOD = target; }
>>
>
> I forget to mention in my previous mail that we already have this
> variable to 2 (We knew that this is really a
> low value but in our application and using java we need to free as
> soon and as fast as possible).
>
>> If you are still seeing problems then it could be that there is a bug,
>> and there is chance that it might already be addressed in svn/trunk or
>> one of the 2.9.x series. I'm actually working of
>> DatabasePager/IncrementalCompileOperation right now so it's not a bad
>> time for me to look at a regression if you can provide guidance on how
>> to reproduce the problem.
>
> We also took a look to the changes between 2.8.3 and trunk but lot of
> changes are made so not sure if the problem persists there.
>
> Our trunk version is working against osg trunk, so once we finish the
> build we can do a simple example to test if continues happening on
> trunk.
>
> Cheers,
> Rafa.
>
>
>>
>> Cheers,
>> Robert.
>>
>>
>>
>> On Tue, Oct 19, 2010 at 11:52 AM, Rafa Gaitan <rafa.gai...@gmail.com> wrote:
>>> Hi,
>>>
>>> We are currently using osg 2.8.3, with osgVirtualPlanets in a GIS
>>> application (gvSIG-3D). Trying to get a new build we migrated from
>>> 2.8.2 to 2.8.3.
>>>
>>> Testing the build we have realized that the memory doesn't free as
>>> "fast" as previous version, getting a big memory usage of the
>>> application.
>>>
>>> Getting deep on the issue we have compared differences between 2.8.2
>>> an 2.8.3 on DatabasePager and we have seen that some code:
>>>
>>> if (osgDB::Registry::instance()->getSharedStateManager())
>>> osgDB::Registry::instance()->getSharedStateManager()->prune();
>>>
>>> // update the Registry object cache.
>>>
>>> osgDB::Registry::instance()->updateTimeStampOfObjectsInCacheWithExternalReferences(frameStamp.getReferenceTime());
>>> osgDB::Registry::instance()->removeExpiredObjectsInCache(expiryTime);
>>>
>>> has been removed from the next methods:
>>>
>>> void DatabasePager::capped_removeExpiredSubgraphs(const
>>> osg::FrameStamp& frameStamp)
>>> void DatabasePager::expiry_removeExpiredSubgraphs(const
>>> osg::FrameStamp& frameStamp)
>>>
>>> I'm not sure if the changes are intentionally or maybe a bug was
>>> introduced in this part of code.
>>>
>>> What do you think?
>>>
>>> Thanks!
>>> Rafa.
>>>
>>>
>>> --
>>> Rafael Gaitán Linares
>>> Instituto de Automática e Informática Industrial http://www.ai2.upv.es
>>> http://gvsig3d.blogspot.com
>>> Ciudad Politécnica de la Innovación
>>> Universidad Politécnica de Valencia
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Rafael Gaitán Linares
> Instituto de Automática e Informática Industrial http://www.ai2.upv.es
> http://gvsig3d.blogspot.com
> Ciudad Politécnica de la Innovación
> Universidad Politécnica de Valencia
>
--
Rafael Gaitán Linares
Instituto de Automática e Informática Industrial http://www.ai2.upv.es
http://gvsig3d.blogspot.com
Ciudad Politécnica de la Innovación
Universidad Politécnica de Valencia
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
