FreeGameDev

I've discovered an odd problem in Hacienda track. When in the building if you ask for help you will be set down in a face plant that toggles rapidly between that and facing straight up. The camera stays level but the kart moves. I think this is because it is set down half in and half out of the mesh due to a low driveline.

And I thought the little jump when I press the skid button was weird...

Is it possible to make some kind of sceenshot/movie?

I had a bug like this on arena in 1 person battle mode. the kart would move exactly like hero described I just forgot about it. and It happened whenever I played the track and only at the start.

I'll see if I can get a shot...

Here we are.



Just a note. It toggles rather randomly.

Hmm I can't reproduce the problem. Do you have a specific way to make it happen, or is it just random?

Go into the building and press your help button. It always happens.

I haven't tested with everything. You can try to replicate the cart amount. I am in Racer.

Sorry, can't reproduce

I'll check when I download the nightly build tomorrow.

The problem still occurs in the latest nightly build.

Just a note. You must rescue when you are just about to go out of the building. I just found out that if you rescue earlier there is no bug.

I had a pretty similar issue with an Intel chipset: isn't it related to your GPU?

Hi,

I can't reproduce this either. Is it possible that you have local modifications?

noname120 {l Wrote}:I had a pretty similar issue with an Intel chipset: isn't it related to your GPU?

I am on an Intel chipset as well.

Cheers,
Joerg

It's not impossible but the Hacienda in question is not my version...

It clears up if you move. But it happens every time I try.

hiker {l Wrote}:Hi,

I can't reproduce this either. Is it possible that you have local modifications?

noname120 {l Wrote}:I had a pretty similar issue with an Intel chipset: isn't it related to your GPU?

I am on an Intel chipset as well.

Cheers,
Joerg

I meant an old Intel chipset:
I actually have an Intel chipset (more recent) and I have no issue.

For me exactly the same happens with the current SVN version (self-compiled). You have to press the rescue button (Backspace for me) in about the middle of the building to reproduce it.

The only thing I modified once is installing the modification for "unleashed AI", which I removed again afterwards by reverting the SVN repository.

I recorded it, please see this video: http://dl.dropbox.com/u/14874671/Hacienda.ogv

Using Kubuntu 12.04 with the open-source radeon drivers for ATI cards.

None of the main developers can reproduce this so far It appears to be a graphical distortion only, correct? I.e. if you drive everything is fine?

Are you all compiling stk yourself, or using the nightly build? Unfortunately I can't use those(no matching glibc).

Could you (someone compiling stk) reproduce the issue in a single kart race, then after the incorrect rescue (and driving a second so that the kart is normal again) press F10? This create a history.dat file, which might help us to reproduce this issue. Just compress it(!), and post it here. It might be a graphics driver problem, or a compiler bug ... or a very sneaky STK bug

Cheers,
Joerg

I use nightly build on a Linux machine.

By the way this "Sneaky STK Bug" is something that often happens in Blender games with a physics mesh difference and an solid object inside a another solid object. Not quite this, but sometimes a lot of jumping and often being propelled "to infinity and beyond".

I'll try an experiment to fix the bug for now.

I am compiling STK myself from SVN.

It seems that this indeed is only a graphics problem. The physics are unaffected by this. You can even start driving normally by pressing the accelerate button, and the issue stays for a short time (but it is immediately gone when you steer, or you are touched by another kart).

Could this be some kind of rounding issue, perhaps triggered only by some graphics drivers? When you look at the mini map, it seems that on this position the driveline is exactly oriented in the west-east direction. I remember when I had to do an OpenGL assignment, some strange problems also happened in such corner cases.

I attached a history.dat file of a race, where I reproduced the bug.

Edit: I noticed that on XR591 the track is also entirely west-east on some places, and that the bug is reproducible there too: http://db.tt/UOZRsOJa. So the problem doesn't seem to be the rescue itself, but that it places the kart in this exact direction. Without rescue, you won't get in the x-direction precisely enough

WillemS {l Wrote}:It seems that this indeed is only a graphics problem. The physics are unaffected by this. You can even start driving normally by pressing the accelerate button, and the issue stays for a short time (but it is immediately gone when you steer, or you are touched by another kart).

I would agree with that.

Just to be sure: if you replay the history (use --history on the command line, in the directory where the (uncompressed) history.dat file is) - do you see the effect (note that the camera might be a bit messed up when the rescue happens)? I don't (neither windows nor linux).

