Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Jitter with close 3D objects.

Author
Message
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 7th Oct 2008 16:12
Link
Hi All,

I have come to a "deal breaker" situation unless I can overcome the following problem.

I have been trying to position the view camera where a pilots eyes would be in a 3D aircraft.
Basically a flight sim where the pilot can look around and should see the aircraft cockpit around him.

I get massive shake of the 3D aircraft as the camera is in any sort of motion, even if it is moving very slowly. (maybe the precision of calculations within this game library is too corse?)

I suspected that I had somehow messed up the position coupling for the aircraft to the camera.

As a test I placed a sphere of 1 meter diameter, 1 meter in front of the camera but using the camera Co-Ordinate information.

No way to mess that up.

This produces the sphere


This positions the camera from data from its data structure.


And this keeps the sphere 1 meter in front of the camera.


Has any one found a way around this sort of problem, as it makes it impossible to have a view point within any sort of vehicle, as the jittering is very bad.

I am happy to post a demo (proof of concept) of the flight sim demonstrating this problem, or even the full source code if it is required for solving this problem.

Any help would be greatly appreciated.
Back to top
Profile PM Email
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Oct 2008 19:10
Link
Quote: "I am happy to post a demo (proof of concept) of the flight sim demonstrating this problem"

Good. How about just a small piece of runnable code showing the problem? We don't need your flight sim code, just something that shows in general what the problem is and how you coded it.

[b]Utility plug-ins collection (updated 27/09/08) and
http://www.matrix1.demon.co.uk
Back to top
Profile PM Email Website
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 8th Oct 2008 07:53 Edited at: 8th Oct 2008 08:12
Link
I tried a small piece of runnable code, but it does not demonstrate the same problem. It appears there are not enough processing overheads on the engine.

Please note, I am not overloading the game engine as I can run that game code at over 300FPS with "wait for vertical sync" disabled

It looks like the engine looks at the number of 3D objects in the game and does some sort of object rendering movement sequence optimisation in the background.
Almost as if objects are left in their old 3D co-ordinates until the camera has moved by some amount of movement, and then it updates the 3D images.
For distance objects it is not a problem, but for close objects the step is very large as the movement is magnified by the closeness to the camera.

Here are 2 pictures where the offset can be easily seen when one compares the sphere wire frame compared to a painted cross hairs on the camera face (cockpit is 2D picture overlay on camera).

pointing aircraft to the blue sky so that the sphere wire frame is easily visiable.





This time I even made it this way to make sure there were no data type precision errors possible:
Back to top
Profile PM Email
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 8th Oct 2008 12:20
Link
Maybe your problem is related to

World X Location : 100005.000000
World Z Location : 100000.000000

look if these numbers 'jump' as well. If they do, then you probably have reached a float precision issue.

Try to reduce the loss of precision in calculus, try to use lower values (or values with a similar magnitude order). Using double floats for calculus may help too.

Or more simple, test if the 'jitter' still happens when those 'World Locations' are near to 0.0
Back to top
Profile PM Email Website
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 8th Oct 2008 12:57 Edited at: 8th Oct 2008 13:26
Link
Quote: "Maybe your problem is related to

World X Location : 100005.000000
World Z Location : 100000.000000
"


You are correct.

At world co-ordinates of 0,0,0 the jittering is totally gone.

The further one moves away from these co-ordinates then the jitter slowly increases.

It looks like even world location values of 2000 (which is only 2KM on my map) in any direction produces noticable jitter, but not too bad. Much further than that and it becomes unusable.

In the last test,"dbPositionObject ( 999, dbCameraPositionX ( ), dbCameraPositionY ( ) , dbCameraPositionZ ( ));" as I was using direct data from the camera to the object, There is no way I can use double float values. This game library with its single float returned values is the current limiting factor for me.

I wonder if I can fix the players aircraft at world values of 0,0,0 , and move the terrain with every thing else relative to this point when the aircraft is actually flying.
It will be a significant increase in overheads.

Has any one else found a workaround for this sort of problem.

Thank You Morcilla .
Back to top
Profile PM Email
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 9th Oct 2008 14:02
Link
Hey you're welcome.

Quote: "This game library with its single float returned values is the current limiting factor for me."


Well, graphic cards are limited to single floats too, so it is just being coherent. However, loss of precision can be carried and increased with previous calculus, so using doubles for the CPU code may contain the loss of precision.
Of course, this is not the case of a simple 'dbCameraPosition'.

I'm afraid that you'll have to move the 'world' and not the player. Some other solutions include to move 'everything' by steps, taking all back to 0,0,0 when player and/or camera gets further than a certain distance, so that re-position doesn't damage performance every loop.
Back to top
Profile PM Email Website
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 9th Oct 2008 15:27
Link
Dungeon siege apparently used a system that didn't have this problem - it used a two-part coordinate, and converted this to floats when rendering. The first part of the coordinate was an integer, while the second part was a float. The scale of the float part to the integer part was chosen to give the required resolution for the incremented they required.

For example, you might find that your precision becomes unacceptable when float values hit 1000.0 - at that point, your integer would be set to 1, and your float would be reset to 0.

All your calculations would take place on these coordinate pairs. Only when positioning the objects prior to rendering would you convert these two-part coordinates back to floats. This would remove the 'add a number to the float and get the same number back' issues of large floats.

In addition, now you have both a large-scale and small-scale coordinate system, you can subtract the integer part of the players position from all other integer parts before setting the players integer parts back to zero - this will automatically move the world centre as Morcilla suggested.

Hide all of that in a coordinate class and you'll never need to worry about it after you've written it.

[b]Utility plug-ins collection (updated 27/09/08) and
http://www.matrix1.demon.co.uk
Back to top
Profile PM Email Website
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 10th Oct 2008 08:12 Edited at: 10th Oct 2008 11:06
Link
Thank you gentlemen.

I will sit in front of the TV with a few beers and think carefully about all that you have said before I make a choice of all possible procedures and may do something that is not optimal for my requirements. It will definitely have to be an origin remapping procedure of one sort or another.

It is a real pleasure to be a member of a forum where there is such a wide range of expertise so that almost any problem can be overcome.
Back to top
Profile PM Email
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 10th Oct 2008 19:42
Link
Or you could just shrink everything by 1000, or 100, since floats can represent small numbers accurately too

[b]Yuor signutare was aresed by a deslyxic mud...
BOX2D V2 HAS HELP FILES! AND A WIKI!
Back to top
Profile PM Email Website
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 11th Oct 2008 01:49
Link
Quote: "Or you could just shrink everything by 1000, or 100, since floats can represent small numbers accurately too
"


If one shrinks everything by a fixed amount, then the relative distances are also shrunk by the same amount.
This moves the closer objects closer by that same amount, and therefor the angular jitter is the same as before the shrinking.

There would be no advantage.

The problem is caused because of the relative small sizes of the models and close distance between parts of the models to the camera (the cockpit to camera distance 0.2M), and having huge distances that the models travel around in (1,000,000 M).
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2024-11-25 03:26:31
Your offset time is: 2024-11-25 03:26:31