Andy Ross writes: > >Jim Wilson wrote: >> I can see what you are saying...but the aircraft (in the cockpit view) >> is actually a different scene graph. > >But it's under the same camera (oddly, ssg puts the global camera >"outside" the graph, when it's logically the top-level node of the >graph), and has the same double-transform problem; it just doesn't >happen to use the terrain frame for anything.
Where the camera 'resides' with respect to the scene-graph can be confusing Following is IMHO a good explanation as to why having the camera a node in the scene-graph is not 'necessarily' a 'good idea' Note this discussion was on the Open Scene Graph list and is not about the SSG camera but the principals discussed are exactly the same Norman ================ > My research group has started using OpenSceneGraph recently. One thing > that I don't understand is why the camera is not in the scene graph. Having a camera node as part of the scene graph seems natural to some engineers, alien to others. The former in general come from an Inventor type scene graph background, the later from a Performer type scene graph background. Personally I have no strong opinions, I see both approaches as being useful, but I think requiring a camera as part of the scene graph to use the scene graph would be bad design, as would not be flexible enough for many users. To define your view in the OSG all you need is a projection matrix and modelview matrix. How you generate these is up to the programmer. The osg::Camera exists to encapsualate some of the set up of these matrices, but it purely an optional extra these days. This is a *really* good thing, as it allow users to write their own camera code, or integrate it with pre-existing camera code with minal effort. To have a camera node is a scene graph poses some interesting questions, especially when you can share subgraph such as you can do in the OSG. Consider adding a camera node to the the head of soldier in the turret of a tank, the head can move, the turret can move and the tank can move. This implies a hierachy of transform nodes, the leaf node being the camera node. To render the view from the soldier, first we have to work out the modelview matrix to do this we have to invert this accumulated transform. This should is not difficult, but might not be unique as the OSG allows you to have multiple parents. For example, the tank might be instanced 100 times a battle field, which tank do you choose? To resolve this you need to specifiy a unique path from the root of the scene graph being viewed to the leaf camera node. This path would be naturally tied to the view, rather than the camera node. If you take another step, if you need this unique path in your view then the camera node itself could just be a normal OSG node, as its the accumulated transforms which define the modelview matrix, not the camera node. One might use the camera node to store a local transformation to multiple the modelview matrix by, but for this you might as well just use a standard osg::Transform. One can of course add more data into a camera, such as projection details, but these depend up the viewport dimensions/aspect ratio, so a much more closely tied to the view of the scene, rather than a specific node in the scene graph. Clearly it isn't entirely natural for a camera to be part of scene, although the concept of camera platform, something to position a camera view is useful, but in the end the really important thing is to get the path to the camera platform. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
