Direct3D : Flickering Primitives
Author
Hello,
I am hoping someone can recognise a problem I am having in D3D8, or suggest possible causes/solutions because I''ve tried everything I can think of and its finally driving me nuts.
Basically, I have a class. This class builds and manipulates primitives, in this case a triangle-fan. This also stores a texture for the primitive.
Pretty simple stuff.
My scene consists of numerous instances of this class, say 20 odd in a row and are about 1000000.0f along the X/Z axis each. You can fly around freely with the camera and that leads onto the problem I am having:
At certain angles, some primitives flicker really badly. It seems to be worse from low angles and also gets worse the further away from the origin you get. The viewable projection range is well above the scene size so the problem does not originate from the primitive leaking into the void. I have noticed that the flickering/tearing does not seem to occur (or occurs far less) when the object is really small, but due to the nature of it, the size is important.
So what now? I''ve suspected possible Z-issues, but my dabbling hasn''t helped. I''m out of options.
What could be causing this flickering? I have a really nagging feeling that the solution is simple (and possibly related to the z-buffer/bias), but I can''t put my finger on it.
Based on this information, I would be grateful for any comments, suggestions and would be happy to elaborate further if anyone has any questions that could lead to a possible solution.
Thanks.
Have you played with the near-clipping distance as well? I think the ration of near/far clip has something to do with it.
But when you are talking about distances that great you will probably need to do some fancy stuff for everything to look right.
There was a thread on one of these boards about adaptive buckets which would be great for what you are doing I think.
If you have a single polygon that is that large you will need to break it up into pieces though.
The basic idea behind using buckets is you take all of your polygons and sort them by their distance in view space. You would create a bucket for each segment.
Say 0-100,000 for your first bucket
100,000-200,000 for your second
etc
Then you draw the furthest bucket then clear your ZBuffer and draw the next bucket and so on.
I might be missing a point or 2 here. lol. I am saying this from memory and I haven''t tried implementing it yet because I don''t need it for my current project, but I found it very interesting reading for future reference.
Seeya
Krippy
But when you are talking about distances that great you will probably need to do some fancy stuff for everything to look right.
There was a thread on one of these boards about adaptive buckets which would be great for what you are doing I think.
If you have a single polygon that is that large you will need to break it up into pieces though.
The basic idea behind using buckets is you take all of your polygons and sort them by their distance in view space. You would create a bucket for each segment.
Say 0-100,000 for your first bucket
100,000-200,000 for your second
etc
Then you draw the furthest bucket then clear your ZBuffer and draw the next bucket and so on.
I might be missing a point or 2 here. lol. I am saying this from memory and I haven''t tried implementing it yet because I don''t need it for my current project, but I found it very interesting reading for future reference.
Seeya
Krippy
I encountered the same problem last night but yet I have not found a solution. My objects tend to flicker if I rotate them AND the camera.
Yup, 1000000 is waaay to high (assuming the near plane value is low) to get decent precision from a Z-buffer, particularly a 16bit Z buffer. A z buffer isn''t linear either, most of the precision is stacked up near the camera, the further you get from it, the less precision you get.
16 bits is only going to hold 65536 possible different values (floating point will give you more range, but can still only hold that many different values), ignoring range for a moment: 1000000/65536=15.25 - so a pixel with Z=2 is going to have the same Z buffer value as one with Z=6 and the same as one with Z=8 and the same as one with Z=12 etc... - for that reason what you see is the draw order with no correct Z sorting.
Solutions:
1. Move the near clipping plane further towards the far clipping plane (you want to reduce the distance between them).
2. If most of the artefacts are further away from the camera, try using W-buffering instead of Z buffering (this divides the space up in a linear fashion). [beware though, on some hardware this loses you a few other features]
3. Move your far clipping plane nearer - you should never need one that far away unless you were doing say a space game where you can see miles and miles away, and in that case you''d do the Z bucketing.
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
16 bits is only going to hold 65536 possible different values (floating point will give you more range, but can still only hold that many different values), ignoring range for a moment: 1000000/65536=15.25 - so a pixel with Z=2 is going to have the same Z buffer value as one with Z=6 and the same as one with Z=8 and the same as one with Z=12 etc... - for that reason what you see is the draw order with no correct Z sorting.
Solutions:
1. Move the near clipping plane further towards the far clipping plane (you want to reduce the distance between them).
2. If most of the artefacts are further away from the camera, try using W-buffering instead of Z buffering (this divides the space up in a linear fashion). [beware though, on some hardware this loses you a few other features]
3. Move your far clipping plane nearer - you should never need one that far away unless you were doing say a space game where you can see miles and miles away, and in that case you''d do the Z bucketing.
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
