Forums » Suggestions
Zoom rendering
Is it just me, or does it seem like the zoom function is merely an after-render process? I turbo'd out really far from a station, and zoomed back in on it. What I saw was very strange. In moving the mouse, the asteroids jumped around (with a pixel position orientation). The station did not jump around, it was really smooth. Although the "drawing" on the station was flickering.
Granted this is not absolutely crucial, I think it would be better if the zoom provided a realistic "smooth" view.
Also, when you zoom into space... you'll notice that it's blurry and pixelated, especially in the gas areas of the background image. Again, not important, it just could be better.
:-P
--
kihjin
Granted this is not absolutely crucial, I think it would be better if the zoom provided a realistic "smooth" view.
Also, when you zoom into space... you'll notice that it's blurry and pixelated, especially in the gas areas of the background image. Again, not important, it just could be better.
:-P
--
kihjin
Well...
All the zoom function does is adjust your field of view... the "flickering" you speak of is depth buffer imprecision, and nothing can be done about it until 64-bit depth buffers are the norm.
As for zooming into space, the reason that bluriness happens is that the background texture is only rendered with so much precision... there's AFAIK no way for WGAF—or any other engine for that matter—to efficiently render select portions of the background.
-:sigma.SB
All the zoom function does is adjust your field of view... the "flickering" you speak of is depth buffer imprecision, and nothing can be done about it until 64-bit depth buffers are the norm.
As for zooming into space, the reason that bluriness happens is that the background texture is only rendered with so much precision... there's AFAIK no way for WGAF—or any other engine for that matter—to efficiently render select portions of the background.
-:sigma.SB
Perhaps you're right, I've only done minor work with OpenGL, plus I don't know how VO works internally.
My guess is that if they could have done Zoom a different (better) way, they would have done that. But then again, it could have just been thrown in there for effect :-P
It just seems that if Zoom were to reposition your field of view and then render, it would work out better. Maybe there's some logic I don't understand though :)
--
kihjin
My guess is that if they could have done Zoom a different (better) way, they would have done that. But then again, it could have just been thrown in there for effect :-P
It just seems that if Zoom were to reposition your field of view and then render, it would work out better. Maybe there's some logic I don't understand though :)
--
kihjin
That would be rather slow... Plus, there's the fact that your orientation vector is truncated for network purposes. Therefore, if you're zoomed way in, rather than moving your orientation in smooth increments, it jumps around. This is the reason why railguns are somewhat more inaccurate than we'd like. Please read the following for a detailed explanation of vector quantization: http://www.vendetta-online.com/x/msgboard/2/4267#55501
Heck, if you wanna see vector quantization, just put a CentII with an FC on turbo away from a system center, come back 2 hours later, and warp.
-:sigma.SB
-:sigma.SB