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
