Ah ok. I see that the "adjacency.cpp" tool, does indeed contain information on what is stored in the binary tokamak format, however I am not sure if tokamak uses all of this information? Would it be possible to have a stripped-down function that just accepts as its inputs the data that is actually needed by Tokamak for the convex collision detection?
I would like to be able to generate the mesh information without having to use an external tool, and I was planning on generating the hull via Stan Melax’s convex hull generator.
I have tried to load a convex object from the QHull data, but my program crashes as soon as the convex object collides with something.
This is how I load the object:
FILE *fb = fopen("divtop.bin","rb");
data = new BYTE[1188];
fread(data,sizeof(BYTE),1188,fb);
fclose(fb);
ptcg->TokamakInitQHull(m,data);
Where TokamakInitQHull does essentially this:
m_ptokGeom = ptb->m_ptokBody->AddGeometry();
m_ptokGeom->SetConvexMesh(data);
If you would be able to post the sample code that would be great.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Adrian,
I believe tokamak convex objects are implemented through the use of a preprocessing tool called adjacency.exe.
This tool runs qhull on the point cloud you supply as vertices in a text file, one vertex x y z per line, and spits out a file with the face, vertex and edge information in a binary format.
This binary blob is then loaded at runtime, parsed to fix up the internal pointers, and supplied to the engine, via the SetConvexMesh method on the neGeometry.
The current limitation that I know of is that none of the counts for faces vert and edges can exceed 255 since they are output as a neByte by the adjacency.exe. According to Chris (tokamaks author) , fixing this is just a matter of recompiling the adjacency tool and updating the runtime parsing code. I am planning on trying this locally soon.
Hope this helps, feel free to contact me with any other questions you might have.
-MikeS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply, I can see now from the adjacency.cpp what inputs Tokamak requires. I was planning on using StanHull as a simple way to generate the convex mesh, but I guess using Qhull to generate the mesh and pass it directly to Tokamak would be more appropriate.
Have you looked in to passing the qhull data directly to Tokamak?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Adrian,
If I read you right, you want to be able to generate the hulls at runtime based on some supplied geometry...
My current approach for this is to write my desired mesh data out to a .txt file in the format that adjacency wants, (x y z\r\n i think) and then programmatically call adjacency with the system() call in the c runtime lib. Adjacency then spits out my data and I load it, preprocess it, and pass it to tokamak with the SetConvexMesh call. I know this sounds somewhat roundabout, but for my purposes it should work.
Alternatively, you could link in the qhull libraries or stanhull or stanhull source yourself, and include adjacency.cpp in your app, or some variant of it, and avoid the intermediate disk stage for the mesh data.
Another obvious benefit of that approach would be the possibility of doing realtime broken object tesselation a la crysis. :) Good luck, feel free message me if you have more questions,
-MikeS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, thats correct, I am trying to generate the hull now using qhull inetrnally, however my program currently crashes when the convex object collides with something else.
I'm setting up the convex body like all others, except with SetConvexMesh instead of something else..
Adrian,
You are loading the data correctly but it must go through a post processing step to fix up the pointers in the data.
You need to check out the samplebase.cpp source file from the demos, in demo_source/samples/samplebase.cpp.
You probably want to start by using that or replicate what its doing.
Its basically fixing up the pointers that are contained in the convex object blob loaded from disk.
Once the data is fixed up, it *should* work, provided also your convex data doesn't exceed the current 255 verts/edges/triangles limitation.
Hope this helps!
-MikeS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm just wondering how to use convex objects with Tokamak?
(ie: what is the input format?)
Is this the format in which Tokamak expects the data:
typedef struct {
neV3 normal;
f32 k;
} tokFace;
typedef struct {
s32 numFace;
s32 numVerts;
tokFace* faces; //array instead of pointer
neV3* verts; //array instead of pointer
} tokConvex;
except that it expects an array as opposed to a pointer?
Is there a Tokamak function for accepting a convex object described as just verticies & indicies? Or just accepting a vertex cloud?
Thanks!
Tokamak's convex support is not very well tested. So expect some bugs.
I will have to dig up the code on this and get back to you, but one of sample does have the format to Tokamak needs to read.
Ah ok. I see that the "adjacency.cpp" tool, does indeed contain information on what is stored in the binary tokamak format, however I am not sure if tokamak uses all of this information? Would it be possible to have a stripped-down function that just accepts as its inputs the data that is actually needed by Tokamak for the convex collision detection?
I would like to be able to generate the mesh information without having to use an external tool, and I was planning on generating the hull via Stan Melax’s convex hull generator.
(John Ratcliff has written an easy to use wrapper class here:
http://www.amillionpixels.us/sourcecode.htm\)
I have tried to load a convex object from the QHull data, but my program crashes as soon as the convex object collides with something.
This is how I load the object:
FILE *fb = fopen("divtop.bin","rb");
data = new BYTE[1188];
fread(data,sizeof(BYTE),1188,fb);
fclose(fb);
ptcg->TokamakInitQHull(m,data);
Where TokamakInitQHull does essentially this:
m_ptokGeom = ptb->m_ptokBody->AddGeometry();
m_ptokGeom->SetConvexMesh(data);
If you would be able to post the sample code that would be great.
Thanks!
I found the sample programs, now it all works. Thanks.
http://www.tokamakphysics.com/download/tokamak_sample_1_2.zip
Hi Adrian,
I believe tokamak convex objects are implemented through the use of a preprocessing tool called adjacency.exe.
This tool runs qhull on the point cloud you supply as vertices in a text file, one vertex x y z per line, and spits out a file with the face, vertex and edge information in a binary format.
This binary blob is then loaded at runtime, parsed to fix up the internal pointers, and supplied to the engine, via the SetConvexMesh method on the neGeometry.
The current limitation that I know of is that none of the counts for faces vert and edges can exceed 255 since they are output as a neByte by the adjacency.exe. According to Chris (tokamaks author) , fixing this is just a matter of recompiling the adjacency tool and updating the runtime parsing code. I am planning on trying this locally soon.
Hope this helps, feel free to contact me with any other questions you might have.
-MikeS.
Sorry I referrred to Chris as tokamaks author, i picked his name up from the old forums, David Lam being the actual author of Tokamak :D, Sorry David.
Hi Mike,
Thanks for your reply, I can see now from the adjacency.cpp what inputs Tokamak requires. I was planning on using StanHull as a simple way to generate the convex mesh, but I guess using Qhull to generate the mesh and pass it directly to Tokamak would be more appropriate.
Have you looked in to passing the qhull data directly to Tokamak?
Hi Adrian,
If I read you right, you want to be able to generate the hulls at runtime based on some supplied geometry...
My current approach for this is to write my desired mesh data out to a .txt file in the format that adjacency wants, (x y z\r\n i think) and then programmatically call adjacency with the system() call in the c runtime lib. Adjacency then spits out my data and I load it, preprocess it, and pass it to tokamak with the SetConvexMesh call. I know this sounds somewhat roundabout, but for my purposes it should work.
Alternatively, you could link in the qhull libraries or stanhull or stanhull source yourself, and include adjacency.cpp in your app, or some variant of it, and avoid the intermediate disk stage for the mesh data.
Another obvious benefit of that approach would be the possibility of doing realtime broken object tesselation a la crysis. :) Good luck, feel free message me if you have more questions,
-MikeS.
Hi Mike,
Yes, thats correct, I am trying to generate the hull now using qhull inetrnally, however my program currently crashes when the convex object collides with something else.
I'm setting up the convex body like all others, except with SetConvexMesh instead of something else..
m_ptokGeom = ptb->m_ptokBody->AddGeometry();
m_ptokGeom->SetConvexMesh(data);
and at the moment, data is just:
BYTE *data;
FILE *fb = fopen("divtop.bin","rb");
data = new BYTE[1188];
fread(data,sizeof(BYTE),1188,fb);
fclose(fb);
Are you having any trouble with convex mesh collisions? Would you know what I am doing wrong?
(It crashes at:
dcd.cpp, line 417:
neighbourEdge = mesh.verts[ret].neighbourEdges[i];
called from
Box2ConvexTest
TestDCD
SearchFV
TestFace
neByte _indexB = objB.GetSupportPoint(face0.normal);
return GetSupportPointMesh(norm);
But it would appear that my convexA has a corrupt verticies pointer.. am I reading the data in wrong?
Adrian,
You are loading the data correctly but it must go through a post processing step to fix up the pointers in the data.
You need to check out the samplebase.cpp source file from the demos, in demo_source/samples/samplebase.cpp.
The last function in the file is:
bool ReadConvexData(char * filename, neByte *& adjacency)
You probably want to start by using that or replicate what its doing.
Its basically fixing up the pointers that are contained in the convex object blob loaded from disk.
Once the data is fixed up, it *should* work, provided also your convex data doesn't exceed the current 255 verts/edges/triangles limitation.
Hope this helps!
-MikeS.
Ah! Thanks for this, I didn't realise the demos have been updated here:
http://www.tokamakphysics.com/demo/tokamakdemo.zip
So now I got it all working. Thanks!