importer and btConvexHullShape

[jotarun]

I've been testing the importer these days.
In the tutorial, the imported mesh is stored in GLInstanceGraphicsShape
then, the following code is used to create convexhull from the mesh.
const GLInstanceVertex& v = gfxShape->m_vertices->at(0); btConvexHullShape* shape = new btConvexHullShape((const btScalar*)(&(v.xyzw[0])), gfxShape->m_numvertices, sizeof(GLInstanceVertex));
However, I find out that many imported files failed to create a proper convex hull.
That is , the object is not interacting with the world.
For instance, the "teddy.obj" in the tutorial doesn't work, but "sphere8.obj' works.

And even when if works, the AABB seems strange too.

Is this an issue of the importer (but the shape seems ok visually) or btConvexHullShape?

[erwincoumans]

What tutorial? Please provide complete instructions how to build and reproduce your issue (including operating system, compiler, build system (premake, cmake), build system flags (double precision, 32/64 bit etc) etc etc.

When using pybullet, the easiest way to use Bullet, those files all work just fine.

[jotarun]

@erwincoumans
I'm following the tutorial here http://bulletphysics.org/mediawiki-1.5.8/index.php/Simple_RigidBody_loaded_from_an_obj_file
I also tried the stl importer and get a similar result.

Operating System: Windows 7
Compiler: Visual Studio 2015
build system: build_visual_studio.bat

[jotarun]

Since you mentioned its fine in pybullet, I delete the source and rebuild everything.
It's fine now.
But I still wonder what cause that issue.

[benelot]

Not sure if this should be closed just because your problem is fixed. It seems that with your former setup, one could break something. Can you post your reproduction code here?

[benelot]

Then, if somebody finds this when similar problems occur , s/he can investigate more and maybe contribute to resolving the potential error.

[jotarun]

@benelot the code is the original RigidBodyFromObjExample in the ExampleBrowser.
In bullet forum, it is reproduced by building with 64-bit mode.
But I build it with 64bit also and cant reproduce the bug again.
As you suggested, I'll reopen the issue and maybe someone can figure this out :)

[srajangarg]

@benelot am facing this issue. Even on multiple rebuilds.

Compiler : gcc 5.4.0
OS : Ubuntu 16.04 (64 bit machine)
Build system : cmake with default flags

Seems to be an issue while reading the .obj file itself as the output reads
[INFO] Obj loaded: Extracted 9576 vertices from obj file [teddy.obj]
but the file itself contains only 1598 vertices. Any help would be greatly appreciated.

[srajangarg]

@erwincoumans after skimming through some code, I found

bullet3/examples/Importers/ImportObjDemo/Wavefront2GLInstanceGraphicsShape.cpp

Line 26 in 6e4707d

for (int f=0;f<faceCount;f+=3)

bullet3/examples/Importers/ImportObjDemo/Wavefront2GLInstanceGraphicsShape.cpp

Lines 174 to 176 in 6e4707d

	vertices->push_back(vtx0);
	vertices->push_back(vtx1);
	vertices->push_back(vtx2);

This seems to be adding vertices to an array, over all faces of a shape. This leads to possible duplicates in this case, where a vertex which is shared by many different faces will be added multiple times to this vector. I think this is not the intended structure?

[erwincoumans]

We use the same indices for vertex positions, normals and uv coordinates, so the combination has to be unique. Since we don't know if the indices point to the same vertex (pos, normal, uv) we duplicate all vertices to make sure they are unique. If you are sure the combination (vertex position/normal) can be shared, the code can be optimized.