On 5/15/07, Johannes Brunen <[EMAIL PROTECTED]> wrote:
I have installed OSG 1.9.4 and tried the osgviewerMFC example. Some
notes on that:

1. The example project didn't worked with MSVC 7.1 (probably because it
has just been published and need some integration polishing).
etc.

I checked in the example to get it out in the hands of the community.
It doesn't yet have a CMakeLists.txt file to enable the CMake build
system to create the project files for you.   This is something the
community needs to add as I don't have a Windows dev machine.

W.r.t. other features and bugs, don't forget this is just a first cut
contribution from a member of the community, hot off the press and
still under development.  Normally code doesn't take too long to bed
down.  Remember, everybody has the same rights to modify the code, so
we are all user/developers, so if you see something that can be fixed,
fix it and send me the changes.


Some additional questions:
        - Could you please provide an example on using the viewer's
frame() function, properly?

while(!viewer.done()) { viewer.frame(); }

Is there good enough?

This question is really open ended, there are lots of ways of using
doing the viewer frame loop, different ways for differnt examples.

        - Can I use the example with the CompositeViewer class?

You should be able to.  The MFC would possible be better off using the
CompositeViewer.

        - You gave me two alternatives for the window  integration but
I'm undecided which is the
          better route (osgviewerMFC or osgsimpleviewerWX).

Examples on osgViewer::SimpleViewer like osgsimpleviewerWX etc will
make way for more sophisticated viewer integration examples using
VIewer and CompositeViewer.  Youl could use SimpleViewer, but given
you spec list I think you'd grow out of it quickly.

Allow me to repeat our requirement list. Could I find solutions for
these within the OSG framework?

        - We must be able to handle the manipulation code ourself, or at
          least define our own manipulation scheme

Yes.  The OSG can be controlled in fine grained ways and coarse
grained ways.  See the osgGA event handlers/manipulators or the
osgManipulator library, these are all just examples of things you can
use, but you can role your own.

        - We must be able to print the scene shown in a window

This really is down to your app.  The OSG isn't an application
framework.  Printing a screen is normally done by doing by attaching a
post draw callback and then osg::Image::readPixels() to get the image.
After that you'll need to you send this to print somehow.

        - We must be able to print the scene from a viewpoint without a
          window

You can use an FBO or a Pbuffer for this.  Right now Pbuffer isn't yet
supported in osgViewer, but the framework for supporting them is all
there.  FBO's are supported natively.  See the osgprerender or
osgdistorion examples to see render to texture cameras in action.

        - We must be able to create bitmaps (i.e. images) from the scene
          shown in a window

Image::readPixels again.

        - We must be able to highlight nodes in the scene dynamically

See the osgmultiplecameras example as this shows osgFX:Scribe being
used for highlighting picking objects.

        - We must be able to have exstended cursor handling, i.e. show
          sophisticated cursors dynamically (currently performed by
logical xor
          drawing)

This really isn't a scene graph issue, its an application/GUI issue.

        - We must be able to do rubber banding operations, e.g. only
          modify a bunch of line graphics with a static probably huge
background
          scene.

The OSG doesn't directly support this, but you can implement it yourself.

The OSG is powerful toolbox, but is general purpose, so doesn't tend
to have many domain specific high level features.  The type of app you
are talking of really doesn't sound too different than that many OSG
users already have, so I really don't think there will be any show
stoppers, just a matter of a bit leg work here and there when you get
to real specialist features.

Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to