Ship Shaking

@Lancer:

**The error is actually due to matrix destabilization. The matrix for the camera is based off of the coordinates of the ship. Once the numbers get large the floating point errors start getting quite large. There is a fix but it would require an addition to the exe to fix it (w0dk4, a hook maybe?)

The quaternion matrix needs to be normalized right after its created and before it is transformed with the position vector. It is a single DX command but without the source I am unable to fix it.**

youll forever been an enourmous source of knowledge mate lol

@Lancer:

**The error is actually due to matrix destabilization. The matrix for the camera is based off of the coordinates of the ship. Once the numbers get large the floating point errors start getting quite large. There is a fix but it would require an addition to the exe to fix it (w0dk4, a hook maybe?)

The quaternion matrix needs to be normalized right after its created and before it is transformed with the position vector. It is a single DX command but without the source I am unable to fix it.**

As I understand it, the floating point errors increase simply because of the high float numbers, losing precision. How does your proposal help solve that?
I dont know a lot about 3D DirectX math stuff so please explain a little more

**Well, I ran into this exact same problem writing my game engine. It took some time to track it down but it turned out that one of the quaternion routines in DX requires a normalized matrix. Unfortunately I don’t know where it is stored in FL, I ran across it a couple of years ago.

Basically the matrix needs to be normalized (converted to a 0.0 to 1.0 range) after this command D3DXQuaternionRotationYawPitchRoll and before this command D3DXMatrixAffineTransformation. The command that needs to be called is D3DXQuaternionNormalize and it needs to be the output from D3DXQuaternionRotationYawPitchRoll.

Sorry, I said position earlier, I was at work and didn’t have the code to look at, still part of the position transform is done by D3DXMatrixAffineTransformation. .

BTW, it’s actually the camera shaking, not the ship.

Edit - forgot to mention this, but the fix can also be applied in the view matrix calculation routine…**

So, I have been doing some research on this and found quite a few things, sadly my conclusion is bad:
Not fixable.

I was right earlier in this thread, floating points simply lose precision and at values of like 5000k, this precision error is already 0.5m. Thats why your cockpit jumps all over your screen that far out in a system.

@LS: FL doesnt really use D3DX functions as far as Im aware, they have their own math library which can be found in x86math.dll.

I’ll look thru my math code and see if I ever wrote a matrix normalization routine.

i smell a hook plugin ^^

I’m crossing my little fingers and toes that it does mean that

@Sushi:

I’m crossing my little fingers and toes that it does mean that

im hoping so bad ill cross your fingers and toes FOR you ^^

edit cant believe i spelt toes as “tows” rofl

There is no real way to fix this. The important thing to understand here is that Freelancer uses floating points (and I think, D3D8 also only supports floating points for camera stuff, but I may be terribly wrong there) for everything related to space positions and the camera.
When you are at 1000k and 1.0 = 1m, you have a precision of around 6cm.

Now imagine your ship standing at position 0, 1000000.03, 0
Since floating points cannot hold 1000000.03, but only 1000000.0 and 1000000.063, your ship and/or the camera may jump 6cm all the time. You see your ship shaking.
Also, what is important to understand: At those precision errors you can no longer fly in a straight line, your ship will shake when flying (or lets say, your ship will fly in zig-zag-pattern). This is especially visible at extreme distances, like 10000k, if you would login with 2 chars and would spectate the other player flying around.

This happens also to sur files, I’ve noticed that my station at 140000, 105000, 120000 has nearly no collision detection, so i moved the station to 100000, 70000, 95000 and the collision detection is back as it should be.

Greetz
Mind

Note: Its a modul station made of 12 parts + the dock.

Hmm, that’s interesting. We haven’t noticed this effect at FWs, and we have stations 500km from the centre.

@Sushi:

Hmm, that’s interesting. We haven’t noticed this effect at FWs, and we have stations 500km from the centre.

Can we have a look at your constants.ini Sushi please?

[Constants]
COLLISION_DAMAGE_FACTOR = 2
MUSIC_CROSS_FADE_DELAY = 10.000000
MUZZLE_CONE_ANGLE = 25 ;Cannot be zero
PLAYER_COLLISION_GROUP_HIT_PTS_SCALE = 1
PLAYER_ATTACHED_EQUIP_HIT_PTS_SCALE = 1
MAX_PLAYER_AMMO = 1000000000

