I know, I know but our program gives to the user the access to object vertices and we can’t all the times convert them. I will try to study deeper this magic GPU RTE approach…
Thanks again,
Alberto
Looks like the GPU RTE approach needs VBO & shaders. Am I right? We need something that work on any OpenGL implementation. I would try the links suggested at the beginning of the article…
Alberto
Yes, it requires shaders! Unfortunately, it cannot be implemented on CPU. In the same article you can find also a CPU based solution, but it is not “so magical”.
I don’t see the problem enabling users to change real coordinates, but before sending them to rendering call World2Scene() function and vise versa.
Can you point me to the CPU based approach?
Thanks,
Alberto
The same article as for GPU RTE (@ http://blogs.agi.com/insight3d/index.php/2008/09/03/precisions-precisions/)
Section The Center of All Things is a CPU approach.
Aleksandar,
I tried to implement the
The Center of All Things is a CPU approach
without success an we are sure that something is missing.
This article suggest to alter the MV matrix from
0.000000 -0.976339 0.216245 -13.790775
0.451316 -0.192969 -0.871249 -7,527,123.004836
0.892363 0.097595 0.440638 -14,883,050.114944
0.000000 0.000000 0.000000 1.000000
to
0.000000 -0.976339 0.216245 -13.790775
0.451316 -0.192969 -0.871249 0.406574
0.892363 0.097595 0.440638 -81.089615
0.000000 0.000000 0.000000 1.000000
But this of course is not enough.
Can you please help me discover what is missing? Thanks.
Alberto
I have already told you that this method is not “a world solving” one. First, there are errors in the example. Just X coordinate is correct. But that changes nothing.
The problem with this solution is that it assumes all objects are drawn in their local coordinate-systems. Replacing last column of the model-view matrix, only a huge translation is eliminated. So, the shuttle is drawn correctly, because it is in the coordinate-system’s origin, and the viewer is moved just a little bit from it.
In order to be able to use this method, you have to express coordinates of your objects locally (relatively to some origin that is in the object or near it), and save displacement of that origin in world coordinates. Remember, fixed functionality (thus far) does not permit using double precision values. A single precision floats have only 5-6 significant decimal figures. Having UTM or LatLon coordinates does not permit even a meter resolution, and that is not enough for CAD applications. Consider revising the way coordinates of the objects are stored, or turn to the method I’ve proposed earlier.
Aleksandar,
I wish I could find a single triangle example that draws without jitter at 1,000,000 from origin so I can study how to apply it to our code…
Thanks,
Alberto
I wish I could find a single triangle example that draws without jitter at 1,000,000 from origin so I can study how to apply it to our code…
The problem is that no such case exists, because numbers passed to OpenGL are never that big. The way to do this means never giving OpenGL large coordinates. So you have to restructure the code you use to set up rendering so that it doesn’t pass OpenGL large coordinates.
Let’s say that your camera is at (50234294.3282, 93947293.2983) You want to draw something that is in sight of the camera, and it is at (50234227.3282, 93947219.2983).
All of the coordinates you pass to OpenGL must be relative to the camera’s position. So given the above, the camera matrix you give OpenGL should be at (0.0, 0.0). The matrix for the something above should be at (-67, -74).
That’s all. Your coordinates in your code should be in doubles, but when you convert them to floats you first convert them into offsets from the camera (also in doubles).
For the magnitudes you’re talking about, just do all MODELVIEW computations in doubles (fp64) in your code. Do not use GL/GLU to do MODELVIEW computations. They can only handle float (fp32), and therein lies your problem.
Or resort to local origins as described.
Thanks Dark Photon, we made a step ahead, please read this:
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=272879#Post272879
Now the problem is to recover the camera space. Can you help me on this?
Thanks,
Alberto
Suggest you just use doubles. Then there’s no need to “recover the camera space”.
Dark Photon,
Did you check the C++ sample provided by wSpace?
It includes the following trick, but when you need the camera space you cannot use the conventional eye, target, up as before because of the additional matrix multiplication. We need it to compute the bounding volume of the model aligned with the camera frame. What is your opinion? We even tried to subtract the gBoxCenter from both the gEye and gBoxCenter points but still is not correct.
//
// RTC method
//
// Here, we are doing the math in double precision and
// then submitting the result to OpenGL as floats.
//
double modelViewMatrix[16];
lookAt(gEye, gBoxCenter, gUp, modelViewMatrix);
double boxTranslationMatrix[16] = {
1.0, 0.0, 0.0, 0.0,
0.0, 1.0, 0.0, 0.0,
0.0, 0.0, 1.0, 0.0,
gBoxCenter.x, gBoxCenter.y, gBoxCenter.z, 1.0};
double boxModelViewMatrixd[16];
matrixXMatrix(modelViewMatrix, boxTranslationMatrix, boxModelViewMatrixd);
//
// Note that while we called it this way, we could have called
//
// glLoadMatrixd(boxModelViewMatrixd);
//
// OpenGL would have downcast the doubles to float. We did it below
// with floats just to emphasize the fact that in the end, we
// are giving OpenGL float values.
//
float boxModelViewMatrixf[16] = {
(float)boxModelViewMatrixd[0], (float)boxModelViewMatrixd[1], (float)boxModelViewMatrixd[2], (float)boxModelViewMatrixd[3],
(float)boxModelViewMatrixd[4], (float)boxModelViewMatrixd[5], (float)boxModelViewMatrixd[6], (float)boxModelViewMatrixd[7],
(float)boxModelViewMatrixd[8], (float)boxModelViewMatrixd[9], (float)boxModelViewMatrixd[10], (float)boxModelViewMatrixd[11],
(float)boxModelViewMatrixd[12], (float)boxModelViewMatrixd[13], (float)boxModelViewMatrixd[14], (float)boxModelViewMatrixd[15]};
glLoadMatrixf(boxModelViewMatrixf);