Thanks, Mr. Osfield, your patience is grateful.
I'm using exactly Win32 directly and WPF as frontend. Thanks to your advises, i have achieved a WPF application with an OSG window inside (needed to modify GraphicsWindowWin32 a bit due to WPF requirement). Now i have a base code to start my GIS development. I will look carefully at the examples you mentioned, it's great to have such a bunch of them! There is a Quick Start Guide, a Reference Manual, is there any plan to develop an 'Complete OSG Guide' or 'OSG Tips and tricks' or whatever any more documentation? The QSG is a great job, but for a new user like me, it is so great explained, that i miss the 2nd part. In my opinion it doesn't reflect the whole potential that OSG have (and the wonderful work it is). There are a lot of code, explanations and tips spreaded out. :( Thanks again for such a job! Himar PD: Have anybody noticed that the TOC of the QSG is misnumbered at page 38 and nexts (at least my revision is)? 2007/6/26, Robert Osfield <[EMAIL PROTECTED]>:
Hi Himar, I'm not familiar with the osgviewerMFC example, but it could be that it itself itsn't an ideal example to learn from. I'd recommend learning from the other OSG examples such as osgcompositeviewer, osgcamera, osgwindows. The idea behind Camera's in osgViewer is that your viewer (Viewer or CompositeViewer) has one or more Views, and each View has a master Camera which you get via view.getCamera() and set this directly or set it via a CameraManipulator. This master camera controls the overall view matrix and projection of that view i.e. where you look at and what the lens is. For a single camera view you just need the master, and no slaves are required. This covers probably 90% of usage. The View does another trick up its sleeve for more complex applications that require the View to be composed of a set of cameras, for instance a 5 sided caved will have 5 slave cameras that make up the view, or a 2 screen powerwall will have 2 slave cameras. There type of exotic display system is extremely well supported by the OSG thanks to the concept of slave cameras - it makes it easy to migrate from a simple single camera view in a desktop app to a full blown immersive visualization. If you are writing an MFC basd app then there is a good chance you really arn't trying to target an exotic display system, you actually just want a view to have one camera, and won't need the extra complexity of managing a slave camera. Robert. On 6/25/07, Himar Carmona <[EMAIL PROTECTED]> wrote: > Hi, > > When setting the camera for a viewer, i see there are multiples choices. > What osgviewerMFC does is setting the camera calling: > > viewer.addSlave(camera.get()): > > I'm following that code (because i'm new) , but i'm also noticed there is > a method viewer.setCamera. > > What's the difference between > > viewer.addSlave(camera.get()); > > and > > viewer.setCamera(camera.get()); > > ?? > > My example simply loads cow.osg. If i use the first statement, i see the > happy cow in the middle of the window, but if i use the second one, i see > the cow very near to the view (and can't zoom out). Which approach is best? > (if there is any?). > > Also, how can I set the position of the camera? (viewer, camera, > manipulator??) > > Sorry for such a silly question, but haven't catch yet the natural > approach for working with OSG... :( > > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
