Re: [Flightgear-devel] Problem with panel code
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
Re: [Flightgear-devel] Problem with panel code
David Megginson wrote: 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 have no Plib insight to offer, but the core problem isn't very difficult at all. Panel geometry is static, and can really easily (by hand in the XML, even) be sorted back to front. Just turn off z-test, set up the projection appropriately, and draw. I'm sure this must be doable in Plib somehow. So long as the graph can guarantee an order of drawing, we can write a state node to set up the matrices. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with panel code
Sure. Scaling is not a problem with plib. The classes ssgTransform and ssgTexTrans are put in the scene graph to control object and texture transformations of their kids. One of the setTransform operations allows scaling. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: David Megginson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Problem with panel code 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? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
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. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with panel code
Vallevand, Mark K writes: Sure. Scaling is not a problem with plib. The classes ssgTransform and ssgTexTrans are put in the scene graph to control object and texture transformations of their kids. One of the setTransform operations allows scaling. Be careful with scaling objects though because this can screw up things like normal vectors (which would then screw up lighting.) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problem with panel code
Yes, you are correct. In fact, this explains an artifact I'm seeing in one of my programs. The normals must be getting screwed up because of scaling because lighting is funny on a pair of identical objects that have been scaled and rotated. I'll have to chase that idea down. Regards. Mark K Vallevand Fat, dumb and happy. 2 out of 3 ain't bad. -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 20, 2002 3:15 PM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] Problem with panel code Vallevand, Mark K writes: Sure. Scaling is not a problem with plib. The classes ssgTransform and ssgTexTrans are put in the scene graph to control object and texture transformations of their kids. One of the setTransform operations allows scaling. Be careful with scaling objects though because this can screw up things like normal vectors (which would then screw up lighting.) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
Curtis L. Olson [EMAIL PROTECTED] said: This would work best if we put the panel into a different scene graph from everything else: setclipplanesforworld(); ssgCullAndDraw(world); setclipplanesforpanel(); ssgCullAndDraw(panel); Does this make sense? Setting up a seperate scene graph? Perhaps it should be called cockpit so that a 3d cockpit can be added. Now I just have to figure out where to start :-) Time to look at those ssg examples. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
David Megginson [EMAIL PROTECTED] said: Andy Ross writes: I have my own peeves about the panel coordinate conventions. I wrote the code after about two hours puzzling through examples in an OpenGL book, which was my first exposure to 3D programming. It works, but I agree that it's ugly. Think I'm reading the same book now :-) One of the things I'd really like to see at some point is the ability to paste a 2D panel onto a polygon in a 3D virtual cockpit. In principle, this should be easy. In practice, the use of screen coordinates makes this difficult. How should one interpret y-offset in a 3D environment, for example? You should ignore it completely -- the pilot position and viewing direction would control what part of the panel you see. The right thing is to integrate the panel code into the main SSG scene graph. Any volunteers? I could be one. Can you explain generally what you mean by integrate the panel code into the main SSG scene graph? Basically, yes I don't yet know what you mean by main SSG scene graph. Otherwise been thinking about two mini projects with the panel in the near term. One is to do an approx model of a real autopilot with a real pitch hold/adjustment, etc. The second is to set up a processor for ribbon textures...that could be configured in XML and used for compasses and/or an integrated (xml defined) GC style instrument. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
On Tuesday 19 February 2002 07:15 pm, you wrote: David Megginson [EMAIL PROTECTED] said: Andy Ross writes: I have my own peeves about the panel coordinate conventions. I wrote the code after about two hours puzzling through examples in an OpenGL book, which was my first exposure to 3D programming. It works, but I agree that it's ugly. Think I'm reading the same book now :-) One of the things I'd really like to see at some point is the ability to paste a 2D panel onto a polygon in a 3D virtual cockpit. In principle, this should be easy. In practice, the use of screen coordinates makes this difficult. How should one interpret y-offset in a 3D environment, for example? You should ignore it completely -- the pilot position and viewing direction would control what part of the panel you see. The right thing is to integrate the panel code into the main SSG scene graph. Any volunteers? I could be one. Can you explain generally what you mean by integrate the panel code into the main SSG scene graph? Basically, yes I don't yet know what you mean by main SSG scene graph. Otherwise been thinking about two mini projects with the panel in the near term. One is to do an approx model of a real autopilot with a real pitch hold/adjustment, etc. The second is to set up a processor for ribbon textures...that could be configured in XML and used for compasses and/or an integrated (xml defined) GC style instrument. Best, Jim Theres a function for built ins in panel_io.cxx that wraps the view around. Currently it's used for the mag compass. TTYL John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with panel code
Jim Wilson writes: I could be one. Can you explain generally what you mean by integrate the panel code into the main SSG scene graph? Basically, yes I don't yet know what you mean by main SSG scene graph. Go to plib.sf.net and read the docs on SSG. Basically, it holds the whole 3D scene in a tree (or graph) and handles the rendering details itself. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
