Mystery of the disappearing planets

Blitz3D Forums/Blitz3D Programming/Mystery of the disappearing planets

Second Chance(Posted 2003) [#1]
Hello there.

Here's my situation; I've got a 1/100th scale star system (earth's) going in blitz. Each of the planets is made in a loop so they are all created exactly the same way. As each planet is made the planet "type" is assigned a blitz sphere as a mesh to represent the body, and textured appropriately. Then it's assigned its orbital distance from the star (0,0,0). Everything looks good until you get out to about the orbit of Uranus (29,000,000 game units) and beyond, at that point the planets start to wink in and out of existence. They'll render for a few seconds (at 86 fps) then disappear for a few seconds. Always the same amount, in a regular cycle. I've got the number of tris being shown and the handle numbers of the mesh spheres. And they say that although the mesh exists it's not being rendered. Now I've also got an untextured test sphere about the same size a little farther out, and it shows up perfectly every time. No winking. But this sphere's mesh handle variable doesn't belong to a type. I've also tried not texturing the planets, with no change in the problem. Can anyone tell me why this sphere stays put while the planets wink in and out of existence? When they do render they're nice and solid with no problems. And when they wink out it's very abrupt, no jittering or flashing. Just ON then OFF, then ON then OFF. Some insight would be much appreciated.

(*Edit*)
I have also tried this with and without wbuffer. And all the planets are set to render 9th. The skybox is set to 10. I turned EntityOrder off with no effect.


jhocking(Posted 2003) [#2]
A couple things to point out...

One is that rendering tends to be unstable far away from the world origin. Normally I try to keep the furthest points in my game within 40,000 units; you're talking about going past 29 million! Try shrinking everything to an even smaller scale.

Another thing to point out is regarding your CameraRange. If it isn't set correctly you can get some very odd visual artifacts.

**************

Slightly OT (but only slightly) note that both problems are pretty hardware dependent. For example literally every other Blitz3D demo I try on my computer has horrible z-buffer problems and I eventually concluded that it is because people aren't setting CameraRange correctly. On their system it looks fine but on my system, which has a coarser z-buffer, there are nightmarish rendering artifacts. Because of the incorrectly set CameraRange they are wasting most of the z-buffer on distances well outside the furthest point in the game.


Second Chance(Posted 2003) [#3]
Yes, those are both very good points. And they are both the bane of doing space based sims. Scale is already a huge problem due to the limits of the blitz "engine" (integer size, decimal precision, camera range, etc). Right now the camera range is set at 1,250000. Insane I know, but I'm just not satisfied with the looks at a lower setting. And if I scale it down any more I'll completely lose any decimal precision I have left. It's already at 1 game unit = 100 km. The only reason I can even do anything is because I've completely disregarded the scale for planets and their orbits and made 1 game unit = 1km for movement of craft and such. So just like every other game I've got completely mismatched scales with planets that are way to tiny to be credible. Obviously planets to scale are impossible with blitz, but I'm trying to get as close as possible. It may turn out that what I want just isn't possible. Of course I'm open to ideas on getting a great big universe into the tiny blitz "engine".

Oops, starting to move away from my topic. I'm really tired, haven't slept yet.


jhocking(Posted 2003) [#4]
It's not fair that you blame Blitz since these problems are mostly due to hardware. Realize a couple things, one being that 3D hardware is designed for the needs of most games and most games take place on a normal human scale (ie. a building or city or something, not an entire solar system.) Note that actual scientific simulations of the solar system only run on supercomputers and even then are nowhere near real-time speeds.

Meanwhile, to get around the limits of hardware, developers of large space sims (or whatever) cheat on scale a LOT. Planets are a lot closer together than they are in reality, ships move much faster than in reality, etc. Think "Master of Orion" where the entire galaxy can be traversed in just a few turns.

Note that these cheats on scale are a good idea anyway from a game design perspective. No player wants to sit around forever waiting for ships to get from planet to planet nor is it conducive to gameplay if the planets are so small on screen they don't even occupy a pixel (as would be the case if the solar system were at realistic scale and you displayed everything onscreen at once.) Even on a human scale things are normally compressed for the sake of gameplay. For example in most games players move much faster than normal humans can because it is boring if it takes too long to run from one end of the level to the other.

If your goal is to create a perfectly realistic simulation of the solar system then that's a pretty misguided goal. Realistic isn't fun but people often get the two concepts confused because they normally aren't contradictory either. In this case however they are; the reality of the vast emptiness of space isn't fun (except perhaps to a very small audience of astronomers) so realistic is not a good goal for your game. To put it in persepctive, note that a game about spaceships zipping between planets and managing a space empire is fundamentally unrealistic anyway; these things are not real but it more fun to pretend they are. Similarly, it is more fun to pretend planets are closer together than they actually are.


Second Chance(Posted 2003) [#5]
Yes, but I don't like the level to which the cheats on scale are taken in most games. I want something different from what you see in most games. Some things are boring to some people and not to others. I prefer realistic sims to pure action games which completely disregard the laws of reality. Many people don't, I understand that. I'm not passing a judgement on what people want. I'm just trying to do the best I can with what I have to create the content that will make me happy. I don't blame blitz for it's limitations, it wasn't designed to do what I'm asking it to. And if it turns out not to be possible I'll just do something else until either it is possible or I become proficient enough to do it using a more advanced language.

All I want to know is why one sphere renders perfectly and another doesn't. Still looking for thoughts on that :)


Second Chance(Posted 2003) [#6]
I have a suspicion on what's happening. It may be that the planets aren't disappearing, they're moving! Maybe at that distance from the origin the transformation matrix has lost so much precision that it can only remain stable for a few seconds before it jumps to a new location, close by but out of camera view. Recently I noticed that when I went beyond 16,777,216 units that I completely lost the ability to move in single unit increments and that when I kept going farther out I started to lose the ability to move even in triple digit increments! Maybe loss of precision in the transformation matrix is the little gremlin behind all these kinds of problems. What do you guys think?


Miracle(Posted 2003) [#7]
That's probably it, SC. Since every floating-point number in Blitz is single precision, numbers start to jump internally to exponents around 16 million.

Have you considered dropping your solar system to 1/1000 scale? (though if your scale gets too small you start having the opposite problem, that you can't move items in small enough increments because the numbers are smaller than the precision.) Alternately, you could create a mathematical model of the solar system, only render planets that are within view, and actually move the solar system around the camera instead of the other way around. I mean, who cares if Neptune is placed EXACTLY where it should be when you're flying around Mercury?


Red Ocktober(Posted 2003) [#8]
Whatever... this sounds interesting...

... any chance i'll be able to see any of this planet trekking?

--Mike


EricZann(Posted 2003) [#9]
Been there, done that, got the tee-shirt...

First things first, the camera scale is going to be a nasty limitation. Camera scale *must* have a maximum near/far ratio of 1:10000. Any more than this and all sorts of strange glitches start to happen. This problem is not specific to Blitz, nor even to DirectX, it is (as far as I know) a problem with any 3D system at present.

If you ignore or find a way round this, there is a limit on how far away from the point of origin you can get before floating-point errors creep in, and start doing weird things to the locations of your objects (I suspect this is what is happening to your planets).

This latter problem could potentially be solved by using a DLL, using a language which can handle floating-point numbers more precisely than Blitz. If you combine this with Miracle's suggestion of keeping the camera fixed and moving the solar system (which is trickier than it sounds, believe me!), you might be able to do something.

If you want a glimpse of my own attempts at solving some of these problems, take a look at the 'Galaxy' project on my website.


RexRhino(Posted 2003) [#10]
Realisticly, what you should probably do is keep your ship at 0,0, and keep track of planetary motion yourself, and then simply render stuff relative to your ship (culling out objects that are too far away to see)

Also, you might want to check out the forums at the Orbiter web site (http://www.medphys.ucl.ac.uk/~martins/orbit/orbit.html) ... Orbiter is a freeware space simulator (realistic space simulator, as in Soyez craft, Apollo craft, Space Shuttles, Voyager probes, etc.), and they seemed to work out the whole planetary system rendering. Also, it has a SDK for developing space-craft plugins (there is a whole MOD community who develop space craft), and it might give you some insight into how they handle their rendering.


Second Chance(Posted 2003) [#11]
Thank a bunch guys, those are all great suggestions. They certainly helped me have a different perspective on solving the problem. It's nice to know that there are always new solutions that just haven't been thought of yet. I especially like the idea about keeping the ship at 0,0,0 and moving everything around it, very clever. Forums are such a great place to find people who can get you thinking in a whole new direction, and not just tell you to give up because what you really want is boring and no fun (ahem). Keep the great ideas coming, I know there's a way around this problem yet! Thanks :)


Andy(Posted 2003) [#12]
Or you could experiment to find out the greatest distance you can use, and then place the camera at half that distance on one side of origo and rotate the planets around the camera in the rest of the visible space...

And why not resize and move the planets dynamically? With such great distances, you can't really tell if the planet is millions of miles away and 10 times the size of earth or a mile away and the size of the moon.

Andy