Optimate scale for view in dx8/unit in world
Author
1. I have set the near and far view from 3 to 8000 I have read much on the subject but still cannot decide if its good or bad ?
It seem to work perfect for now but I wonder If I got some perfomance hit.
2. In an outside world very hugh is it better to move the object relative to the camera keeping coordinate in a virtual manner or
I can go with absolute coordinate.
Ie:
Can I move my camera in a world which extend from XZ=0 to
XZ = 1 million without trouble (the camera could be at X=500''000
z=500''000 with a range view 3-8000)
Or should I convert all the near object from a "virtual world coordinate" to local view and keep the camera at say 10''000X 10''000Z (that would be a lot much trouble to work with)
In summary does dx8 car of great number ?
Thanks
Dan
it doesn''t matter is the world is huge, the z values correspond to how far you can see. For instance, if you wanted to be able to see the whole huge world, the zextent would need to be very large. If you only care about seeing 8000 in front of you, that''s fine.
The bigger your z range, the more the card has to process because it can''t just clip things away. Also, you may run into issues with precision in the z buffer.
The bigger your z range, the more the card has to process because it can''t just clip things away. Also, you may run into issues with precision in the z buffer.
Actually you can clip things away in the Application stage, except you don''t literraly "clip" them you use an algorithm and not send them in for processing at all. Depending on DirectX for your clippeng needs is a slow, completely irrational solution.
I don''t have it in front of me here at home, but there was a GDC 2000 paper about this sort of thing. One of the points made was that in some cases, it''s actually cheaper to let D3D do the clipping when you are talking about rendering terrain. (This was in the context of Sony''s upcoming PlanetSide)
The rationale was that it was more expensive to lock the vertex buffer, process the vertices, unlock the buffer, and re-upload the vertices than it was to just let the pipeline handle it.
Like I said, I don''t have the paper in front of me, but it makes sense, at least on newer hardware. The slowest part of the pipeline is the bus. Depending on the situation, you may be optimizing the internal pipeline, but at the cost of pushing more across the slower bus. It doesn''t make sense to optimize the fast part by slowing down the slow part.
In practical terms, both probably make sense - if something is easy to remove in the application stage, then by all means do it, otherwise let the hardware handle it.
The rationale was that it was more expensive to lock the vertex buffer, process the vertices, unlock the buffer, and re-upload the vertices than it was to just let the pipeline handle it.
Like I said, I don''t have the paper in front of me, but it makes sense, at least on newer hardware. The slowest part of the pipeline is the bus. Depending on the situation, you may be optimizing the internal pipeline, but at the cost of pushing more across the slower bus. It doesn''t make sense to optimize the fast part by slowing down the slow part.
In practical terms, both probably make sense - if something is easy to remove in the application stage, then by all means do it, otherwise let the hardware handle it.
Author
Thanks all for reply,
>The bigger your z range, the more the card has to process
The point is to find the limit beetween zbuffer inacuracy and
performance.
As far as I understand cliping and from previous test I think
wreakon mean using bounding box or other test to reject whole part ot the scene that aren''t in the frustrum.
The counterpart of this and perhaps a less know issue is
that the animation can become jumpy depend on the application.
Enabling or disabling suddenly part of the scene will make great change beetween one frame time and the next one, the bad thing is that we only know the delta time frame for the last frame not the incoming one.
Say that a frame take 10ms. Next frame an object come into the frustrum and drop the frame time to 20ms too bad we have a delta time of *10 instead of *20... Jumpy.
Of course we can make some predictive correction while we know that an object will be drawed or not but how good will it be if I have tuned the correction for say a p400 adding 10ms and it run on a p800 where the correction will only be 5ms ? Jumpy again.
Here I''m lost I was never able to fully correct this and the game on the market often are jumpy too.
Anyone on this ?
>The bigger your z range, the more the card has to process
The point is to find the limit beetween zbuffer inacuracy and
performance.
As far as I understand cliping and from previous test I think
wreakon mean using bounding box or other test to reject whole part ot the scene that aren''t in the frustrum.
The counterpart of this and perhaps a less know issue is
that the animation can become jumpy depend on the application.
Enabling or disabling suddenly part of the scene will make great change beetween one frame time and the next one, the bad thing is that we only know the delta time frame for the last frame not the incoming one.
Say that a frame take 10ms. Next frame an object come into the frustrum and drop the frame time to 20ms too bad we have a delta time of *10 instead of *20... Jumpy.
Of course we can make some predictive correction while we know that an object will be drawed or not but how good will it be if I have tuned the correction for say a p400 adding 10ms and it run on a p800 where the correction will only be 5ms ? Jumpy again.
Here I''m lost I was never able to fully correct this and the game on the market often are jumpy too.
Anyone on this ?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