If you see the problem, can you apply the following patch:

{l Code}: {l Select All Code}

supertuxkart/src/karts> svn diff kart.cpp
Index: kart.cpp
===================================================================
--- kart.cpp    (revision 12179)
+++ kart.cpp    (working copy)
@@ -1012,7 +1012,11 @@
     
     // Update the position and other data taken from the physics   
     Moveable::update(dt);
-
+    printf("Rot: %f %f %f %f\n", getVisualRotation().getX(),getVisualRotation().getY(), getVisualRotation().getZ(), getVisualRotation().getW());
+    static int xx=0;
+    xx++;
+    if(xx>=904)
+        printf(" ");
     if(!history->replayHistory())
         m_controller->update(dt);
     if(m_camera)


Then try running stk in gdb:

{l Code}: {l Select All Code}

gdb ./bin/supertuxkart   # or whatever
(gdb) break kart.cpp:1019
Breakpoint 1 at 0x90d624: file /home/joerg/local/supertuxkart/supertuxkart/src/karts/kart.cpp, line 1019.
(gdb) run --history


This should run till just when the kart is rescued. Then press 'c' for continue several time till you see the kart flipping. What are the values printed at that time - I'd guess something like

{l Code}: {l Select All Code}

 Rot: 0.000000 0.707107 0.000000 0.707107


perhaps with a minus sign in front of a 0.000 ?
If this is the case, can you modify history.dat and remove the '-' sign in front of all -0.00000 at lines 2034, e.g.:

{l Code}: {l Select All Code}

0.000000 0.000000 0  70.625000 0.119928 100.000000  -0.000000 0.707107 0.000000 0.707107
...
0.000000 0.000000 0  70.625000 -0.174121 100.000000  0.000000 0.707107 -0.000000 0.707107



It's just a wild guess, but perhaps the minus-sign triggers a bug. If so, we could try to avoid this situation at least. Note that my history.dat file also contains -0.0000.

Thanks!
Joerg

hiker {l Wrote}:Just to be sure: if you replay the history (use --history on the command line, in the directory where the (uncompressed) history.dat file is) - do you see the effect (note that the camera might be a bit messed up when the rescue happens)? I don't (neither windows nor linux).

When I replay the history file (wow, I didn't know that was possible ) I do see the bug too. However instead of the flickering behaviour, the kart is just displayed upside down and stays that way. See this screenshot: http://db.tt/TQfNXGyB. I suppose that happens because the history file contains rounded values for the kart coordinates? (Just guessing...)

hiker {l Wrote}:If you see the problem, can you apply the following patch:
[...]

After applying the patch and recompiling, I tried to set the breakpoint using gdb as you described, but gdb returns

{l Code}: {l Select All Code}

(gdb) break kart.cpp:1019
No symbol table is loaded.  Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n])

I didn't know how to fix this, so instead I directed the output to a file:

{l Code}: {l Select All Code}

bin/supertuxkart --history > stklog

and opened the resulting file in a text editor. This is the relevant part:

{l Code}: {l Select All Code}

Rot: 0.000000 0.736886 0.000000 0.676017
Rot: 0.000000 0.736886 0.000000 0.676017
Rot: 0.000000 0.736886 0.000000 0.676017
Rot: 0.000000 0.736886 0.000000 0.676017
 Rot: 0.000000 0.707107 0.000000 0.707107
 Rot: 0.000000 0.707107 0.000000 0.707107
 Rot: 0.000000 0.707107 0.000000 0.707107
 Rot: 0.000000 0.707107 0.000000 0.707107


Afterwards, all lines printed are exactly the same (until Replay finished). There are thus no minus signs here.

I tried replacing in history.day all occurrences of -0.000000 by 0.000000, but that unfortunately doesn't change anything, nor in the appearance (the kart is still upside-down), nor in the output.

I decided to experiment further with the history.dat file. For reference, consider this line from the original file:

{l Code}: {l Select All Code}

0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707107 0.000000 0.707107

Replacing all occurences of 0.707107 with 0.707000 (or any other value) also didn't change anything. For example the line would become:

{l Code}: {l Select All Code}

0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707000 0.000000 0.707000

But when I replaced all end-of-line occurences of 0.707107 by 0.707106 (so this only applied to the numbers in the 10th column, not in the 8th column), the problem didn't appear anymore. For example:

{l Code}: {l Select All Code}

0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707107 0.000000 0.707106

