Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

CGameProgrammer

Large clipping plane corrupts Direct3D? (w/ screenshot)

This topic is 5307 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

[The screenshot, and a better explanation, are about 6 comments down.] I need to render a very large scene. I don't mean a lot of geometry, just a very large space. Here's my problem: I first set the depth buffer range to [8192..131072] (in other words, 8192 * [1..16]) and rendered a lot of far-away stars. Then I cleared the depth buffer, changed its range to [0.01..8192], and rendered close-up planets. However this is obviously bad as I'm stretching floating-point accuracy past its breaking point, and what's really bizarre is I appeared to have corrupted the FPU... the longer my engine ran, the more and more inaccurate various calculations would be, which is really strange. It may be a Direct3D thing. Anyway that stopped when I mashed everything 32x closer in, so the maximum depth was 4096. It's obvious I need to use a fixed depth and just manipulate the view matrices to make everything appear to be to scale. How do I do this? Do I just use the world matrix and have it set to scale everything down, or would that still cause floating-point errors? Probably I should elaborate. You can fly 128 light-years across space, approach a solar system, and go right up to a planet (eventually landing on it). So it's not just a depth-buffer issue, it's a size issue. If the maximum view range was 131072 units, being 100km above a planet would be maybe 0.01 units above it in the engine. Clearly I can't render the landscape and objects on it with such small inaccurate values so that's another reason to alter the view matrices. ~CGameProgrammer( ); Screenshots of your games or desktop captures -- Upload up to four 1600x1200 screenshots of your projects, registration optional. View all existing ones in the archives.. [edited by - CGameProgrammer on March 1, 2004 6:26:13 AM]

Share this post


Link to post
Share on other sites
Advertisement
The problem is in the closer near plane. Just change the [0.01, 4096] to something like [2, 4096] and you''ll be golden.

karg

Share this post


Link to post
Share on other sites
No, that doesn''t help. The FPU still gets corrupted (or whatever is going on). Plus 2 units is like 200km above a planet''s surface, which makes no sense since the engine should be able to render a person standing on the planet.

~CGameProgrammer( );

Screenshots of your games or desktop captures -- Upload up to four 1600x1200 screenshots of your projects, registration optional. View all existing ones in the archives..

Share this post


Link to post
Share on other sites
Space is very big but pretty empty so why waste z-buffer precision on all that empty space? Partition things up into groups of objects which actually need the z-buffer and draw each group separately back to front, clearing the z-buffer after you''ve done each group. You know that the distant stars and planets are always going to be behind the stuff that''s in your immediate vicinity so draw them in a separate pass. You don''t need the z-buffer to help you sort out what''s closest.

In fact, for distant stars and planets you don''t even need to enable the z-buffer, just draw them in back to front order. They''re all non-intersecting points or spheres so you don''t need z-buffering to draw them correctly.

Share this post


Link to post
Share on other sites
I already do that. Distant stars are rendered first, followed by the planets. When the distant stars are rendered, the near plane is 8192 and the far plane is 131072. If I make the far planer closer, that will limit the draw distance which I can't have. And while I can disable the z-buffer, that will cause some stars to overlap others. They're only one pixel each, but it still can be noticeable, and I may render larger objects like gases that should not obscure stars in front of them.

Here's a screenshot of a perfect sphere:


That's what happens after running the engine for about 30 seconds. Not only that, but the shape actually changes if you tilt the camera just a bit, though it doesn't change if it's still. It's really weird. You have to see it to understand what I mean... so here's a demo. I disabled planet rendering for this, but stars are rendered -- both distant ones and nearby ones. The screenshot above is of a nearby star (they're rendered in wireframe so you can see what's going on).

The controls are WASD for moving around and the mouse for turning/looking. The number keys change your speed. 7 is the default speed, but when you load the engine, please press 9 for super-fast speed and fly randomly around the galaxy for around 20 seconds or so. Now press 5 or 6 and fly up to a star (press 3 as you get closer so you can approach it more accurately). It will be a misshapen blob... at least it is on my Radeon 9600. I'd be interested to see if the problem happens on other cards... but in any case, it's unacceptable.

By the way, there are no memory leaks and if any Direct3D functions returned an error it would be printed to PanGalactic.log. After flying around for a bit, mouse movement will appear very jerky like the framerate is low, except the framerate counter indicates it is not. (I guess I was wrong about the FPU being "corrupted", actually.) Also the path of the camera will be totally screwed up, and at slow speeds like 1, it'll refuse to move at all. Camera movement uses the D3DX matrix rotation functions, which I think take advantage of SSE, so maybe this is someone getting messed up? I have no idea. Maybe the error is competely internal to D3D... I'd really appreciate some help here. If I can get away with using a far clipping plane, that'll be fine... I just need this fixed!

~CGameProgrammer( );

Screenshots of your games or desktop captures -- Upload up to four 1600x1200 screenshots of your projects, registration optional. View all existing ones in the archives..

[edited by - CGameProgrammer on March 1, 2004 6:24:59 AM]

[edited by - CGameProgrammer on March 1, 2004 6:27:27 AM]

