I´m not the Z-Buffer expert, pretty sure about that, though:
Recently read an article linked here in some thread somewhere, and if I understood it correctly, it would double the accuracy 'range' (range with some specific acceptable error) of your depth buffer if you doubled the value for the near plane. So instead of 1.0f use 2.0f for doubled range, using 4.0f might probably not hurt, either.... just put the near plane as far away as you can bear. And perhaps decrease the far plane distance, if needed. I am currently using 5.0f for near and 8000.0f for far plane and got no visual glitches... but that obviously depends on the scene you´re rendering....
Rendering Question.
Calidev, the visual artifacts you pointed out in that screenshots are called "z-fighting". Google is your friend here, but like suggested above: adjusting near and far clipping planes (to increase z-buffer resolution at viewing distance) usually does the trick. Pay special attention to the near plane.
Also, from the screenshot it seems the geometry is faulty: t-junctions (an other good thing to google on!) cause seams in between adjacent polygons, allowing the geometry behind it to shine through.
Also, from the screenshot it seems the geometry is faulty: t-junctions (an other good thing to google on!) cause seams in between adjacent polygons, allowing the geometry behind it to shine through.
Author
Thank you; I was playing with the near plane (setting it to 5.0) and it helped out a great deal. It looks a lot better now; but I'm still not getting the lighting like it is in the MeshViewer(of the DirectX SDK); I guess I need to play around with that. But it looks really great in the MeshViewer (so crisp and clean).
Thank you,
Joshua
Thank you,
Joshua
Quote:Original post by calidev234
Thank you; I was playing with the near plane (setting it to 5.0) and it helped out a great deal. It looks a lot better now; but I'm still not getting the lighting like it is in the MeshViewer(of the DirectX SDK); I guess I need to play around with that. But it looks really great in the MeshViewer (so crisp and clean).
Thank you,
Joshua
See the light settings in "mview.cpp" from Mesh Viewer code. This file is in the ..\DXSDK\Extras\MView path.
umm of course you aren't going to get the same coloring with the lighting.. you are using 16-bit colors when you initialize whereas the mesh viewer defaults to 32-bit :) Other than that the mesh viewer is probably lighting slightly different.
Based on your last screenshot, it seems you are using a point or spot light, and the range of the light seems small to iluminate the whole model.
Try to increase it. For example:
light.Range = 10000.0f;
Also, try to use a directional light instead of a point light.
Note:
Remember that to get exactly the rendering shown by Mesh Viewer, you need to use the same lighting properties (including the position or direction of the light) and the same camera settings.
Try to increase it. For example:
light.Range = 10000.0f;
Also, try to use a directional light instead of a point light.
Note:
Remember that to get exactly the rendering shown by Mesh Viewer, you need to use the same lighting properties (including the position or direction of the light) and the same camera settings.
I'm sure someone answered already, but I think it has to do with your lighting. I think MView lights already on default. Hope this helps.
Author
Saruman, I understand the 16 vs. 32 bit argument and I tried to default my viewer to 32 but it WOULD NOT create the 3d Device; only the 16 worked. But the MeshViewer worked fine (on the same computer).
As for the other lighting issues, yes I agree with both of you that the type, possition, etc. must be the same.
Thank you,
Joshua
As for the other lighting issues, yes I agree with both of you that the type, possition, etc. must be the same.
Thank you,
Joshua
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
