Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson writes: Sure we do (but implicitly; see below). That's the whole point of a scene graph -- objects draw themselves into their own coordinate system, and their containers, being higher up in the scene graph, set up the modeling transformation appropriately. Yes this is true, but models move within the scene, and the panel needs to be located at a given xyz in relation to the model not the scene. Of course it could be oriented in the scene as it is now, but it really ought to be placed in the model, hence the suggestion that the orientation data come from the FGModel class. I think what Andy's suggesting is that the panel be part of the model's scene graph. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: Sure we do (but implicitly; see below). That's the whole point of a scene graph -- objects draw themselves into their own coordinate system, and their containers, being higher up in the scene graph, set up the modeling transformation appropriately. Yes this is true, but models move within the scene, and the panel needs to be located at a given xyz in relation to the model not the scene. Of course it could be oriented in the scene as it is now, but it really ought to be placed in the model, hence the suggestion that the orientation data come from the FGModel class. I think what Andy's suggesting is that the panel be part of the model's scene graph. So am I, but panel isn't moved to a scene graph yet. Now that I think about it though, he is still going to need the offsets that the model doesn't know about to implement the mouse action. So never mind. That information is and will be in the property tree. Sometime this week I should be ready to set up the property tree for view data in it's more or less final form. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson wrote: David Megginson wrote: I think what Andy's suggesting is that the panel be part of the model's scene graph. Yeah. What he said. :) So am I, but panel isn't moved to a scene graph yet. Now that I think about it though, he is still going to need the offsets that the model doesn't know about to implement the mouse action. Nope; just the matrices. The panel knows that if it runs an airframe coordinate through teh modelview and projection matrices, it'll get screen coordinates in the range [-1:1]. Just invert that matrix and we can go from screen coordinates to airframe, thence to panel coordinates. It's a little more complicated in practice, but that's the essence of the problem. The panel certainly doesn't need to know anything specific about the model or the viewer. It can do it all on its own, without reference to anything but the OpenGL render state. Again, that's the point behind scene graph architectures. 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] Panel locking to z-offset
Andy Ross writes: Jim Wilson wrote: David Megginson wrote: I think what Andy's suggesting is that the panel be part of the model's scene graph. Yeah. What he said. :) So am I, but panel isn't moved to a scene graph yet. Now that I think about it though, he is still going to need the offsets that the model doesn't know about to implement the mouse action. Nope; just the matrices. The panel knows that if it runs an airframe coordinate through teh modelview and projection matrices, it'll get screen coordinates in the range [-1:1]. Just invert that matrix and we can go from screen coordinates to airframe, thence to panel coordinates. It's a little more complicated in practice, but that's the essence of the problem. The panel certainly doesn't need to know anything specific about the model or the viewer. It can do it all on its own, without reference to anything but the OpenGL render state. Again, that's the point behind scene graph architectures. and you could probably even use the 'hitlist' mechanism almost as is to do this in an SSG way that would return both the face hit and the position in that face :-) I think it is just a matter of putting the cockpit into SSG and then setting up the apropriate 'ray' to intersect with the 'Model' SceneGraph For the 'adventurous' I believe that the 3D cursor stuff from PPE should be convertable to FGFS too. In any event the applicable matrix stuff is all there in 'src / Viewer / ppeViewer.cxx' for anyone inclined to peek Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Panel locking to z-offset
Andy Ross writes: But the core point is valid -- this is essentially a collision detection (or picking -- same thing) problem, and can be solved using all the same tricks. Hence my reference to PPE which constrains the 'picker' to a plane where the math is all worked out for doing this in a SSG friendly way Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Andy Ross [EMAIL PROTECTED] said: Nope; just the matrices. The panel knows that if it runs an airframe coordinate through teh modelview and projection matrices, it'll get screen coordinates in the range [-1:1]. Just invert that matrix and we can go from screen coordinates to airframe, thence to panel coordinates. It's a little more complicated in practice, but that's the essence of the problem. The panel certainly doesn't need to know anything specific about the model or the viewer. It can do it all on its own, without reference to anything but the OpenGL render state. Again, that's the point behind scene graph architectures. Interesting. I've read about this method but assumed it was best for more complex scenes. What I was thinking is that with the offset values you could essentially remap the panel's 2D hot spots to new 2D locations, but that's perhaps a bit heavy computationally. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson writes: It looks like somehow the panel is locking the the offset adjustments. So that if you move into the back seat the panel comes with you. Right -- Andy is not yet using the x/y/z view offsets for the panel transform. Andy? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Andy Ross [EMAIL PROTECTED] said: Your changes to put the panel in a scene graph are the big part of the solution. Really, the panel should be drawn immediately after the aircraft model, with the same matrix environment. If you can get this put together (forgive me if you already have -- I haven't read the changes yet), I'll fix the panel. Well I haven't done that. Ideally (perhaps not a good word :)) the panel code would get the orientation from the FGModel class and a panel XYZ from the model's xml file. We really don't want anything to be dependant on the viewer for that kind of data. How about I publish the model rotation and you can add the panel position XYZ to the translation? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson [EMAIL PROTECTED] said: Andy Ross [EMAIL PROTECTED] said: Your changes to put the panel in a scene graph are the big part of the solution. Really, the panel should be drawn immediately after the aircraft model, with the same matrix environment. If you can get this put together (forgive me if you already have -- I haven't read the changes yet), I'll fix the panel. Well I haven't done that. Ideally (perhaps not a good word :)) the panel code would get the orientation from the FGModel class and a panel XYZ from the model's xml file. We really don't want anything to be dependant on the viewer for that kind of data. How about I publish the model rotation and you can add the panel position XYZ to the translation? Andy, I should have said publish the entire model matrix including the translation not just the model rotation. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson wrote: Well I haven't done that. Ideally (perhaps not a good word :)) the panel code would get the orientation from the FGModel class and a panel XYZ from the model's xml file. We really don't want anything to be dependant on the viewer for that kind of data. Sure we do (but implicitly; see below). That's the whole point of a scene graph -- objects draw themselves into their own coordinate system, and their containers, being higher up in the scene graph, set up the modeling transformation appropriately. Not only should the panel not be going to the viewer for this information; it shouldn't be going *anywhere* for the information. It should simply spew vertices in the aircraft's coordinate frame at OpenGL, and expect that everything should work. That way, you can do any magic you want to the pilot viewpoint, using as many wacky parameters as you can think of, and the panel will always render correctly at its proper location without having to be modified to support your changes. The core point being that, right now, the panel draws itself by erasing the OpenGL matrix stack and starting from scratch. That is wrong, and fragile, and leads to the kind of bug you just discovered. The translation of pilot viewpoint is not something the panel should ever have to worry about. The pilot viewpoint translation belongs in the pilot viewpoint code, and nowhere else. Everything else shoudl just use the matrix stack that it's given. How about I publish the model rotation and you can add the panel position XYZ to the translation? This would work, but like I said, it is fragile. It ties us to a particular implementation. If you want to write new code (say, a smoothly interpolating chase plane view that uses its own offsets), the panel will have to be hacked to comply. 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] Panel locking to z-offset
Andy Ross writes: Not only should the panel not be going to the viewer for this information; it shouldn't be going *anywhere* for the information. It should simply spew vertices in the aircraft's coordinate frame at OpenGL, and expect that everything should work. That way, you can do any magic you want to the pilot viewpoint, using as many wacky parameters as you can think of, and the panel will always render correctly at its proper location without having to be modified to support your changes. For the record, if anyone wants to fix that, they are welcome too. The 2D panel was my very first OpenGL project, written as a learning exercise, and I do not deny that it is sloppy and poorly-integrated in its current state. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
David Megginson wrote: For the record, if anyone wants to fix that, they are welcome too. The 2D panel was my very first OpenGL project, written as a learning exercise, and I do not deny that it is sloppy and poorly-integrated in its current state. Actually, for the 2D panel this behavior is just fine. You *want* to draw into screen space and erase whatever other matrix context might be active. It's only the virtual panel that needs this treatment. What I'd really like to see is for the panel's draw() method to be called with a pre-built matrix stack that transforms model/aircraft coordinates (back/left/up, with the origin at the nose) into screen space. Then we just store corner locations for the panel and draw them. If in 2D mode, we can always push the unwanted matrices down and rebuild them just like we do now. 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] Panel locking to z-offset
Andy Ross writes: What I'd really like to see is for the panel's draw() method to be called with a pre-built matrix stack that transforms model/aircraft coordinates (back/left/up, with the origin at the nose) into screen space. I realize that this is jsut a translation but why at the nose when everything else related to the aircraft is at the 'cg' Then we just store corner locations for the panel and draw them. FWIW I think that you should be able to do this in the current SSG graph of the aircraft model now as a render to texture in the pre draw callback mechanism for a rectangle representing the panel in the model. I realize that this might be slow on some cards but for anything of the geForce2 generation or newer this should work quite well Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Andy Ross writes: What I'd really like to see is for the panel's draw() method to be called with a pre-built matrix stack that transforms model/aircraft coordinates (back/left/up, with the origin at the nose) into screen space. Then we just store corner locations for the panel and draw them. If in 2D mode, we can always push the unwanted matrices down and rebuild them just like we do now. I'd like to plib-ify the whole infrastructure, so that the panel is a single scene graph with ssgTransform nodes for the various animations. I don't think it would be hard, but it's still a bit of an undertaking. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Norman Vine wrote: Andy Ross writes: What I'd really like to see is for the panel's draw() method to be called with a pre-built matrix stack that transforms model/aircraft coordinates (back/left/up, with the origin at the nose) into screen space. I realize that this is jsut a translation but why at the nose when everything else related to the aircraft is at the 'cg' The c.g. isn't a fixed location. It moves when you burn fuel, load cargo or drop bombs, sometimes quite significantly. When I looked, actually, all of the model stuff was relative to the airfame. I can promise that YASim's position output is that of the aircraft nose (well, not necessesarily the nose, but all the current aircraft configurations use this by convention), and I'm all but certain JSBSim works the same way. Which parts are still using the c.g.? we should fix that. 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] Panel locking to z-offset
Andy Ross writes: The c.g. isn't a fixed location. It moves when you burn fuel, load cargo or drop bombs, sometimes quite significantly. When I looked, actually, all of the model stuff was relative to the airfame. I can promise that YASim's position output is that of the aircraft nose (well, not necessesarily the nose, but all the current aircraft configurations use this by convention), and I'm all but certain JSBSim works the same way. JSBSim references any arbitrary aero reference point. We try to use the same one as the manufacturers, when it's published (i.e. on the floor by the firewall for small Cessnas). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Panel locking to z-offset
It looks like somehow the panel is locking the the offset adjustments. So that if you move into the back seat the panel comes with you. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson wrote: It looks like somehow the panel is locking the the offset adjustments. So that if you move into the back seat the panel comes with you. Locking? No. Ignoring. :) The virtual panel code always draws itself with the origin at the eyepoint. This is because it was basically done backwards -- it figures out where the panel should be on the screen based on the view direction offset from the aircraft frame. The *right* way to do this would be to just push a transformation on the stack that maps panel coordinates to aircraft coordinates, and assume that the code higher-up has set up the modelview matrix appropriately for the cockpit reference frame. Your changes to put the panel in a scene graph are the big part of the solution. Really, the panel should be drawn immediately after the aircraft model, with the same matrix environment. If you can get this put together (forgive me if you already have -- I haven't read the changes yet), I'll fix the panel. 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