Share this post


Link to post
Share on other sites
This might be too slow for realtime but:

Why not have a huge sky (should that be universe) sphere that surrounds space at the center of the object relative to the player.

When in Interstellar space the sphere is centered on a player.
When in a solar system (say 1.5 light years from a sun), the sphere is centered on the sun (or in a binary or tenary system the central point of orbit).
And near a planet (or other celestial object) the sphere is centered around the planet.

Obvously your universe is stored in a data structure, which contains all the star data and locations. You can work out where the player will see the stars according to their positions. On the texture for the sphere using polar corrdinates plot all the stars, testing for depth using the players distance from each star location. You might have to have a slight pause when entering each solar system or planet to calculate the new star positions, but it might eradicate depth buffer woes.

If your game however takes place over thousands of year and you are simulating stellar drift, this won't work! This is only a sugesstion.

[edited by - pkelly83 on March 1, 2004 6:43:41 AM]

[edited by - pkelly83 on March 1, 2004 6:44:50 AM]

Share this post


Link to post
Share on other sites
That won''t work because it assumes the player teleports from star to star. He flies. If you download the demo, you''ll see what I mean.

And if you''re thinking that stars can pop out of the sphere when you get close enough, it will still look strange and not perspective-correct, plus that doesn''t handle the problem of fog -- farther stars are darker than closer ones, so as you move, their colors have to change as they become closer to you. It just wouldn''t look good and it would be slower than the normal way I''m doing it.

~CGameProgrammer( );

Screenshots of your games or desktop captures -- Upload up to four 1600x1200 screenshots of your projects, registration optional. View all existing ones in the archives..

Share this post


Link to post
Share on other sites
I execed your demo and it renders nothing visible. Maybe the hw does not support your depth settings. The log shows no error or warning.

Have you tried it disabling the zbuffer (since it's not necessaryu seeing you screen-shot), just order the centers of your spheres (planets/stars).

You seem to confuse the z-buffer settings, the clipping planes and the projection matrix. Of course usually they are equivalent. So you should try to separate the tests.

1) Test the view matrix stuff alone.
- remove zbuffer, set clipping planes very far and very near.
2) Test the view + clipping
3) Test the view + clipping + zbuffer


I your coordinates become 'jerky' it's probably a fpu precision issue, thus 1). In the transfo, most probably big numbers are substracted resulting in very high precision losses.

ex :
model : x ( 32 bits, x<2^10 )
+ translation : 2^24 + x', x' (10 bits now) looses 22 bits of precision(rotation)
- translation : 2^24 + x' - 2^20 = x'

x' only has 10 bits of precision now !!!! In fact the matrix computations have transformed your floating point coordinates into fixed point values. I don't know if you have ever heard of the quick float to int or float to fixed trick that uses big numbers. If you don't google, it will be clearer. It's probable that SSE optimisations makes such issues appear more often. Cf the other thread in this forum where I respond to SSE precision tests.

Solution :
- control the matrix stack yourself.
Send only the concatenated projection matrix. It's the only way to avoid the errors in the arcanes of D3D or GL unaccurate 'optimizations'.
- use centered model coordinates, not absolute.



[edited by - Charles B on March 1, 2004 7:00:51 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by Charles B
I execed your demo and it renders nothing visible. Maybe the hw does not support your depth settings. The log shows no error or warning.

Damn. Yes, if no errors are returned, I assume it set the far plane closer than it's supposed to be. Technically you can try moving anyway, you'll probably see a star once it gets close (and becomes a polygonal sphere) but there's not much point.

quote:
Have you tried it disabling the zbuffer (since it's not necessaryu seeing you screen-shot), just order the centers of your spheres (planets/stars).

You seem to confuse the z-buffer settings, the clipping planes and the projection matrix. Of course usually they are equivalent. So you should try to separate the tests.

Yes, that occured to me but I didn't try it yet. The clipping planes are the main problem, because in order for everything to be to scale, I'd need a distant clipping plane. Or, I can somehow manipulate the view matrices (world matrix, specifically?) to obtain this effect, but I'm not sure how.

I tested it with the z-buffer disabled. The problems haven't changed however, so the error is with the clipping plane...? Interesting. I uploaded the disabled-zbuffer version, I'd appreciate it if you'd download it and report whether or not you see anything. But I expect you won't, since clearly this clipping plane is not good.

Oh, and there are no problems initially, so it's not a question of floats being inaccurate.

EDIT: Every time I said "clipping plane", I meant the near and far values for the projection matrix. Sorry, should have clarified. That is equivalent to a clipping plane since it only draws what lies inbetween those two z-values.

~CGameProgrammer( );

Screenshots of your games or desktop captures -- Upload up to four 1600x1200 screenshots of your projects, registration optional. View all existing ones in the archives..

[edited by - CGameProgrammer on March 1, 2004 7:02:31 AM]

Share this post


Link to post
Share on other sites
Did download the demo, but won''t work on shitty college PC''s. Just out of interest are there any space games that actually do waht you are trying to do? Your idea sounds really interesting.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!