I sent you a personal email Richard with a few suggestions.
What I believe Richard was getting at, is there any global settings that should
be made to the system. What I instantly thought of was this :
osgDB::DatabasePager* pPager =
osgDB::Registry::instance()->getOrCreateDatabasePager();
pPager->setDoPreCompile(mPaging_Precompile);
osgDB::ReaderWriter::Options* options = new osgDB::ReaderWriter::Options;
options->setObjectCacheHint(osgDB::ReaderWriter::Options::CACHE_ALL);
osgDB::Registry::instance()->setOptions(options);
//pPager->setTargetFrameRate(mPaging_Frame_Rate_Targeted);
//pPager->setExpiryDelay(mPaging_ExpiringDelay);
pPager->setMaximumNumOfObjectsToCompilePerFrame(mMaximumObjectsToCompile);
//pPager->setThreadPriorityDuringFrame(OpenThreads::Thread::THREAD_PRIORITY_NOMINAL);//HIGH);
//pPager->setThreadPriorityOutwithFrame(OpenThreads::Thread::THREAD_PRIORITY_NOMINAL);//HIGH);
Partially off topic, I did not feel like the osg training sessions I received
were beneficial; as I already came from Opengl course / directx course
backgrounds.
________________________________
From: [EMAIL PROTECTED] on behalf of Richard S. Wright Jr.
Sent: Fri 1/25/2008 5:03 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Terrain (.osga) optimization tips
Ok, before we get anymore bad blood here let me just say I did not
frame my original question properly, which has lead to a
misunderstanding and elevated blood pressures. I basically got my
answer (and then some), but I did not mean to cause a goading war.
Richard
On Jan 25, 2008, at 4:38 PM, Robert Osfield wrote:
> Hi Richard,
>
> You shouldn't have to do any performance tuning with VPB dataset, they
> are supposed to built well balanced in the first place. If there is a
> problem then its not a general problem but something very specific
> about your system and the way you've set things up - from the little
> stats its clearly a hardware/driver issue particular to your system
> OS. Its utterly pointless talking about giving you a full lesson in
> the general topic of paging when there is something really specific
> wrong with your setup, something I'm completely not partial to. I am
> human not omnipotent.
>
> As for complexity, hell yes, real-time computer graphics is hard,
> multi-threading is hard, the OSG strives to make it easy, but in the
> end its a big big hard topic. Its takes years to master, and yes
> taking courses really does help, you shouldn't expect others to teach
> you everything you need to know.
>
> If I ask a question of what's happening at your its because it needs
> there is NO way I can answer you question without more information.
> If I have to ask extra questions its because you have failed to
> provide the info in the first place, I don't ask questions for the fun
> of it and a way of avoiding answering a question, I try to get the
> point as quickly as possible to avoid wasting mine and your time.
>
> Perhaps I should just totally ignore posts that don't provide enough
> info to answer sensible? Why should I waste my time if people don't
> care to invest their own time in asking sensible questions.
>
> Robert.
>
> On Jan 25, 2008 9:23 PM, Richard S. Wright Jr.
> <[EMAIL PROTECTED]> wrote:
>> "lots of in depth best practice advice"?
>>
>> I didn't realize it was that complicated a question, I'm sorry. If
>> someone asked for some general performance tips for using OpenGL, I
>> could probably spout off about 10 or so cold. I didn't realize OSG
>> was
>> so complicated that you needed a training class. I just wanted to
>> know
>> if the way I was loading the terrain was typical or not, and if not
>> how other people are doing it. My 'clue' that my approach was perhaps
>> naive was that I thought the performance could be better, and I might
>> have overlooked something obvious. I apologize if my first message
>> was
>> unclear, I'm not trying to focus on the performance per-se, I realize
>> no one can do performance tuning via e-mail.
>>
>> This is how everyone load's terrain in OSG. The lower rez terrains
>> render quite fast, and for higher rez terrains is might be slow on
>> some systems. Specific performance tuning is something of a black
>> art.
>> I did not miss anything obvious, that's just the way it is. I can
>> accept that as an answer.
>>
>> Richard
>>
>>
>> On Jan 25, 2008, at 10:22 AM, Robert Osfield wrote:
>>
>>> Hi Richard,
>>>
>>> I'm afraid you're best to go to a training course if want lots of in
>>> depth best practice advice.
>>>
>>> As for why things are going slow, well the high draw time is great
>>> place to start, sounds very much likely a driver the OpenGL badly
>>> optimized for the type of data the OSG is throwing at it.
>>>
>>> If you have another machine/OS available try the same data there.
>>>
>>> Robert.
>>>
>>> On Jan 25, 2008 2:20 PM, Richard S. Wright Jr.
>>> <[EMAIL PROTECTED]> wrote:
>>>> Robert,
>>>>
>>>> I didn't give all those details because I'm looking for more of a
>>>> "best practices" type of advice. Just loading the terrain "just
>>>> works", but is this the typical usage scenario for most users? What
>>>> are some of the common ways to speed up a terrain database created
>>>> with osgdem in this way? When I created the database with osgdem, I
>>>> made it to level 10.
>>>>
>>>> My specific case is just terrain and imagery. It's made from a ten
>>>> meter DEM of the island of Oahu. The osga file is just shy of a
>>>> gig.
>>>> I'm "not-impressed" with performance because from looking at what
>>>> is
>>>> on screen, I've seen way better performance from my hardware
>>>> (MacBook
>>>> Pro w/ATI x1600 & a Mac Pro w/ATI 2400). The window is small and
>>>> not
>>>> fill limited.
>>>>
>>>> Basically, I'm not looking for a detailed analysis of my particular
>>>> situation, but wanted to know if there is something obvious that
>>>> everyone else knows about for loading these types of files that I
>>>> had
>>>> missed.
>>>>
>>>> Bringing it into the Cocoa viewer, I get 1.03fps from an elevated
>>>> view
>>>> looking down on the Island. Timeing stats are:
>>>>
>>>> Event: 0.02
>>>> Update: 0.04
>>>> Cull: 0.41
>>>> Draw: 932.81
>>>>
>>>> So... doing the math, looks like rendering is taking a pretty long
>>>> time ;-) I'm thinking there is some utility node or flag that most
>>>> people turn on that I have overlooked.
>>>>
>>>>
>>>> Richard
>>>>
>>>>
>>>> On Jan 25, 2008, at 4:56 AM, Robert Osfield wrote:
>>>>
>>>>> Hi Richard,
>>>>>
>>>>> Way too little information to be able to know what is up with
>>>>> performance, so lets start with a few questions to get the
>>>>> information
>>>>> needed to guide you in the right direction:
>>>>>
>>>>> What platform are you working on?
>>>>>
>>>>> What hardware?
>>>>>
>>>>> Did you compile a release build?
>>>>>
>>>>> What performance did you get?
>>>>>
>>>>> What is the update, cull, draw, GPU stats like?
>>>>>
>>>>> How big is the database? Is it terrain, imagery, terrain+imagery?
>>>>> Other cultral data in there???
>>>>>
>>>>> Robert.
>>>>>
>>>>> On Jan 25, 2008 3:54 AM, Richard S. Wright Jr.
>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>
>>>>>> I'm loading a terrain set created with osgdem (.osga) via
>>>>>> something
>>>>>> like
>>>>>> this:
>>>>>>
>>>>>>
>>>>>> pTerrain = osgDB::readNodeFile("oahu-10.osga");
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Easy as pie. However, for a really dense terrain, the performance
>>>>>> is a bit
>>>>>> lack-luster. I wonder if everybody knows a trick that I haven't
>>>>>> discovered
>>>>>> yet for speeding this up a bit. Some standard "optimization" node
>>>>>> configuration or setting that a newbie might have missed that can
>>>>>> make a big
>>>>>> difference.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
_______________________________________________
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