Replacing only non-end-of-line instances of 0.707107 by 0.707106 also prevented the bug from happening.

{l Code}: {l Select All Code}

0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707106 0.000000 0.707107

I tried (from the original file) replacing the 0.000000 in the 7th column by 0.000001, and that also fixed the graphical problems.

{l Code}: {l Select All Code}

0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000001 0.707107 0.000000 0.707107

Finally I tried (from the original file) replacing the 0.000000 in the 9th column by 0.000001, and that also fixed the bug.

{l Code}: {l Select All Code}

0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707107 0.000001 0.707107

Summary:

{l Code}: {l Select All Code}

Bug triggered by:
0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707107 0.000000 0.707107         // the original line
0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707000 0.000000 0.707000         // 8th and 10th column changed to the same value

Bug not triggered by:
0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707106 0.000000 0.707107         // 8th column changed
0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707107 0.000000 0.707106         // 10th column changed
0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000001 0.707107 0.000000 0.707107         // 7th column changed
0.000000 0.000000 0  70.625000 -0.990000 100.000000  0.000000 0.707107 0.000001 0.707107         // 9th column changed


So it seems something goes wrong when the 7th column and the 9th column contain exactly 0.000000, and the 8th and the 10th column contain exactly the same value. I don't however know what these columns contain (quaternion rotation or something?) so I have no clue about how this could happen...

Sorry for the long post, but I hope it helps finding the cause of this strange behaviour

WillemS {l Wrote}:

hiker {l Wrote}:So it seems something goes wrong when the 7th column and the 9th column contain exactly 0.000000, and the 8th and the 10th column contain exactly the same value. I don't however know what these columns contain (quaternion rotation or something?) so I have no clue about how this could happen...

Yes, they are quaternions, so it looks like your graphics driver has a problem with exactly 90 degrees rotation. Gee, that's a pain - we have to see if we can avoid this, but this is a highly annoying bug. I mean, they can be used everywhere, not only with karts

Just for the record: you have the latest graphics driver? Does changing the graphics details change anything, perhaps even the resolution (not that I really believe this tbh ).

Thanks a lot for debugging this - I'll need a bit more time
Joerg

Can you try the following patch:

{l Code}: {l Select All Code}

src/karts> svn diff moveable.cpp
Index: moveable.cpp
===================================================================
--- moveable.cpp        (revision 12186)
+++ moveable.cpp        (working copy)
@@ -69,6 +69,9 @@
     Vec3 xyz=getXYZ()+offset_xyz;
     m_node->setPosition(xyz.toIrrVector());
     btQuaternion r_all = getRotation()*rotation;
+    if(btFuzzyZero(r_all.getX()) && btFuzzyZero(r_all.getY()-0.70710677f) &&
+       btFuzzyZero(r_all.getZ()) && btFuzzyZero(r_all.getW()-0.70710677f)   )
+        r_all.setX(0.000001f);
     Vec3 hpr;
     hpr.setHPR(r_all);
     m_node->setRotation(hpr.toIrrHPR());


and see if this fixes the problem?

I am not sure how we are going to fix this permanently (if this works) - it just doesn't feel right to have this code for everyone. Perhaps a setting in the config file (which you would have to apply yourself) will enable this or so - I'll discuss this with auria.

Cheers,
Joerg

This patch indeed fixes the issue, thanks! But I agree that it isn't really desirable to have to work around random graphics driver issues in application code...

I am using the open-source radeon drivers, just the version from the stable Ubuntu repositories (12.04). So it will probably not be exactly the newest version, although I don't know whether there is many development there. As far as I know there is not a lot of 3D hardware acceleration, mainly rendering by CPU. Therefore I assumed it wouldn't contain a lot of bugs. Sigh, I switched from ATI's fglrx proprietary driver to the open-source driver just to avoid the bugs in fglrx. I'll retry fglrx soon (if I manage to reinstall it) to see if this driver also suffers from the issue.

Hero, which driver/graphics card are you using?

Oh no, I hate trying to figure out the card. It took me a week so that we could get a driver and all that time I couldn't play STK because the graphics card and mismatched driver didn't work...

NVIDIA accelerated graphics driver version 96.

Graphics Processor: GeForce2 MX/MX 400

That's the most I can get. Is there anything else I can do?

Thank you Hero, I asked that because I wondered whether this issue appeared only with one driver.

So it seems that there are two drivers (my radeon driver, and your NVIDIA driver) suffering from the same problem; that's strange.