Curt, Thanks, this has been very helpful. Been playing around with ssg a little bit and trying to gleen some sort of understanding from the documentation, which is very good but in some cases terse.
It looks like the panel graphic objects will need to all be ssgTransform nodes so that they can be rotated, etc. Somehow I need to come up with a system for keeping track of which nodes belong with which instruments so the coordinates can be manipulated. I'm assuming that I will need a node for each individual part of each instrument (ie several nodes for some individual instruments). It's not clear how I can group together the components that make up a given instrument (or even if I should!), so that say a major branch (if there is such a thing) would have multiple ssgTransform nodes on it all belonging to the same instrument...e.g. HSI. Anyway, what I'm trying to do here is outline where my thinking is going so that I can get this fairly right the first time. Mostly I'm interested in whether anyone else has ideas on organizing the scene graph tree. Best, Jim "Curtis L. Olson" <[EMAIL PROTECTED]> said: > David Megginson writes: > > Jim Wilson writes: > > > > > And the question that brings to mind is, how will we be able to set > > > the z axis in a way that it can handle the panel? In other words, > > > the scale is so large now that it'll disappear just like airplane > > > model components do when viewed too closely. Can we have two > > > different scales in the same tree/graph? > > > > Actually, I'm not sure -- any advice from the PLIB gurus? > > I'm not sure about your definition of the z axis ... in this case your > question makes sense if we define the z axis to be along the center of > projection. > > This really is more of an opengl issue than a plib issue. > > Opengl defines the view volume to be a frustum (just like a pyramid > with a bit of the top lopped off.) You can refer to the picture here > for an example: > > http://www.cs.ucf.edu/~moshell/CAP5725/CAP5725.week4.html > > So if a portion of the scene is closer to us than the near clip plane, > it will be clipped out. That is what happens when you get the > external view point too close to the aircraft. Similar wierdness if > you set the far clip plane too far away and then get too close to the > ground. > > The good news is that you can reset the clip planes at any time during > the rendering process meaning you can render a portion of the scene, > then move one or both clip planes, and redraw another portion of the > scene, continuing this as much as needed. > > The bad news is that certain driver optimizations can get screwed up > if you move the clip planes (ie. the fog tables in some versions of > mesa). Or the driver may be forced to recompute things like fog > tables and other values when you change the position of the clip > planes. Thus, there can be visual artifact and or performance > implications with moving the clip planes. > > Also, be aware that the precision of the depth buffer is *very* > sensitive to the position of the near clip plane: > > http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html > > The conclusion is that for best depth buffer precision we want to push > out the near clip plane as far as possible. The position of the far > clip plane is mostly irrelevant, although it has to be beyond the > furthest object we want to see. :-) > > So the point of all this is that we can draw the world, then move the > near clip plane in, and then draw the panel. > > This would work best if we put the panel into a different scene graph > from everything else: > > setclipplanesforworld(); > ssgCullAndDraw(world); > > setclipplanesforpanel(); > ssgCullAndDraw(panel); > > Regards, > > Curt. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
