Attaching the player to an attached object (attachment chain) confuses the client #5013
Comments
orwell96
changed the title
orwell96
changed the title
|
While trying (again) to fix the problem that attach offset is not applied to the camera, I recognized 'interesting' behavior. seems like the Irrlicht coordinate system is reset sometimes. Does someone know and can explain to me what minetest actually does there? |
|
I think you mean the camera offset. |
|
Related #8037 |
|
minetest/src/client/content_cao.cpp Line 923 in ad8d68c v3f lastpos = pos_translator.val_old; fixed the issue, I don't know if there are any consequences to doing this.@paramat @SmallJoker |
|
@CoderForTheBetter Which issue does that fix? I can hardly believe that changing this variable does have any visual effect since it's only used for the footstep sounds. |
|
My mistake, I was using a mod I wrote that corrected for the 200 node offset, back to the drawing board. |
|
I've done more research, I'll leave what I found in case it helps someone else figure all of this out. Use a mod that will make a chain of attachments like the OP has, go to somewhere that is > 200 nodes (x, y, or z) away from the origin. I chose to do go 200 nodes in the negative x-direction, and then used this code, minetest/src/client/content_cao.cpp Lines 1319 to 1326 in ad8d68c just after line 1320. Now the attachment will be in the correct place; however, the '200' used above only works if the visual_scale in the axis you choose is 10 for the first parent entity, otherwise, you'll have to use a different number. The properties of the entities in my hierarchy were, root visual_size=(10,10,10), child1 (attached to root) visual_size=(0, 0, 0), and then player (attached to child1). The above is mostly a patch I think, as SmallJoker says, it might be a sync problem. |
|
@CoderForTheBetter Thanks a lot for your research. Indeed, a rotation & re-positioning calculation error is probably the cause for this issue. The node needs to be rotated at the position (0,0,0), whereas the camera seems to shift that. |
|
Figured out where that camera shift is happening: minetest/src/client/camera.cpp Lines 432 to 438 in 8e3b63b Commenting out those lines fixes these issues (at least the camera offset but not really the model's, it seems) but then teleporting very far from 0,0,0 results in visual glitches (even when not attached to anything) probably because of floating point rounding at large numbers (which is the whole point of these lines, to avoid those visual glitches). Just thought I would mention it. |
|
What's the status here after #8701 ? |
|
Tested with f51cf7c Attaching player to an attachment still unusable, view constantly wobbling around and visual glitches affecting the whole scene. Edit: I could reproduce it eventually, nothing has changed. |
|
As far as I can figure out, the camera offset exists because of float precision errors. Is there any problem with removing BS or changing it to something like 0.5? Or would it still be too imprecise in some way or another and cause compatibility problems? Excuse my ignorance, but I can't find much information on the full reason why the camera offset exists or proposals to make it better. |
You're talking about the camera offset and then asking if
|
This wouldn't help because all positions and distances are affected by BS, so e.g. it doesn't matter if you do |
|
I wasn't asking about this issue in particular, just about the camera offset; there doesn't seem to be any dedicated issue to the camera offset. Admittedly, this issue wasn't the most relevant. I was asking about BS because I was thinking (at the time of writing) that making every float smaller would increase precision (since BS makes everything 10 times larger), but I forgot that
happens. (I've probably been working with fixed point numbers in my own projects too much; I like them sooooo much better than floating point.) However, increasing precision to f64 would only work for entity position, not the camera offset. The camera offset affects SceneNodes, which use floats internally, so we'd have to change a lot of Irrlicht code to use f64s instead of f32s. |
Indeed, that's a bit of a bummer, but... Once I had a working version of 64bit(ish) MT, there are conversion operators between different versions of vector and abbox, that could be incorporated into MT Irrlight fork. |
|
A problem is attachment chains, where object 1 is attached to object 2, which is attached to object 3. Each object has its own position relative to the parent object, and they're all floats. It sounds very hard to work doubles into the mix. Is there an issue somewhere that I overlooked that mainly concerns the camera offset? It routinely causes problems, so I wonder if there's an issue for replacing it with a less problematic solution. |
|
Do you have a less problematic solution in mind? |
|
Not at the moment, but having a place to discuss better solutions would be nice. A recurring problem like the camera offset surely deserves its own issue instead of scattered conversation in IRC and different issues. |
I still wonder why there should be a problem though. relative positions and camera offsets are still fairly large numbers, and if I'm not mistaken, f32 error margin around 300k is a magnitude of a MT world centimeter, that should be plenty enough precision for camera movement. |
|
Ah of course, the problem isn't about the position of camera itself, but rendering in the camera space, and I can see that 1cm precision imay be insufficient for that. A temporary improvement could be to increase the step, why 200 if 900 should give roughly similar precision. Maybe consider changing MT Irrlicht fork so all positions are f64, that might not be too difficult, and if conversion operators were to be added MT should work with such version without changes, and still would benefit somewhat from increased precision of internal Irrlicht calculations. |
|
I have implemented the dummy object workaround in the Konstal 105 modpack here: https://invent.kde.org/davidhurka/doxy_mini_tram/-/tree/work/davidhurka/attachment-object. You can try it out with this modpack yourself. On Minetest 5.4.1 from snap, the problem still persists to the full extent.
On Minetest 5.6.0-dev self-compiled, I could not observe any problem. (But: The box on which I run self-compiled has far more than 100x more performance than my slowbook, so it may well be that I just didn’t see the issue.) If anyone has time to check out my modpack 👓 , please do so to confirm my observations. You need to build a long advtrains track, place a “Minitram Konstal 105” on it (while looking forward along the track), enter it (rightclick), and accelerate (forward button). You can disable advtrains_attachment_offset_patch, then you see the behavior without workaround. You can easily tell that it is disabled, because you just see the floor of the train and can not look through the windows. Well, that is the reason why #10101 is so annoying. ;) I will try it myself with Minetest 5.6.0-dev on the slowbook, as soon as I have lots of time to compile. ;)
I have not tested enough to be sure this does not happen anymore. I haven’t observed it. |
I have now compiled Minetest 5.4.0, 5.5.0, and today’s 5.6.0-dev on both computers. I wasn’t able to reproduce the problem anywhere. On 5.4.1 from snap it is gone too. I didn’t install any of the compiled versions, and I also didn’t install updates and didn’t even reboot the slowbook since tuesday. Can anyone explain what is going on? |
|
Your client is haunted. The only explanation would be a race condition or mismatch in your testing results/notes. Please ask to re-open this issue if you find testing code that's reproducible (more or less) reliably on 5.5.0 or 5.6.0-dev. |
Situation:
To get a workaround to the "feature" that the eye position is not moved when a player gets attached to an object with an offset given, I did the following.
Imagine 3 Entities:
When all objects are near (0,0,0), everything's fine, but as soon as you get more distant from (0,0,0), problems arise.
Problem:
Here's the output of minetest --verbose:
ID 7 is the wagon, ID 8 is the dummy entity.
As you can see, the blocks where the wagon and dummy entities are get unloaded...
Disabling anticheat does NOT fix the problem, so this is not the cause.
You can use this to test.
The text was updated successfully, but these errors were encountered: