Jitters increase with distance from origin

Playing around with adapting my game to the new engine, I think I discovered something...

Background first -- I'm working on an airplane game -- it needs a large scale world. Unless I'm missing something, from what I gather the new terrain is not "movable" -- the origin is always with the SW corner of the terrain at 0,0 of the gameworld.

Ok, fine...

So I make a suitably large terrain (100000 x 100000) which I think means it's 100km square if I understand the scale correctly. Now, when I was setting up the airplane where it used to start -- near the center of the old game or, close to 0,0,0 it works fine. Unfortunately, though, this is close to the edge of the new terrain so I moved the base to the center of the map, which is now 50000,0,50000. Strange -- the cockpit instruments and controls are bouncing all over the place! After some fiddling around, it seems clear that the bounciness is related to the plane's distance from the origin -- my layman's hunch is that some calculations are losing precision due to loss of significant digits...

thoughts?

 

thought maybe a movie might help illustrate what I'm talking about:

http://homepage.mac.com/uncl3t/jitter.mov

 

thanks, yeah, that's what I surmised...

might be the only practical option at this point

tried it; doesn't work -- just "moves the decimal place" on the precision problem. And then the physics go out of whack too. :?

nope, it's not a gui -- rather a fully 3-D immersive cockpit... pretty crucial to the concept...

thanks anyway ...

 

Don't know if this would work, but would it be possible to make the Terrain the child of another object, then all you'd have to do is move the parent, and hopefully the Terrain would move with it.

 

hmmmm.... interesting idea, hadn't thought of that... might be workable...

there isn't really a "GUI" though -- you are inside an airplane; you can look around (in fact you have to to survive...) the airplane interacts with the world...

maybe this will make it clearer what i'm doing... (unity 1.6)

http://homepage.mac.com/uncl3t/swinesample.mov

 

Great looking demo! A couple of things I noticed are that you seem to be able to shoot your own propeller, and the propeller needs a motion blur disk to make the slow motion movement look more realistic.

I think what Joachim is talking about having your 3D cockpit located somewhere else with its own camera. The image generated by the second camera is overlaid onto the main camera's view, thereby creating the 'GUI' in the main view. If you synchronise the rotation of both cameras then the second camera would still look around the inside of the cockpit, which should give you the effect you're after.

 

Thanks :-D -- that's an ancient version -- prop has since been improved and actually, you can't shoot the prop -- the gun just misses it (fires over it) (if you saw a side view you'd see )... but anyway... :-D

yep, I get it -- except the cockpit is illuminated by the light in the scene, and the pilot camera is affected by physics (head lolls around due to g-forces, etc.)

doesn't mean you couldn't make what Joachim suggests work, justs means it gets really complicated [I think].

 

Is the main camera attached to the pilot's head? If so then you'd have to synchronise the second camera with the rotation of the pilot's head instead.

I think the lighting is where you're really going to hit problems. Although, you could simulate identical dynamic lighting around the cockpit. To do this you would also need to synchronise the rotation of the cockpit with that of the plane. This would also mean that you would need to move the second camera.

One way to do it might be to make the second camera a child of the cockpit as it would move automatically when you rotate the cockpit (which is synchronised with the plane's rotation). You could then synchronise the local rotation and movement of the cockpit camera with the pilot's head. All lights that are affecting the plane in the primary view would need to be recreated in the secondary cockpit view. The only problem you'd be left with is shadows from clouds or other planes, assuming they exist in the primary view.

BTW, I really like the chain system that's holding the plane before it launches... very cool.

 

After thinking about this some more, I think the two camera approach is indeed probably the way to go. Thanks for the suggestions Joachim Neural_Echo.

I'll let you know how it goes...

--Bo

 

I've done the two cameras thing before and it works fine. I did it mainly because I didn't want bits of the outside world (space dust, asteroids etc.) to be able to poke into the cockpit interior of my spaceship.

On the other hand, it might not be perfect if you want pieces of the scenery to be able to pass between the camera and your wingtip. For that effect, you might need to have the cockpit on its own camera, and have the plane exterior as part of the outside world in the usual way. If you do that, the plane exterior will jitter as usual, but at least it's further away than the cockpit interior and the effect should be less pronounced. I suppose you could just claim that it's turbulence that's making it shake around.

Nice visuals in the movie, by the way. Looking forward to seeing how it plays!

 

Thanks... I probably will need to take the second approach as there are things that can bounce off the plane :-D -- I suppose a third approach would be to test for foreign object collision or proximity and switch to a third "render all" camera for the duration (accepting, nay, relishing the jitters)...