Ship Shaking
-
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, 1002Then, 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
-
As I said on the FW:ToW forums:
http://www.youtube.com/watch?v=Fj6qQdLBwm4 -
-
After a long time of being rather inactive in Freelancer Modding due to RL, I finally came back to my old problem.
I made one rather interesting discovery:
- tested ship shaking being ~470k away from the center, with a Nav Map Cale of 0.2 –> heavily recognizable
- tested ship shaking 40k ayway from the center with a nav map scale of 0.8. Nothing else changed in the system (still a station 450k away from center etc.) --> ship shaking stays noticeable
Has this anything to do with the NavMapScale being below 1.0?
And now the most important question: Are there any possibilities to optimize the game’s math? My knowledge in programming is rextricted, but I could imagine such optimisation would be possible if the functions Freelancer asks for are kept in some way.
-
Unfortunately I doubt upgrading FL’s position calculations is possible because it’d require completely changing how it stores positions. The issue is inherent to the technique used and unfortunately can’t be fixed much. Even if we were to be able to apply certain error correction techniques, the issue would still crop up. Completely swapping out the technique requires work that can only be done with the source code (unless someone’s an ultra ASM guru and has years to work on it), which we don’t have.
As for shaking and navmapscale, I don’t think there’s any relation. Since it’s not a “feature”, I doubt the programmers would’ve tied both values in any way - they’d always prefer maximizing precision.
-
Well, then I actually will have to make things smaller. Weird though, that the FL-Developers didn’t fix a bug which is mostly clearly visible in cockpit view.
Thanks for the help though
Will concentrate on modelling now, making the system(s) smaller shouldn’t take much time. -
Excuse me, I know this is a old thread, but i really want to know how to solve this problem, because i was planning to make a very very big system (include big planet and big sun), but i also got this shaking problem. actually i can see station also shaking not only the ship ……
I don’t know if it is possible to change the data type (to double?) or other to make FL storage long float … although in my knowledge god can do this…
However, i want to ask is someone solved this problem…
-
I was talking to wodka about this and he was working on some changes via client- and serverhooking, but it’s a rather huge change so i guess it will take a while. Changing the data type to double would have a bad effect on performance (besides i don’t think it’s easy to do). I did some tests in my own 3D engine and I only noticed some unprecision starting at around 5000K from the center, so I am not sure whether this really is a precision problem at all.
-
Unfortunately, nothing is really telling us whether your 3D engine is using the same positioning method as Freelancer’s. Based on what we see (IE the output, logs and such), I’d say FL doesn’t appear to have the best code base in the world, so it’s possible that part is a bit unreliable too.
-
That is correct, but also means that FL would have to calculate internally with values greater than 1 million for the precision being a problem. I don’t know why they would have done that although I admit it IS Freelancer
Anyway wodkas approach would work completely around that, so let’s hope he succeeds. -
I dont know how OpenGL or your engine handles position data in detail, but floating point precision will always be an issue when dealing with high values.
Just think about it: At 130 000 the precision error is already 0,01 so no, I dont think this is due to bad coding of the FL devs.
