Sorry your browser is not supported!

I am working on a space simulator, and currently I have a chase camera following my space craft as I steer and move it around planets. I was attempting to make the solar system to scale, which requires me to use very fast speeds so that I can explore the solar system in a reasonable amount of time. However, I find that as I accelerate the ship to higher and higher rates of speed, the model begins to vibrate. It increasingly gets worse, and eventually the model appears as if it were tearing itself apart, it almost looks like its under some sort of a strobe effect.

Ive spent many hours attempting to investigate why this may be happening, and have had no luck. Originally I was using the dbMoveObject method, and I even attempted to position the object myself using vectors, but either method produced the same effect. I have also tried adjusting the move object step to be time based rather than frame based, but still no luck. I checked over all of my camera commands one by one to see if any of them are the culprit, and still I cant figure it out. To give an example to show the relative scale that Im trying to do this at, the model shakes pretty badly if I try the dbMoveObject with a step of 10,000 world units, and the model is scaled to a cube with sides of length .760

So is there something I am missing here? Am I busting some limits and just need to slow the relative speed of the model down? Or must there be a bug Im just not seeing in the code? Or is it something else entirely? Any help would be much appreciated.

Thanks,
Justin

I don't know if this will be of any *real* use to you, but:

Judging by my understanding of what's happening and the scenario you're presenting; I have to say that what you are describing - makes sense...

Let me explain... But first, a few assumptions on my part:

1) You're using a model for your space craft (duh).
2) That model defines vertex points at various positions which define the overall shape of the model (again, duh).
3) You're using some sort of transformation/rotation etc. that moves the object/camera in world-space (most likely using matrix math?) (yet again, duh) and;
4) You're using floating (and/or double) precision values in your calculations....

Are you with me so far?

Now, with these assumptions in place, let me just say that it sounds to me like a mathematical precision error... Remember, you're trying to represent numeric values (floating point) using a mere 32-bits...

With that in mind, 32-bits of precision on a scale of 0 to 1 equals
2^32 = 4294967296 and when scaling the results (1/4294967296) = 0.00000000023283064365386962890625 - which is the minimum adjustment required to reflect a change of a single bit (remember there's only 32) in floating point math...

Now, here's where I believe your problems comes from:

What happens if instead of some multiple of 0.00000000023283064365386962890625 being the adjustment required, it is actually a multiple of say 0.00000000023283064365386924351763? Instead of adjusting a single-bit, you would be required to adjust ~.99-bits; which obviously can't be currently done...

Are you with me so far?

Since you can't adjust just .99-bits, that adjustment would be modified in some way (either left out completely or rounded up) but either way, it would introduce *errors* in the math. Apply those errors, over time, to each vertex point of the model and Yes, I can envision exactly what you are seeing...

How would you fix this? I can tell you my approach, be it right or wrong, this is how I'd approach it:

First, I would choose a single point on the model that I would dub *Home*. From that point, I would cast a ray recording the direction and distance to EACH of the other points of the model and record that information...

From time to time, be it 10, 20, 30 frames (or some other measurable value) test the current values with the original values and correct vertex-data accordingly...

I hope this helps... I know it doesn't answer your question entirely, but I do hope it helps you understand what's going on. I really don't think, from the sounds of it, that you have an error in code (but I could be wrong)...

Regards,
Jumpster

Yes your assumptions are pretty much correct. And I had considered that it had to do with float accuracy, so I attempted doing the calculations in doubles, but when I use the position and move object functions I am forced to use floats.

As for your suggestion on making a ray to point to other points on the model, I must admit I wouldnt really know how to begin doing that. I made a model in Blender that (sort of) resembles the Star Trek Enterprise ship, and I just load that object in and position and move it as I need. That would sound rather challenging and expensive to get a ray to each and every vertex on this sort of object I would think. What are your thoughts?

True, not related with the speed but rather with the position. The precision of the float values is being reached.

Never heard before about Jumpster's solution but from other approaches like shifthing scenary positions and keeping the camera or ship near the origin (0,0,0). There are other solutions around here in the DGDK/DBPro forum.

Also watch out for that .760 size of the ship, it looks to me like it could go easily into the near camera plane (beyond camera range).

Thanks, you were both absolutely correct about the precision. I had thought of fixing my ship on the origin and moving everything else, but avoided it because I was afraid it would be a pain. But in fact with my other messing around I already had movement expressed as vectors so it was pretty easy to make the change. And yes now I can go very fast and not witness any of those unpleasant effects.

Morcilla, concerning the size of the ship, I had used the function dbSetCameraRange and reduced its inner limit to .001f, and it seems to work fine.

I have another issue with scaling though that maybe someone can help with. I have placed all of my objects inside of a giant sphere that is textured with stars for my space background. Well, whenever I have the background up, my very large planet objects, when I start getting some distance between me and them, begin to flicker and tear and you see black panels along the faces of the sphere. This effect is not observed though when I turn off my star background sphere, and the effect is only mild or unnoticeable when I am close to the planets.

I had one idea on how to solve this. At close ranges uses the same sphere method, but after a certain distance replace the sphere with a plane. The plane I was thinking could even be textured from a camera image viewing the actual spherical planet (the sphere and camera could be hidden outside my star sphere). BUT, this sounds like a pain in the butt, and Im hoping maybe someone might have some advice on a better fix.

Floats increase on a logarithmic scale - while you may be able to move 0.5 when a float has a low value, as the float grows larger, this becomes less and less accurate.

Using that 0.5 as an example, adding 0.5 to 8388608.0 will result in an unchanged value. Adding a value slightly higher than 0.5 will add 1.0 instead.

That's the reason for using combinations of scaling and re-centring of your scenery. With scaling, you move it closer and make it smaller.

Also take care of that camera range - a camera range that small will cause you z-depth issues at a higher range. For a good explanation of the problem, go here: http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html

Even in risk of being repetitive, just say that what IanM just explained very well is the same as your flickering problem.
That is, because...

Heres an opinion, you said this is to be a simulator, what if the object your model is supposed to represent can't physically travel at those speeds without the 'help' of some outside force eg slip-space travel to go at those speeds, something like that =D

If you understood what I just said.

Thanks IanMan,
Your information and that link exactly filled in the missing information for me. I now realize that yes Ill have to reposition and scale the objects to keep them at reasonable values. I wanted to avoid this because I think the math will be a bit of a pain to grind out, but its probably again going to be not as bad as im thinking. Thanks for the help again!