Ship Shaking
-
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. -
I do get you point, but the question is, whether you would see it. I use 1:1 position data even for the physics engine and at 500K the movement seems still fluid, regardless of small or fast speed. Either way since we don’t know (yet) exactly what Freelancer does I guess we just wait and see if your method works.
-
Well, do you have implemented smooth camera movement in your engine? I suspect you only have linear non-acceleration based camera movement, which means that the position of your camera is static, therefore you dont see the shaking effect.
In FL, the camera is in most cases always in little motion (change of 0.00001 in a rotation may result in vastly different matrix transformations due to the high precision error) which I think is the origin of the shaking.
Im also not entirely sure if this is true, but for me thats the only logical explanation.
-
**W0dk4 hit it on the head. The camera in FL is an attached camera that is based off of the ships position. It isn’t the ship that’s shaking, it’s the camera. The camera in my game is designed exactly like the one in FL but in my case I can make it show the position of the camera in real-time. It jumps around just like it does in FL once it gets way out from the center. The ship’s position is shows a much smaller jumping.
There is a feature in FL that allows you to lock your camera to the ship without any sliding from side to side, you could try that to see if the shaking goes away.
Also, only moving objects will appear to shake, not stationary ones.
Hope that helps explain it….**
-
I found selution for that problem. Custom cokpits dont shake match do to there size but all originale FL cockpits shake like crazy end the problem is that they (FLC) ar wery small size ( + - 0, 1 )
Resize the cockpits to atlis ± 5 or higher end shaking will go awey.
Youse FMR ( Freelancer model resizer ) on the cockpits . Try it end see how it go
-
[dream]Fixed.[/dream]
Hi all, happy new year!
First of all, apologies for bumping this very old topic.
Was wondering whether there is any news on this subject that I’ve missed (doesn’t have to be big). For example from earlier in this thread:
LancerSolurus wrote:
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.or
Schmackbolzen wrote:
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.Anyone still working on this?
Just checking.
-
No, there’s no work on this and it’s unlikely there will ever be a fix.
-
Yeah, it’s the individual object matrices which become denormalized. If you perform all the calculations and rendering in camera space instead of world space (by moving everything so the camera is at the origin before rendering the frame, then reverting all that after rendering), you already get a noticeably lower amount of shaking for the exact same inputs. The rest of the shaking is probably caused by the positions themselves becoming inaccurate.
Unfortunately, I don’t have the ability to do that space transformation for everything (specifically, it breaks ALEs and I believe stars), so it’s not currently viable.
-
G Gold_Sear referenced this topic on
-
G Gold_Sear referenced this topic on
