Jagged edges going from DX 8.0 to 8.1?? (picture)
Author
I just updated to the 8.1 SDK, and for some reason my .x meshes that i''ve loaded now have a very jaggedy edge to them, almost as if the zbuffer isn''t working very well or something. I''ve made no changes other than going to the new DX SDK 8.1 from 8.0. Any ideas why this is happening? (I did check and make sure that m_pd3dDevice->SetRenderState( D3DRS_ZENABLE, TRUE ); is working successfully still).
Notice things like the rooftops, which used to completely cover the castle towers, now for some reason only cover it in strange areas jaggedy areas.
I noticed you are running in windowed mode. Have you changed your color depth on your desktop since the move? It looks almost like its missing some of the polygons. The only thing that I can suggest is make sure your back-face culling is set to what its supposed to be (counter clockwise by default, I think), and check that you are using a 32 bit z buffer if its available on the machine that your program runs on.
One more thing - check to make sure you have the latest drivers.
Moe's site
Edited by - Moe on December 12, 2001 6:17:30 PM
One more thing - check to make sure you have the latest drivers.
Moe's site
Edited by - Moe on December 12, 2001 6:17:30 PM
Author
Interesting, after experimenting a bit it does appear to have something to do with 32 bit or 16 bit mode. I''m running my windows desktop in 16-bit color mode, and run the app in the same format. When i switched to a 32 bit desktop the jagged edges went away and everything drew perfectly again. Why would this make that kind of a difference?
I''m using this bit of code currently for setting up the zbuffer:
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = !bFullScreen;
d3dpp.BackBufferCount = 1;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.EnableAutoDepthStencil = TRUE;
d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
(btw i am using the latest nvidia driver for this GeForce 3 Ti200, and even reverted to an old driver to see if that helped, but it didn''t, it seems to have something to do with going to the 8.1 sdk over the 8.0 sdk).
I''m using this bit of code currently for setting up the zbuffer:
ZeroMemory( &d3dpp, sizeof(d3dpp) );
d3dpp.Windowed = !bFullScreen;
d3dpp.BackBufferCount = 1;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.EnableAutoDepthStencil = TRUE;
d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
(btw i am using the latest nvidia driver for this GeForce 3 Ti200, and even reverted to an old driver to see if that helped, but it didn''t, it seems to have something to do with going to the 8.1 sdk over the 8.0 sdk).
Ok, so it looks like its your color depth. Here''s whats causing the problem:
When you run your desktop at 16 bit color, it uses a 16 bit z buffer as well. In your program, the z-buffer is losing precision because its not big enough to hold all your data. When you use a 32 bit z buffer, it has more precision and can more acurately sort the pixels. When you see that flickering like you are missing some triangles, it is really the z buffer that can''t figure out what to draw because of its lack of precision. This is known as z-fighting. There are a few ways it can be fixed.
You can use something called a w-buffer. I don''t know a whole lot about it, or how it works, so you might have to do a bit of research into that. The easier way is to make your program use a 32 bit z-buffer. Since you are running a Geforce 3, you should be able to run in 32 bit color with no problem (depending on your monitor). If all else fails and the computer that you are trying to run your program on can''t do a 32 bit z-buffer, then drop down to a 16 bit z buffer and use a w-buffer.
Also, make sure that you check to see if the computer you are running on can do a 32 bit z-buffer. If you don''t its quite possible that your program will either crash or quit.
Its (almost) always best to use the latest video drivers.
When you run your desktop at 16 bit color, it uses a 16 bit z buffer as well. In your program, the z-buffer is losing precision because its not big enough to hold all your data. When you use a 32 bit z buffer, it has more precision and can more acurately sort the pixels. When you see that flickering like you are missing some triangles, it is really the z buffer that can''t figure out what to draw because of its lack of precision. This is known as z-fighting. There are a few ways it can be fixed.
You can use something called a w-buffer. I don''t know a whole lot about it, or how it works, so you might have to do a bit of research into that. The easier way is to make your program use a 32 bit z-buffer. Since you are running a Geforce 3, you should be able to run in 32 bit color with no problem (depending on your monitor). If all else fails and the computer that you are trying to run your program on can''t do a 32 bit z-buffer, then drop down to a 16 bit z buffer and use a w-buffer.
Also, make sure that you check to see if the computer you are running on can do a 32 bit z-buffer. If you don''t its quite possible that your program will either crash or quit.
Its (almost) always best to use the latest video drivers.
color depth has no effect on the moniter. it all has to do the the video card. (since rgb moniters accept rgb signals which suffice to say accept true color deoths). refresh rate limitations at color depths are soly form the video card being to slow not the moniter which is only affected by resolutions you choose. also you may try bring yoru far clipping plane and near clipping plane closer.
I beg to differ. My monitor has a max. resolution of 1280x1024x32 and it can only handle it at something like 70Hz. The monitor can limit the maximum resolution and refresh rate. My video card can handle 1920x1600 (or whatever it is) at something like 130Hz.
A person is right that moving the far clipping plane might help somewhat, but it won''t fix the problem. The z-buffer loses precision as an object gets further away, and more precision up close. If anything, move the far clipping plane further away.
A person is right that moving the far clipping plane might help somewhat, but it won''t fix the problem. The z-buffer loses precision as an object gets further away, and more precision up close. If anything, move the far clipping plane further away.
About far& near clipping plane. you loose a lot of precision when you have a close near clipping (read the doc I don't recall the detail)
near plane is very important for Z-Fighting and changing close from 0.1 to 3.0 have more effect than 4000.0f to 9000.0f
for the far clipping. The closest the near clipping strongest is the z-fighting trouble.
Also you may take care not designing object that are to "flat"
(don't know the word) while Z buffer cannot resolve value that are too close.
Immo you cannot assure that you will get every time a 32 bit buffer or you will limit your game to the latest hardware only so you likely must deal with range and object design.
What are your current value for near and far ? if you get a near
less than 3.0 you have your problem.
Below what doc say about z-buffer... interesting.
Dan
Edited by - dansteph on December 14, 2001 8:39:32 AM
near plane is very important for Z-Fighting and changing close from 0.1 to 3.0 have more effect than 4000.0f to 9000.0f
for the far clipping. The closest the near clipping strongest is the z-fighting trouble.
Also you may take care not designing object that are to "flat"
(don't know the word) while Z buffer cannot resolve value that are too close.
Immo you cannot assure that you will get every time a 32 bit buffer or you will limit your game to the latest hardware only so you likely must deal with range and object design.
What are your current value for near and far ? if you get a near
less than 3.0 you have your problem.
Below what doc say about z-buffer... interesting.
Dan
quote:
Nearly all 3-D accelerators on the market support z-buffering, making z-buffers the most common type of depth buffer today. However ubiquitous, z-buffers have their drawbacks. Due to the mathematics involved, the generated z values in a z-buffer tend not to be distributed evenly across the z-buffer range (typically 0.0 to 1.0, inclusive). Specifically, the ratio between the far and near clipping planes strongly affects how unevenly z values are distributed. Using a far-plane distance to near-plane distance ratio of 100, 90% of the depth buffer range is spent on the first 10% of the scene depth range. Typical applications for entertainment or visual simulations with exterior scenes often require far-plane/near-plane ratios of anywhere between 1000 to 10000. At a ratio of 1000, 98% of the range is spent on the 1st 2% of the depth range, and the distribution becomes worse with higher ratios. This can cause hidden surface artifacts in distant objects, especially when using 16-bit depth buffers, the most commonly supported bit-depth.
A w-based depth buffer, on the other hand, is often more evenly distributed between the near and far clip planes than a z-buffer. The key benefit is that the ratio of distances for the far and near clipping planes is no longer an issue. This allows applications to support large maximum ranges, while still getting relatively accurate depth buffering close to the eye point. A w-based depth buffer isn't perfect, and can sometimes exhibit hidden surface artifacts for near objects. Another drawback to the w-buffered approach is related to hardware support: w-buffering isn't supported as widely in hardware as z-buffering.
Edited by - dansteph on December 14, 2001 8:39:32 AM
I found some similar problems.
For this: 16bits = low precision in many calcules. 32bits = high precision. Even when it indicate colors-depth.
For this: 16bits = low precision in many calcules. 32bits = high precision. Even when it indicate colors-depth.
Author
You are describing exactly what''s happening, the closer i get the jaggediness goes away, but if it gets off in the distance a little bit it gets really jagged looking. I''m adjusting my clipping plane this way (I assume this is what you mean anyways?)
FLOAT fAspect = (float)screenwidth/(float)screenheight;
D3DXMatrixPerspectiveFovLH( &matProj, D3DX_PI/4, fAspect, 1.0f, 65000.0f );
m_pd3dDevice->SetTransform( D3DTS_PROJECTION, &matProj );
I tried values from 1000 on up to 100000 in the far (last parameter of the D3DXMatrixPerspectiveFovLH function) to see if that helped but it made no difference either way no matter what the value. When I change the near value, from 1.0f to like 5 or 10, it did seem to help, but not quite enough. Is it ok to set this value higher, to like 50 or even 100, or will that have adverse effects?
Also, setting the zbuffer depth to this:
d3dpp.AutoDepthStencilFormat = D3DFMT_D24X8;
instead of
d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
does make the problem go away, however like someone said up above, i''m worried about graphic cards that have only 16 bit zbuffers. BTW thanks for all the help, it''s been a good learning experience.
FLOAT fAspect = (float)screenwidth/(float)screenheight;
D3DXMatrixPerspectiveFovLH( &matProj, D3DX_PI/4, fAspect, 1.0f, 65000.0f );
m_pd3dDevice->SetTransform( D3DTS_PROJECTION, &matProj );
I tried values from 1000 on up to 100000 in the far (last parameter of the D3DXMatrixPerspectiveFovLH function) to see if that helped but it made no difference either way no matter what the value. When I change the near value, from 1.0f to like 5 or 10, it did seem to help, but not quite enough. Is it ok to set this value higher, to like 50 or even 100, or will that have adverse effects?
Also, setting the zbuffer depth to this:
d3dpp.AutoDepthStencilFormat = D3DFMT_D24X8;
instead of
d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
does make the problem go away, however like someone said up above, i''m worried about graphic cards that have only 16 bit zbuffers. BTW thanks for all the help, it''s been a good learning experience.
For my part I also need a great range for exterior (age of sail simulator) but it seem i''m clamped more or less to 3.0->9000.0
Greater(&closest) value let artifact happen for 16 bit buffer.
The counter part of a great number for close range (100) is that if you approach close from an object it will disappear when it will be closer than the near plane value (seem to be "eating")
so it''s not suitable for interior. (but in interior you will also have less far value)
result depend also of the scale of your objects if your castle
make 10''000 wide it will be "cut" even at close distance
Only test can resolve and give good result.
Immo it''s bader to let some artifact happen than reducing automaticly the range for the far plane if player''s card isn''t capable of 32(24) bit buffer. Just let him know gently that his card suck.
Almost all "pro" game do that Bad card= Bad visual.
Funny, the player would never imagine what we are facing for doing game and Z-fighting is only a small issue in regard of other trouble. They only rant about the 25 buck we ask them and rant about a patch or something or that (why isn''t the grass animated ??? :-)
Do we still love doing game ? Yessss sir !
Dan
Greater(&closest) value let artifact happen for 16 bit buffer.
The counter part of a great number for close range (100) is that if you approach close from an object it will disappear when it will be closer than the near plane value (seem to be "eating")
so it''s not suitable for interior. (but in interior you will also have less far value)
result depend also of the scale of your objects if your castle
make 10''000 wide it will be "cut" even at close distance
Only test can resolve and give good result.
Immo it''s bader to let some artifact happen than reducing automaticly the range for the far plane if player''s card isn''t capable of 32(24) bit buffer. Just let him know gently that his card suck.
Almost all "pro" game do that Bad card= Bad visual.
Funny, the player would never imagine what we are facing for doing game and Z-fighting is only a small issue in regard of other trouble. They only rant about the 25 buck we ask them and rant about a patch or something or that (why isn''t the grass animated ??? :-)
Do we still love doing game ? Yessss sir !
Dan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement