RE: [Flightgear-devel] Jitterbug pinpointed
Norman Vine [EMAIL PROTECTED] said: Andy Ross writes: Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Right --- So why not leave the camera at 0,0,0 and add an additional offset to the 'tile-offset' When I first saw this suggestion what came to mind was using camera at 0,0,0. Applying the offset (difference between our current view position and the scenery center) to the scenery. And applying the difference between our view position and the model origin (aircraft position) to the model. But I guess I'm a little confused on how this would be done. Would we apply the same rotation matrix with an adjusted translation vector? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
Jim Wilson writes: Norman Vine [EMAIL PROTECTED] said: Andy Ross writes: Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Right --- So why not leave the camera at 0,0,0 and add an additional offset to the 'tile-offset' When I first saw this suggestion what came to mind was using camera at 0,0,0. Applying the offset (difference between our current view position and the scenery center) to the scenery. And applying the difference between our view position and the model origin (aircraft position) to the model. But I guess I'm a little confused on how this would be done. Would we apply the same rotation matrix with an adjusted translation vector? Yes, but this is the easy part :-) Not really sure yet how to get the Terrain Intersection routines working with an 'offset' from the tile_center, and the since the scenery tiling is NECESSARY due to 'precision issues', we can'y adbandon it. I know it should just be another translation but I can't seem to get it working right thinking publically Since the scenery tiles are in are in a tile-relative coordinate space we should just have to add vdiff = ( scenery_center - abs_view_pos ) to the scenery_center in the ssg_prep_tile() call and subtract vdiff from the scenery_center in the scenery intersection routines / Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
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
Re: [Flightgear-devel] Jitterbug pinpointed
Norman Vine wrote: Following is IMHO a good explanation as to why having the camera a node in the scene-graph is not 'necessarily' a 'good idea' Which is a good point in theory. Their basic idea is that the scene graph specifies data, and you interpret that data via a camera. These are two well-defined and separate areas, and should be kept separate in code. The problem is that this leads naturally to precision problems exactly like our jitter -- you can't just push transforms onto the matrix stack willy nilly (in this case, moving ~1.0e+07 cockpit-pixels away and coming back) and expect things to work nicely. These are finite computers, and they have finite precision. Sure, it's cleaner in principle to have all the scene data separated from the camera data, but until we have arbitrary-precision GPUs these two halves need to coordinate so they don't step on each others toes. 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] Jitterbug pinpointed
Andy Ross writes: Which is a good point in theory. Their basic idea is that the scene graph specifies data, and you interpret that data via a camera. These are two well-defined and separate areas, and should be kept separate in code. The problem is that this leads naturally to precision problems exactly like our jitter -- you can't just push transforms onto the matrix stack willy nilly (in this case, moving ~1.0e+07 cockpit-pixels away and coming back) and expect things to work nicely. These are finite computers, and they have finite precision. Sure, it's cleaner in principle to have all the scene data separated from the camera data, but until we have arbitrary-precision GPUs these two halves need to coordinate so they don't step on each others toes. I haven't been following this thread as closely as I should have been, but there should be no reason why we'd need to have the camera in the scene graph. I think we just need to be smarter about how we structure the transforms. Someone mentioned that currently we have a transform for part of the scene then for the model we have a transform that undoes part of the original transform??? It seems like that could be restructured to avoid those sort of numerical problems. The scene graph is just a convenient way to hold geometry data. There's nothing magical about it, it just gets translated into a big bunch of opengl primitives when we call ssgCullAndDraw(). There's nothing magical about having multiple scene graphs vs. one scene graph, in the end you still get basically the same set of opengl primitives. The advantage to splitting up a scene into separate trees is that it allows you to do things in between rendering sections of your scene. This is mostly an 'optimization' or 'perfomance' issue. We put light points in a separate tree so that we can change fog and other global parameters once before rendering all the lights. Otherwise we'd have to do this via call backs, but since call backs can only be attached to leaf nodes, we'd have to change state before each lighting leaf node, and reset it back after each one which would be much less efficient. 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] Jitterbug pinpointed
Curtis L. Olson wrote: I haven't been following this thread as closely as I should have been, but there should be no reason why we'd need to have the camera in the scene graph. I think we just need to be smarter about how we structure the transforms. That was my original suggestion: put the camera origin at the viewpoint, and insert one ssgTransform node on top of the terrain that moves it to the tile centroid, and another above the model that moves it to the model origin. The camera business came up because I suggested that this sort of mistake is very easy to make with the camera living outside of the scene graph. The proof: Jim (no slouch as a 3D programmer) didn't realize that the bug still applied in cockpit mode, even though the model was in its own scene graph. The fact that the camera lives separately from the graph is, IMHO, a mistake. But it's tangential to the bug. There's nothing magical about having multiple scene graphs vs. one scene graph, in the end you still get basically the same set of opengl primitives. True, but the more special rules there are (e.g. cameras aren't the same thing as ssgTransform nodes), the less obvious the set of OpenGL primitives that will be generated is. No one would ever think to do the following in OpenGL: Move +1000m Draw the Terrain (~100m from the viewpoint) Move -1000m Draw the Cockpit (~0.1m from the viewpoint) But that's exactly what happened to us. It happened because the two move lines are not implemented the same way -- the first happens in ssgSetCamera, the second is an ssgTransform node at the top of the model scene graph. The right solution (ignoring orientation, which is fine as-is) is this: Move 0m in the camera Move +1000m Draw the terrain Move ~1m to the aircraft origin Draw the cockpit 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] Jitterbug pinpointed
Andy Ross writes The right solution (ignoring orientation, which is fine as-is) is this: Move 0m in the camera Move +1000m Draw the terrain Move ~1m to the aircraft origin Draw the cockpit Indeed ... which is why I pointed out 'where' in the code it was easiest to do this To experiment I believe all you should have todo is change the value for 'center' in prep_ssg_nodes( vis, up, center ); in tilemngr.cxx to reflect the 'offset' you want. I guess I wrongly assumed that everyone would read this as just add the appropriate offset to move the camera to the origin :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Norman Vine wrote: I guess I wrongly assumed that everyone would read this as just add the appropriate offset to move the camera to the origin :-) Unless I'm still not understanding you, I think you misunderstand the issue. Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Once that 1000m transformation is on the stack, it's too late -- you can't recover precision you've already lost. 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] Jitterbug pinpointed
Andy Ross writes: Norman Vine wrote: I guess I wrongly assumed that everyone would read this as just add the appropriate offset to move the camera to the origin :-) Unless I'm still not understanding you, we do seem to have a communication gap :-) not-all-M$oft-users-use-the-gui'ly yours Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes: Unless I'm still not understanding you, I think you misunderstand the issue. Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Once that 1000m transformation is on the stack, it's too late -- you can't recover precision you've already lost. Just to summarize, I think that Andy is recommending that the camera location *always* be 0,0,0, and that scene graphs be transformed appropriately for rendering. Is Norm suggesting something different? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
Andy Ross writes: Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Right --- So why not leave the camera at 0,0,0 and add an additional offset to the 'tile-offset' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Jitterbug pinpointed
David Megginson writes: Andy Ross writes: Unless I'm still not understanding you, I think you misunderstand the issue. Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Once that 1000m transformation is on the stack, it's too late -- you can't recover precision you've already lost. Just to summarize, I think that Andy is recommending that the camera location *always* be 0,0,0, and that scene graphs be transformed appropriately for rendering. Is Norm suggesting something different? I guess I have to 'spell out' my hints in their entirety but I am saying the same thing PLUS giving 'hints' as to what part of the code also needs to change. BUT IMHO this is still a suboptimal solution in that it is MUCH easier to just use separate scene graphs as I and others have been 'suggesting' ever since the 'rewrite' was first proposed refactoring-a-graph'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Jitterbug pinpointed
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. Really I've got to get more into ssg to understand how all this works better. For some reason I seem to have an easier time understanding the lower level opengl stuff now than plib (which probably sounds backwards). I have the same trouble. You can debug OpenGL transformations by looking at code and inspecting the matrices via printf where you know the problem is. With plib, you have to stare at a scene graph dump. These are really useful, by the way -- just call the print() method on the top level node. The only significant problems are that it's 10 megabytes of dump, mostly of tiles that aren't interesting; and that most of our nodes don't have names -- I added a bunch of setName() calls to the ssg nodes to tell where I was. My first concern would be about the overhead of transforming the terrain each frame (lots and lots of vertices). You don't transform the vertices in memory -- just push an extra matrix on the stack and OpenGL will combine them for you. The extra performance cost is almost exactly zero (one matrix multiplication per frame). If it can be done, I think my earlier suggestion of rendering the Cockpit with no position offsets might work. Can't we render everything else and then lastly set the camera to the pilot's nose Sure thing. That's basically the same idea, but it works only for the cockpit. If you fix the double-transform stuff in general, the outside view will stop jittering too. 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] Jitterbug pinpointed
Norman Vine wrote: To experiment I believe all you should have todo is change the value for 'center' in prep_ssg_nodes( vis, up, center ); in tilemngr.cxx to reflect the 'offset' you want. No, that won't work unless you can guarantee that the offset value will always be within ~100m of the viewpoint. The problem isn't that the offset exists, it's that it's being pushed onto the matrix stack twice -- once to draw the terrain, and once to undo it to draw the aircraft model. The model must be drawn with its own viewpoint-to-origin translation, and shouldn't care about the terrain's origin. The terrain translation is too big, and causes FPU/GPU precision problems at scales the aircraft model cares about. 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] Jitterbug pinpointed
Andy Ross [EMAIL PROTECTED] said: Camera (orientation only, no position change) | +-- Transform (move to terrain origin) || |+-- Terrain | +-- Transform (move to model origin, orient to model frame) | +-- Aircraft Model I got started trying to figure out how to do this, but got a little lost. Jim, you know this code a lot better than I do, how hard would that be to do? I can see what you are saying...but the aircraft (in the cockpit view) is actually a different scene graph. Really I've got to get more into ssg to understand how all this works better. For some reason I seem to have an easier time understanding the lower level opengl stuff now than plib (which probably sounds backwards). My first concern would be about the overhead of transforming the terrain each frame (lots and lots of vertices). If it can be done, I think my earlier suggestion of rendering the Cockpit with no position offsets might work. Can't we render everything else and then lastly set the camera to the pilot's nose ( ie with only the offset from aircraft origin and no position offsets or orientation rotations applied). In other words just render it on top of the rest at 0,0,0 plus a little offset to the pilot seat so the cockpit looks right? Or is changing the camera like that not allowed? Note that if we did this we would still need to apply the view offsets so you can pan view and look down at the ruder pedals properly. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
