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
> >>>> [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
> >>
> > _______________________________________________
> > 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
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
