Bullet assertion error in new China track

[supertuxkart-sourceforge-migration]

Author: auria

The China track posted on the forum crashes :

#5  0x0029ce07 in btQuantizedBvh::quantize at btQuantizedBvh.h:355
#6  0x002a7037 in btQuantizedBvh::mergeInternalNodeAabb at btQuantizedBvh.h:278
#7  0x002a591b in btQuantizedBvh::buildTree at btQuantizedBvh.cpp:156
#8  0x002ed4df in btOptimizedBvh::build at btOptimizedBvh.cpp:184
#9  0x002d8d05 in btBvhTriangleMeshShape::buildOptimizedBvh at btBvhTriangleMeshShape.cpp:351
#10 0x002d8d96 in btBvhTriangleMeshShape::btBvhTriangleMeshShape at btBvhTriangleMeshShape.cpp:37
#11 0x0012d4f7 in TriangleMesh::createCollisionShape at triangle_mesh.cpp:94
#12 0x0012d5e7 in TriangleMesh::createPhysicalBody at triangle_mesh.cpp:119
#13 0x0010c27c in Track::loadMainTrack at track.cpp:930
#14 0x0010da20 in Track::loadTrackModel at track.cpp:1197
#15 0x000eb857 in World::init at world.cpp:138
#16 0x0026e1a7 in WorldWithRank::init at world_with_rank.cpp:27
#17 0x000df81f in LinearWorld::init at linear_world.cpp:54
#18 0x001663e4 in RaceManager::startNextRace at race_manager.cpp:359
#19 0x0016743b in RaceManager::startNew at race_manager.cpp:302
#20 0x0016754f in RaceManager::startSingleRace at race_manager.cpp:625

See http://forum.freegamedev.net/viewtopic.php?f=18&t=2016&sid=1f206b7f0f08d29c66e0ca19c5b6ddc8

Migrated-From: https://sourceforge.net/apps/trac/supertuxkart/ticket/442

[supertuxkart-sourceforge-migration]

Author: hikerstk Works on Linux, but crashes on windows.

[supertuxkart-sourceforge-migration]

Author: hikerstk Some vertices appear to be way out, which then (I am guessing a bit) is causing rounding problems later on when quantising (sp?)

This particular mesh has no texture attached, so I can't easily tell which mesh it is (from the .b3d files).

It's a mesh that has 562 vertices, and 834 indices (so 278 triangles). The first three vertices are at: 208.00423, 37.910168, 45.645103 (#0) 207.95564, 32.594353, 45.869049 (#1) 208.12427, 32.594353, 45.858242 (#2) ... The problem then starts at vertex 483 (when counting from 0): 66666628, -12.345046, 55.610699 (#482) 66666628, -12.345046, 55.636639 (#483) ... 66666628, -12.345046, 56.017330 (#497)

before the values become more reasonable again. When those large values are converted to an integer index, and then converted back, floating point errors causes this value to become 66666660, which is larger than the original value, triggering an assertion.

There is nothing we can do about this in STK (short of using double instead of float). Could you check if you can identify this mesh, and fix the model (e.g. removing this mesh, or at least the large vertices), or declaring this to be not exported in the track exporter.

I am leaving this ticket open for now, till it was confirmed that this issue is fixed by a change of the model (it might be an exporter issue).

We could potentially add some debug code to print information if 'too large' coordinates are being used ... if we define what 'too large' is ;)

Cheers, Joerg

[supertuxkart-sourceforge-migration]

Author: hikerstk Postponed till 0.8, since we had no update, and this is not a release blocker for 0.7.3.

[supertuxkart-sourceforge-migration]

Author: magned Just wanna say I have an assertion in Bullet as well with this track, but this is on 64-bit Arch Linux.

(We can't have fewer segfaults than Windows; that'd make us use a worse OS ;) )

[supertuxkart-sourceforge-migration]

Author: hikerstk No update for over one year, so I'll close this ticket for now. Please reopen if this should still be an issue.