[EngineEquipConsts]
CRUISE_DISRUPT_TIME = 1
MAX_DELTA_FX_THROTTLE = 0.250000
THROTTLE_STEADY_TIME = 0.500000
THROTTLE_ATTEN_MOD_RANGE = 8.000000
DELTA_THROTTLE_ATTEN_MOD_CHANGING = 8.000000
DELTA_THROTTLE_ATTEN_MOD_STEADY = -1.000000
CRUISE_STEADY_TIME = 10.0;0.100000
DELTA_CRUISE_ATTEN_MOD_STEADY = -5;-1.000000
CRUISE_ATTEN_MOD_RANGE = 8.000000
CRUISING_SPEED = 5000		;10000
CRUISE_ACCEL_TIME = 5		;0.5
CRUISE_DRAG = 85		;250

[ShieldEquipConsts]
HULL_DAMAGE_FACTOR = 1.0

[PhySysConsts]
MATERIAL_FRICTION = 0.001;0.100000
MATERIAL_ELASTICITY = 0.2;0.500000
DEFAULT_LINEAR_DAMPING = 0.500000
DEFAULT_ANGULAR_DAMPING = 0.200000, 0.200000, 0.200000
ANOM_LIMITS_MAX_VELOCITY = 1000000
ANOM_LIMITS_MAX_ANGULAR_VELOCITY_PER_PSI = 0.04
;RMGR_LOOK_AHEAD_TIME_WORLD = 0	;no idea what I'm doing here
;RMGR_LOOK_AHEAD_TIME_INTRA = 0

[CommConsts]
COMM_PLAYER_FAR_DIST = 6000.000000
COMM_PLAYER_FAR_DIST_ATTEN = 0.000000
CHATTER_MAX_DIST = 100000;3500.000000
CHATTER_MAX_DIST_ATTEN = -8;-16.000000
CHATTER_START_ATTEN = -2.000000
COMM_CONFLICT_PRIORITY_CUTOFF = -10;-3
WALLA_MAX_DIST = 100000;3500.000000
WALLA_MAX_DIST_ATTEN = -8;-24.000000
WALLA_START_ATTEN = -2;-8.000000
WALLA_PRIORITY_CUTOFF = -10;-3

[AsteroidConsts]
MAX_ASTEROID_LOOT_DAMAGE = 20000.000000
MAX_LOOT_PER_ASTEROID = 3

Well, I stand corrected. The base collision works about 70% of the time at this distance from the centre. Very interesting. I’ll have to get my guys on it to see what’s going on.

What’s even stranger is that collision detection works fine on the ships at this distance.

I agree with W0dk4 there i a limit to how much the normalizing will help. Even in GE the ship begins to shake a little bit at 2 million units out. And I use normalization on all of my matrices. The only sure fire way to get around the problem is to split up huge systems into sections and move everything in the system each time a player crosses one of the boundary. don’t know difficult it would be to make a plugin for that but I have a feeling it wouldn’t be easy.

Alright, did a lot more thorough testing here:

130km seems to be a cutoff for all hiboxes. Ones that worked under 130km, may not work over 130km
Some boxes work fine at 150, 200, 300,400, 500km. These boxes seem to be square in shape, with no rounded/curve points to them. Combining the hitboxes didn’t seem to have an effect at under 130km or 500km. The box worked or it didn’t. So, what does this mean…I dunno…aside wanting the source code and being pissed at digital anvil for making these arbitrary cutoffs :@

@Lancer:

I agree with W0dk4 there i a limit to how much the normalizing will help. Even in GE the ship begins to shake a little bit at 2 million units out. And I use normalization on all of my matrices. The only sure fire way to get around the problem is to split up huge systems into sections and move everything in the system each time a player crosses one of the boundary. don’t know difficult it would be to make a plugin for that but I have a feeling it wouldn’t be easy.

Speak to blackhole, i believe he said something about this a while ago when he was talking about something similar, dunno if hell remember but im PRETTY sure it was him i was speaking to about this issue some time ago, tho i could be wrong.

I found a fix for the 130k sur collision detection problem:

0xED8B4 in common.dll (v1.0) 0.01f - collision detection min check distance

If you change it to 0.5f, you should be save until 4000k.

More details, how I found it:

What is intersting to note is that between 130k and 140k the floating point precision error is going from <1cm to >1cm.

Moved the base to
pos = 2000362, 1009, 1002

Then, I could fly through a lot of walls that I couldnt fly through at 0, 0, 0.

Now, load up common.dll and replace every occurence of 0a d7 23 3C with 00 00 00 3F (should only be like 5 places or so).
3C23D70A is 0.01f (I think this is the min distance the collision detection code checks for collisions, since at great distances the floating point error is higher than that, it gets bugged).

After that hack, I couldnt fly through any walls