OpenGL What is the best way to implement extreme zoom in Orthograhic mode?

This topic is 4927 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hey what is the best way to implement zoom in orthographics. I need to have the ability to do extreme zoom. Say I want to create a line from (0,0,0) to (0.000000000000000001, 0, 0); I want to be able to zoom that deep. I use a zoom factor in gluOrtho() per the OpenGL faq on zoom. So my question is what is the best way to change the zoom factor. The way I have it implement it now is that I add a small value to zoom factor. If it falls below a certain threshhold I change the small value to a smaller value. The zoom factor approaches the limit 0. Say I have:
[source lang = "cpp"]

void initialize()
{

zoomFactor = 1.0 / 2;

}

void zoom(dir)
{

double temp = zommFactor * 0.1 //10% of zoomfacotor

if(dir < 0)
temp = -temp;

zoom += temp;

if(zoom < zoomFactor)
zoomFactor = zoomFactor / 2;
else if(zoom > zoomFactor * 2;
zoomFactor *= 2;

}

So what is the best way to implement something like that.

I will of course ponder more on this problem. I just want to throw this out there and see if you guys can help me.

Thanks.


Share on other sites
Naw, that is a really stupid way to do it...

I'm saw some code on Codeguru and I'm going to use some ideas from that...

I will report back here what I did...

Share on other sites
This is what I'm doing now:

he idea is that since we know the extend of our ortho object
coordinate dimension (i.e size of the ortho view in real world coords)
we can continously shrink this window.

To shrink the window we calculate the height of the ortho dimension
(we may need to worry about aspect ratio etc) and divided it
into window height number of pieces.

I.E: shrinkFactor = abs(orthoMaxY - orthoMinY) / windowHeight;

IF we move the mouse 1 pixel this will corrspond to shrinking 1 unit
of the ortho window. So we simply do this:

shrinkFactor *= pixelUnit; I.E where pixelUnit is MouseY - oldMouseY
//# of pixels moved

we then shrink uniformly the window by:

orthoMinY += shrinkFactor;
orthoMaxY -= shrinkFactor;
orthoMinX += shrinkFactor;
orthoMaxX -= shrinkFactor;

Is this a good idea?

Share on other sites
I do my Ortho zooming in this way
glOrtho(left*zoom_factor,right*zoom_factor,bottom*zoom_factor,top*zoom_factor,near,far);

In this way it's possible to manipulate only the perspective matrix...

Share on other sites
I did that at first by how do you zoom to extreme small values? Can you zoom to a line that is from 0,0,0 to 0.0000000000000001, 0, 0

How do you factor you zoomFactor?

I had the problem where my zoom was increasing by too much, so I lose alot of precision at these small values...

Share on other sites
The factor is a float (or a double), so it depends on what happens when you Zoom-In/Out... Instead of multiplying your current zoomfactor, you could add a fixed quantity to it, so your increase/decrease will be slower (and will seem smoother)... obviusly you could adjust the value to add to the zoomfactor while zooming (if really far you could use a +1 increment, if nearer a +0.00001 increment... or you could create a function to retrieve the correct increment depending on camera position... just an idea...) ^^

Share on other sites
u will have precision troubles with very small/big numbers
just keep a variable with each mesh saying at what scale it is eg scale = 0.001
keep all the verts in the range 0.001->1000 say (reality = 0.0000001->1.0)
and just draw the 0.001->1000 values to the screen. anytime u wanna output the data to the person just multiple the values by the scale

Share on other sites
Yeah, thanks. ALl great ideas.

I have major precision problems with my new method. For the longest time I thought it was an aspect ratio problem because when I get down to the 1e-8 level my lines becomes all jittery :P i.e suppose a line starts at the origin it should be centered but it 'moves' away from the center.

Then I realize the value I'm adding is 9.11777e-15... DUde, I'm adding a really small number to a really small number... loss of precision.

Well I'm think maybe once the distance from origin gets below 1.0 then I scale everything?

Quote:
 u will have precision troubles with very small/big numbersjust keep a variable with each mesh saying at what scale it is eg scale = 0.001keep all the verts in the range 0.001->1000 say (reality = 0.0000001->1.0)and just draw the 0.001->1000 values to the screen. anytime u wanna output the data to the person just multiple the values by the scale

I don't think I can do this. My job is to implement the transformation and camera code. I can't really tell the people to change their mesh generation specification.

BTW I'm doing this for a C.F.D grid generation/CAD program. Originally our GUI used FLTK but we are moving it to python, SWIGGING all the C++ code.

They want to see really small numbers because with the previous GUI they were able to detect mesh problems by zooming down to small levels.

The guys claim that they can create a line from (0,0,0) to (1e-32 i.e 31 zeros) and still see it.

I need to give more thought to the problem.

Share on other sites
Nice engine BTW...

Share on other sites
Ahhh...

Yes, I guess it the significant digits matter.

If I add 0.0000000000001 with 0.0000000000000001 there should be no problem.

But If I add 0.000000000001 with 9.234293e-15 there would be a precision problem.

I'm going to try something...

1. 1
2. 2
3. 3
Rutin
15
4. 4
5. 5

• 13
• 26
• 10
• 11
• 9
• Forum Statistics

• Total Topics
633724
• Total Posts
3013556
×