"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
