This thread is for 3D space-based game making theory.......
If you are making a dungeon crawl or a FPS, your scale is probably not more than 1 or 2 km in any direction (most likely not even 1km). But when making a space-based game, things are a bit different. Games like the X series use sectors to break up the vastness of space, but even when you break it up like they do, you still run into the same kinds of problems-- THE MASSIVE SCALE!
At first look, you would see a glaring problem right away: the far clipping plane. Easy enough, you think "I'll just push it out to about 10,000,000 and be done with it." Though this sounds like a good idea, it creates problems as well. You run into things like z-fighting that you can't get away from! So you have to come up with another solution......
The next problem you will discover is that the coordinate system starts to go all wierd as you get farther from the origin. This is due to the limitations of the floating point-- which is used by DirectX. Don't get me wrong, there's nothing wrong about using floating points, it's just that using them for the purposes of a coordinate system in a game like this is not going to work. So you have to come up with another solution......
....The other solution(s):
This solution won't work correctly if you don't have full control of the render order....
First, don't make the far clipping plane larger than 10,000 and you won't get much z-fighting, but you still have to see the objects at ranges sometimes 100,000,000km or more. I know I\'m not supposed to use code, but this is an equation for distance vs view size of an object:
S=float(atan(size/(dist-size)));
where S is the apparent scale of the object
size is the size of the object
and dist is the distance from the camera
This gets you part-way. Now that you have a scale factor, shoot a vector from the camera to the object, normalize that vector, and multiply it by the max distance of say 5,000. That's half the view distance and gives you enough space for even the largest objects to render fully without running into the far clip plane. Now that you have all your objects rendering at seemingly great distances, you will notice objects that are supposed to be in the foreground being clipped by objects that are supposed to be in the background and z-fighting occurs. This is because you are rendering them at the same distance and the GPU doesn't know that they are at different depths. You can correct this by turning off the z-buffer. But at some point, you will want to turn it back on because some complex objects like space stations have arms sticking out that would cover part or all of a ship that is actually nearer the camera than the space station. So I turned mine on at distances less than 4,000.
I've been talking about render order, but didn't discuss how to do it. When you would normally go through and update the objects, put them into a pool of all the objects you want to render, sorting them by distance from the camera. The first in the pool is the farthest away and the last is the closest. Now before rendering this pool of objects, turn off the z-buffer and draw each of the objects one at a time. When you reach your near threshold (4,000), turn the z-buffer back on and continue. If you did it right, this will properly render all your objects with good looking results.
Now we need to talk about the coordinate system. I'm not going into great detail here, but if you want to know specifically what I am using, here is a link to my discussion on it:
http://forum.thegamecreators.com/?m=forum_view&t=199677&b=22
Here it is in a big nutshell. I broke the massive scale of the solar system so that each unit is 1meter. That means the unit value from the sun to Pluto is 5,913,000,000,000 meters! There's not much in C++ that can handle this number except __int64. But I still needed some kind of floating point so that everything moved smoothly. So I used a double for the last 3 digits and included decimal places. This put my numbers at 5,913,000,000__int64 and up to 999.99999F with a double. This makes it very accurate at very lare scales.
Putting it all together:
Don't change the camera's position! Keep it at the origin. Remember the floating point accuracy issue? If you move the universe around the camera with our new coordinate system, then the only issues are with objects very far away (which we\'ve corrected already). Render the objects in order of distance at a or closer than the maximum depth.
Here is a pic of what I've been working on:
In the backgound, you see what looks like Earth. It's actually at the distance that Pluto is. You may be able to see a moon or two (they have the same texture as Earth). And in the foreground, you see a space station and some asteroids. All of them rendered using the method I described. I hope this helps someone and perhapse inspires others.
The fastest code is the code never written.
