Thanks for the pointers I should be able to get something up and running
now.
Robert Osfield wrote:
Hi Nghia,
On 11/14/06, *Nghia* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Sorry if this question has been asked before (couldn't find a search
option for the mailing list). I have an existing OpenG app that I want
to port over to OSG to see if there are any speed gains.
Possible speed gains will depend on how you manage the OpenGL
rendering right now. If you don't do view frustum culling, LOD, state
sorting, use OpenGL fast paths then you have a lot to gain as the OSG
will do all of these.
Some basic questions:
How do I set a viewing frustrum much like the gluPerspective command?
It depends upon how you want to set things up at the viewer level. If
you are using OSG-1.2 then SceneView is probably the way you'll need
to go to integrate the OSG's rendering into your app, and SceneView
has a method setProjectionMatrixAsPerspective and it'll take exactly
the same parameters with the same meaning as gluPerspective. There
are also equivlants for gluLookAt etc. See the osgsimple example for
inspiration.
In the CVS version there is higher level equivilant to
osgUtil::SceneView, called osgViewer::SimpleViewer that adds optional
event handling support, and support for database pager that SceneView
doesn't support. With SimpleViewer there is a osg::CameraNode*
getCamera() method that you can use to the camera that controls the
view and projection matrices. The osg::CameraNode provides the same
s/getPorjectionMatrixAsPerspection and s/gViewMatrixAsLookAt etc
methods as SceneView (in fact SceneView uses a CameraNode to implement
it so under the hood everything is same.) The osgsimple in CVS now
uses SimpleViewer so again that's not a bad place to start.
How do I resize the window instead of fullscreen on startup?
What are you using for viewer code? osgProducer? If this uses
Producer, and within this library you'll find the
Producer::RenderSurface has a resize method.
A more general question. The app I have loads a massive 3D world
(obtained from a laser scanner) which I've managed to post-process it
down to about
~6000 planes (GL_QUADS) - 167MB of texture
10 million GL_POINTS - 240MB
My Nvidia 6800 has 256MB of RAM so I assume there might be HD swapping
invovled. The question is, is OSG suitable for this large amount
of data?
Well I consider Gigabytes of data is large, some OSG users consider
Terabytes of data large ;-)
The crux is if you want really big data then database paging is what
you'll need to use and the OSG has excellent support for database paging.
For you own task you have data that is small enough not to need
database paging, just careful management of the data. I have used the
OSG for handling just the type of data you are dealing with, and to
get best performance I found the use of VBO's and batching the data is
chunks of around 10,000 points worked well for me. You don't want the
chunks too small as to cause a CPU overhead during culling, but you
don't want them so large as to cause problems when streaming the data
out to the GPU.
I'm not sure what you mean when you talk about planes, but the same
principles apply as with handling points - getting granularity of the
data is important, as is optimizing the mesh itself, I have found that
tristriping + display lists works best on Nvidia. Basically the OSG
support lots of options in this direction.
And for textures, if you find you have too big a footprint then
considering use compressed textures - the OSG support them and is able
to do the compression for you. See osgconv and associated notes on
the wiki about texture compression.
Robert.
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
