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
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
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
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
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
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
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
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
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
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
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
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
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
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
I spent some time over the weekend struggling with the jitterbug
(sorry, couldn't resist). I haven't fixed it, but I have pinpointed
the issue.
In essence: yes, it's a precision problem; but no, Jim's calculations
aren't the problem. The problem is actually the organization of the
scene graph.
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
16 matches
Mail list logo