OgreTok - Comments / Questions / Suggestions / Help / etc.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hey all,
For those who are curious I am still hammering away on this, haven't given up at all, so don't worry about that just yet. I haven't done a commit in a few days because I'm having so much trouble with TriMesh support and I really want to get it in place before I move ahead with anything else. I've got a few other things up my sleeve to add before the next time I upload as well. For anyone else here who has used Tokamak, and especially if you've used the TriMesh callback stuff, I would really appreciate you glancing at this thread on the Tokamak forums and seeing if you can spot my problem (the most recent one). I'm using OPCODE now and I feel like I'm so close to getting this right, but something is still busted.
@cTh
Yeah, I thought about doing that, but I want to keep this as generic as possible. Requiring a specific scene manager would make it really application specific, and I'm aiming for plug and play usability at this point. On the flipside, if I get TriMesh support in the way I'm trying to it should be very easy to support an octree implemenation on top of OgreTok (which was always my goal).
About your lag... that is bizzare, I haven't the slightest clue what could be causing that. If anyone else is having this problem I would GREATLY appreciate a report, as I really don't even have the slightest clue where to start. The only thing that makes demos #2 and #4 similar is that they have the most objects of any of the scenes...
Thanks all,
staringmonkey
For those who are curious I am still hammering away on this, haven't given up at all, so don't worry about that just yet. I haven't done a commit in a few days because I'm having so much trouble with TriMesh support and I really want to get it in place before I move ahead with anything else. I've got a few other things up my sleeve to add before the next time I upload as well. For anyone else here who has used Tokamak, and especially if you've used the TriMesh callback stuff, I would really appreciate you glancing at this thread on the Tokamak forums and seeing if you can spot my problem (the most recent one). I'm using OPCODE now and I feel like I'm so close to getting this right, but something is still busted.
@cTh
Yeah, I thought about doing that, but I want to keep this as generic as possible. Requiring a specific scene manager would make it really application specific, and I'm aiming for plug and play usability at this point. On the flipside, if I get TriMesh support in the way I'm trying to it should be very easy to support an octree implemenation on top of OgreTok (which was always my goal).
About your lag... that is bizzare, I haven't the slightest clue what could be causing that. If anyone else is having this problem I would GREATLY appreciate a report, as I really don't even have the slightest clue where to start. The only thing that makes demos #2 and #4 similar is that they have the most objects of any of the scenes...
Thanks all,
staringmonkey
Code: Select all
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (__imp_??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)" (__imp_??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@XZ)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(char const *)" (__imp_??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@PBD@Z)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (__imp_??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (__imp_??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::operator+=(char const *)" (__imp_??Y?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@PBD@Z)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::operator+=(char const *)" (__imp_??Y?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@PBD@Z)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::operator+=(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (__imp_??Y?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@ABV01@@Z)
Demo error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::operator+=(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (__imp_??Y?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@ABV01@@Z)
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Well I solved one more problem with my TriMesh collision, was missing a " + k" in the vertex loop. So now I'm getting some collision, but it's still broken, only a few of the objects collide and they are somewhat erratic. It seems that the data I'm pumping into Tokamak is incorrect somewhere. It's as though the entire mesh is being "compressed" into about 1/4th it's size... I've double checked the values in both Ogre and Opcode and to the best of my understanding the dataset is correct in both places. Not sure what is causing this... I may commit it to the CVS and see if anyone else can spot anything, but I can't connect at the moment and as I understand it sf.net is doing maitanence this weekend. Guess I'll keep staring at it. Wish me luck.
EDIT: Rather than doing a full commit of broken code I'll just toss this up here... on the off chance somebody can spot something.
staringmonkey
EDIT: Rather than doing a full commit of broken code I'll just toss this up here... on the off chance somebody can spot something.
Code: Select all
// _onTriMeshQuery()
void Simulation::_onTriMeshQuery(const neV3& minBound,
const neV3& maxBound,
signed int** candidateTriangles,
neTriangle** triangles,
neV3** vertices,
signed int* candidateCount,
signed int* triangleCount)
{
// Clear all data to start
(*candidateTriangles) = 0;
(*triangles) = 0;
(*vertices) = 0;
(*candidateCount) = 0;
(*triangleCount) = 0;
// User callback triangle collision culling
if(mTriMeshQueryCallback)
{
(*mTriMeshQueryCallback)(minBound,
maxBound,
candidateTriangles,
triangles,
vertices,
candidateCount,
triangleCount);
}
// Internal triangle collision culling
else
{
// If no TriMeshes are being used, exit early
if(mTriMeshCount == 0)
{
return;
}
// Count the total number of collisions that occur
signed int totalCollisionCount = 0;
// Create bounding boxes for Ogre and Opcode
AxisAlignedBox ogreBoundingBox = AxisAlignedBox(neV3_to_Vector3(minBound),
neV3_to_Vector3(maxBound));
CollisionAABB opcodeBoundingBox;
opcodeBoundingBox.SetMinMax(Point(minBound.v[0], minBound.v[1], minBound.v[2]),
Point(maxBound.v[0], maxBound.v[1], maxBound.v[2]));
// Get an iterator for the TriMeshes
TriMeshMap::iterator i;
// Iterate through the TriMeshes
for(i = mTriMeshes.begin(); i != mTriMeshes.end(); i++)
{
// Check for bounding box intersection
if(!i->second->getBoundingBox().intersects(ogreBoundingBox))
{
// No intersection, therefore no collision
continue;
}
// Perform Opcode collision
if(!mOpcodeCollider.Collide(mOpcodeCache, opcodeBoundingBox, i->second->_getOpcodeModel()))
{
// Throw an exception
Except(Exception::ERR_INTERNAL_ERROR, "Opcode TriMesh collision failed.", "Simulation::_onTriMeshQuery()");
}
// Check for collision
if(!mOpcodeCollider.GetContactStatus())
{
// No collision
continue;
}
// Get the collision information
unsigned int numCollisions = mOpcodeCollider.GetNbTouchedPrimitives();
unsigned int* collisionTriangles = (unsigned int*)mOpcodeCollider.GetTouchedPrimitives();
// Allocate enough memory to hold the current triangles
mCollisionTriangleIndices = (signed int*)realloc(mCollisionTriangleIndices, sizeof(signed int) * (totalCollisionCount + numCollisions));
mCollisionTriangles = (neTriangle*)realloc(mCollisionTriangles, sizeof(neTriangle) * (totalCollisionCount + numCollisions));
mCollisionVertices = (neV3*)realloc(mCollisionVertices, sizeof(neV3) * (totalCollisionCount + numCollisions) * 3);
// Get pointers to the TriMesh data
float* triMeshVertices = i->second->getVertices();
unsigned int* triMeshIndices = i->second->getIndices();
// Loop through the triangles that collided
for(unsigned int j = 0; j < numCollisions; j++)
{
// Compute once to save a bit of time
signed int triIndex = totalCollisionCount + j;
// Setup the index
mCollisionTriangleIndices[triIndex] = triIndex;
// Setup the triangle
mCollisionTriangles[triIndex].flag = neTriangle::NE_TRI_TRIANGLE;
mCollisionTriangles[triIndex].materialID = 0;
mCollisionTriangles[triIndex].indices[0] = (triIndex * 3);
mCollisionTriangles[triIndex].indices[1] = (triIndex * 3) + 1;
mCollisionTriangles[triIndex].indices[2] = (triIndex * 3) + 2;
mCollisionTriangles[triIndex].userData = 0;
// Setup the vertices
for(unsigned int k = 0; k < 3; k++)
{
// Compute once to save a bit of time
unsigned int collisionVertIndex = (triIndex * 3) + k;
unsigned int originalVertIndex = triMeshIndices[(collisionTriangles[j] * 3) + k];
// Setup the vertex
mCollisionVertices[collisionVertIndex].v[0] = triMeshVertices[originalVertIndex];
mCollisionVertices[collisionVertIndex].v[1] = triMeshVertices[originalVertIndex + 1];
mCollisionVertices[collisionVertIndex].v[2] = triMeshVertices[originalVertIndex + 2];
//mCollisionVertices[collisionVertIndex].v[3] = 0;
}
}
// Add the number of collision to the total
totalCollisionCount += numCollisions;
}
// Fill in return information
(*candidateTriangles) = mCollisionTriangleIndices;
(*triangles) = mCollisionTriangles;
(*vertices) = mCollisionVertices;
(*candidateCount) = totalCollisionCount;
(*triangleCount) = totalCollisionCount;
}
}
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
I substituted another mesh file that I am using to do testing with in ODE. I only get collisions with the balls in one small area. Do you have to specify anything special when loading a mesh? You have to move up to get above my mesh before testing.
Here is my test replacement: http://www.battleop.net/temp/terrain.mesh
Here is my test replacement: http://www.battleop.net/temp/terrain.mesh
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hey Slicky,
Just want to let you know that I'm not ignoring your post. I'm in the process of overhauling the TriMesh system, so I honestly don't even have a copy of the code your working with (although I could pull one off the CVS). That said, the process for loading a mesh with that version should be in demo #9, just load it with shadow buffers, 12 byte vertices and 2 byte indices. If you can't make it work don't get to troubled, I never had a chance to thoroughly debug that release before I moved on to this system. I've been having a hell of a lot of problems getting this working, but I just now found a clue to whats causing the problems and will hopefully track it down today. Once I get it working with my original TriMesh I will make sure it works with yours before I commit it.
Thanks for the feedback,
staringmonkey
Just want to let you know that I'm not ignoring your post. I'm in the process of overhauling the TriMesh system, so I honestly don't even have a copy of the code your working with (although I could pull one off the CVS). That said, the process for loading a mesh with that version should be in demo #9, just load it with shadow buffers, 12 byte vertices and 2 byte indices. If you can't make it work don't get to troubled, I never had a chance to thoroughly debug that release before I moved on to this system. I've been having a hell of a lot of problems getting this working, but I just now found a clue to whats causing the problems and will hopefully track it down today. Once I get it working with my original TriMesh I will make sure it works with yours before I commit it.
Thanks for the feedback,
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
I AM STARINGMONKEY, HEAR MY PROGRAMMATIC ROAR!
AAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!
The bug from HELL has been quashed and TriMesh support is in. Got a few little things to take care of, but it will be in the CVS tommorow I hope (for shell users anyway). It supports an unlimited number of TriMeshes, has built in culling and is generally quite fast. Damn is that a load off my shoulders!
staringmonkey
AAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!
The bug from HELL has been quashed and TriMesh support is in. Got a few little things to take care of, but it will be in the CVS tommorow I hope (for shell users anyway). It supports an unlimited number of TriMeshes, has built in culling and is generally quite fast. Damn is that a load off my shoulders!
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
I am frustrated with ODE. The "bendy wheel" problem has me stuck. It looks like Tokamak uses sensors so as long as trimesh collision is similar to ODE i'm going to spend time learning Tokamak.
I am guessing there was something with the original trimesh support in your implementation. I tried another mesh and it would record hits with the lower side of a ramp but not the top.
Thanks for all your work on this. I'm curious how the restriction limit of one trimesh has been dealt with. I may be able to avoid having to merge all my meshes into one. I haven't seen a meshmerge tool so I would have had to try and write it.
I am guessing there was something with the original trimesh support in your implementation. I tried another mesh and it would record hits with the lower side of a ramp but not the top.
Thanks for all your work on this. I'm curious how the restriction limit of one trimesh has been dealt with. I may be able to avoid having to merge all my meshes into one. I haven't seen a meshmerge tool so I would have had to try and write it.
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hey all,
I'm having excellent excellent luck today, have cleared up several major issues that were troubling OgreTok. I'm really looking forward to getting this stuff out the proverbial door.
@Slicky
Yeah, ODE can be awfully complicated, but luckily OgreTok is there to save the day. I'm steadily approaching the point where OgreTok will be able to handle complex projects. I'm not 100% sure, but when I checked it appeared that the problem with your TriMesh had to do with the way to it was constructed. I noticed two things right off when I tested it. Firstly, your mesh had visible seams on my screen, so an object could certainly penetrate there. Secondly, and more importantly the triangles constructing your mesh appeared to be HUGE (at least in relation to my objects). I'm not sure how big the objects your using are, but generally you need to avoid very large triangles as it's possible (read: probable) that collisions will be missed with them.
The way I chose to support multiple TriMeshes was to skip merging entirely. I'm utilizing the TriMesh callback to provide Tokamak with the triangles it needs each frame. So you don't need to merge your meshes, in fact, you won't want to, because OgreTok's internal culling checks against each individual meshes bounding box. Lemme explain in more detail. OgreTok's TriMesh implementation is a three-step process. Pseudo-code:
Each frame
-- For each dynamic object (rigid body)
----- For each static TriMesh
-------- 1) Perform a AABB to AABB check between the dynamic object and the TriMesh. (OgreTok)
-------- 2) Perform a AABB to Triangle check between the dynamic object and the TriMesh to determine potentially colliding triangles. (Opcode)
-------- 3) Perform a Box/Sphere/Cylinder to Triangle check between the dynamic object and all potentially colliding triangles. (Tokamak)
----- Next
-- Next
End
This is a fairly fast process, especially if your world/level is well subdivided. Now, to address your question of whether or not the generic scenemanager is enough for your project, that really is going to depend on the nature of the project. If your project's environment is made up of a lot of small-medium size meshes, then yes, the generic scene manager should work fine. On the other hand, if your world is primarily one, or several, large pieces of terrain (e.g. any fps) then your going to want to customize OgreTok to handle that in whatever way you think is best. Unfortunantly at this point you wouldn't be able to use the data directly from your Octree/BSP-tree with OgreTok, because you need to subdivide it into smaller meshes to load with OgreTok (as opposed to one big chunk of world geometry). And since the TriMesh class only loads from a mesh name at this point (rather than from raw data or anything like that) there is no way to do this without alterating OgreTok (or creating your own TriMesh callback), which I encourage.
OgreTok is never going to be an all-purpose solution for everyone's needs, but at this point it is nicely generic and everyone should be able to alter it to meet there own needs in short order. I may at some point add a way to create a TriMesh with raw data, which would make it easier to subdivide an Octree or BSP-tree's mesh data into OgreTok-friendly units (2000-3000 tris would likely be a good size). For most games you probably WILL want to use an Octree with OgreTok, but I'm not going to do the implementation of that (except maybe as an example), as every project will want to handle it differently.
Wow, I really rambled there, I hope I managed to answer some of your questions.
@Guest
Fancy name: Memory alignment
The Hard Truth:
should have been
Almost a week it took me to find that stupid mistake.
Later,
staringmonkey
I'm having excellent excellent luck today, have cleared up several major issues that were troubling OgreTok. I'm really looking forward to getting this stuff out the proverbial door.
@Slicky
Yeah, ODE can be awfully complicated, but luckily OgreTok is there to save the day. I'm steadily approaching the point where OgreTok will be able to handle complex projects. I'm not 100% sure, but when I checked it appeared that the problem with your TriMesh had to do with the way to it was constructed. I noticed two things right off when I tested it. Firstly, your mesh had visible seams on my screen, so an object could certainly penetrate there. Secondly, and more importantly the triangles constructing your mesh appeared to be HUGE (at least in relation to my objects). I'm not sure how big the objects your using are, but generally you need to avoid very large triangles as it's possible (read: probable) that collisions will be missed with them.
The way I chose to support multiple TriMeshes was to skip merging entirely. I'm utilizing the TriMesh callback to provide Tokamak with the triangles it needs each frame. So you don't need to merge your meshes, in fact, you won't want to, because OgreTok's internal culling checks against each individual meshes bounding box. Lemme explain in more detail. OgreTok's TriMesh implementation is a three-step process. Pseudo-code:
Each frame
-- For each dynamic object (rigid body)
----- For each static TriMesh
-------- 1) Perform a AABB to AABB check between the dynamic object and the TriMesh. (OgreTok)
-------- 2) Perform a AABB to Triangle check between the dynamic object and the TriMesh to determine potentially colliding triangles. (Opcode)
-------- 3) Perform a Box/Sphere/Cylinder to Triangle check between the dynamic object and all potentially colliding triangles. (Tokamak)
----- Next
-- Next
End
This is a fairly fast process, especially if your world/level is well subdivided. Now, to address your question of whether or not the generic scenemanager is enough for your project, that really is going to depend on the nature of the project. If your project's environment is made up of a lot of small-medium size meshes, then yes, the generic scene manager should work fine. On the other hand, if your world is primarily one, or several, large pieces of terrain (e.g. any fps) then your going to want to customize OgreTok to handle that in whatever way you think is best. Unfortunantly at this point you wouldn't be able to use the data directly from your Octree/BSP-tree with OgreTok, because you need to subdivide it into smaller meshes to load with OgreTok (as opposed to one big chunk of world geometry). And since the TriMesh class only loads from a mesh name at this point (rather than from raw data or anything like that) there is no way to do this without alterating OgreTok (or creating your own TriMesh callback), which I encourage.
OgreTok is never going to be an all-purpose solution for everyone's needs, but at this point it is nicely generic and everyone should be able to alter it to meet there own needs in short order. I may at some point add a way to create a TriMesh with raw data, which would make it easier to subdivide an Octree or BSP-tree's mesh data into OgreTok-friendly units (2000-3000 tris would likely be a good size). For most games you probably WILL want to use an Octree with OgreTok, but I'm not going to do the implementation of that (except maybe as an example), as every project will want to handle it differently.
Wow, I really rambled there, I hope I managed to answer some of your questions.
@Guest
Fancy name: Memory alignment
The Hard Truth:
Code: Select all
unsigned int originalVertIndex = triMeshIndices[(collisionTriangles[j] * 3) + k];
Code: Select all
unsigned int originalVertIndex = triMeshIndices[(collisionTriangles[j] * 3) + k] * 3;
Later,
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
Yep there were some visible seams in the trough and yep some triangles were big. I wasn't talking about going through a seam and ODE didn't have a problem with the large triangles. It's funny everything I need works well in ODE except for one thingI noticed two things right off when I tested it. Firstly, your mesh had visible seams on my screen, so an object could certainly penetrate there. Secondly, and more importantly the triangles constructing your mesh appeared to be HUGE
I'm looking forward to giving the updated cvs a spin.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Ok, for those of you who have access to the secure CVS, the new version is up (despite a VERY slow CVS update). I debated whether or not to upload today, as I have a fairly long list of small things I want to take care of, each of which won't take more than 45 minutes. But still, ten 45 minute projects would have taken me a couple more days and I want to see what kind of reaction I get to this release. Once I get these last few minor features in and get sensors in place I'll likely be ready for a mythical "1.0" release. I'll probably write up a fancy demo for that or something. Anyway, it's got handy-dandy uber-fancy TriMesh support, so give it a spin, demo #9 is the one you want to look at.
@Slicky
Hmmm, I'm not sure if that makes ODE more resilient or more lax.
staringmonkey
PS: This release is certainly not guaranteed to be bug free, I haven't really made an effort to test every little feature, I'm trying to get all these little things in place first.
@Slicky
Hmmm, I'm not sure if that makes ODE more resilient or more lax.
staringmonkey
PS: This release is certainly not guaranteed to be bug free, I haven't really made an effort to test every little feature, I'm trying to get all these little things in place first.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Just committed a fix for several TriMesh problems (I dunno if the first commit has even made it to public CVS yet ). This little update also has a nice framerate boost that comes from exiting the collision callback early if it's not needed. But the big nicety added here is the ability to create a TriMesh using VertexData and IndexData instead of a mesh, this opens the door for very easy integration with a terrain engine, or possibly even BSP or Octree. In particular I was looking at David's fantastic displacement mapping terrain engine and it wouldn't take much to add OgreTok physics to it (although I'm not positive how I would deal with the LOD at this point).
Note that even though the feature is in there, it's not really documented just yet. I'm going to go through and thoroughly document all Simulation function parameters here soon (it's on the TODO list). Once that is done the whole thing is going to become much more explanatory.
@Slicky
I think I know what the problem with your mesh was. Since you had gaps in your mesh I'm going to assume it was imported as multiple SubMeshes. OgreTok doesn't support multiple SubMeshes just yet, but it will very soon. 90% sure that's why you had problems.
EDIT: Just committed support for TriMeshes with any number of SubMeshes and with variably sized vertex/index buffers. That should solve your problem Slicky, and now that was really the last hurdle for integration with a terrain engine, so that should be a walk in the park now.
Later,
staringmonkey
Note that even though the feature is in there, it's not really documented just yet. I'm going to go through and thoroughly document all Simulation function parameters here soon (it's on the TODO list). Once that is done the whole thing is going to become much more explanatory.
@Slicky
I think I know what the problem with your mesh was. Since you had gaps in your mesh I'm going to assume it was imported as multiple SubMeshes. OgreTok doesn't support multiple SubMeshes just yet, but it will very soon. 90% sure that's why you had problems.
EDIT: Just committed support for TriMeshes with any number of SubMeshes and with variably sized vertex/index buffers. That should solve your problem Slicky, and now that was really the last hurdle for integration with a terrain engine, so that should be a walk in the park now.
Later,
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
Actually I just replaced the terrain in the example #9 with the mesh file that I created. Anyway, I know at least with ODE there is tweaking for some elements.I think I know what the problem with your mesh was. Since you had gaps in your mesh I'm going to assume it was imported as multiple SubMeshes. OgreTok doesn't support multiple SubMeshes just yet, but it will very soon. 90% sure that's why you had problems.
Appreciate all your efforts. I didn't have a chance to check cvs yet. I'm guessing it is lagged as usual anyway. One of my first tests will be to drop that mesh in as a replacement and see if it works better than before.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Actually, that's not was I was talking about. I'm was talking about how you created the mesh. (I mean imported in terms of Ogre's internals, not your code.) Since their were seams in the mesh I assumed that each side was probably exported from your modeller as a seperate SubMesh, and in the original version I wasn't taking multiple SubMeshes into account (I was just loading SubMesh 0).Slicky wrote: Actually I just replaced the terrain in the example #9 with the mesh file that I created. Anyway, I know at least with ODE there is tweaking for some elements.
But, after giving your mesh a spin with the new code, it still only sort of works... According to my log it is divided into two SubMeshes with 677 vertices and 3405 indices. I'm getting some very odd collision glitches. I'm also seeing some very strange lines in places on your mesh. At this point I'm reluctant to debug this any further with a mesh with so many obvious defects. I guess all I can tell you is that my test meshes have all worked 100%, including multiple terrain meshes, the Ogrehead model (with 4 SubMeshes), and a simple character models. ODE may run it... but I'm some level I'm glad OgreTok is having problems with it. Hopefully that doesn't sound assinine, but I'd highly recommend cleaning up your mesh before you go any further, I can't imagine your results are going to be 100% predictable as long as your using that mesh.
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hey everyone,
I just wanted to let people know that OgreTok is, at least temporarily, complete. I've added all the features that I feel I need for my projects, and have decided not to bother with sensors, controllers, and other Tokamak features with (in my opinion) very limited usage. I'll continue to add stuff and fix bugs as I find it necessary, but I don't see any reason to work on this "full time" any longer, especially since there doesn't seem to be too much interest in it. I'm not bitching, not really anyway. If anyone comes up with any ways to improve it I'll be more than happy to maintain the release, I just don't plan on actively developing it on a day to day basis any longer. Thanks to those that have tested it, and I hope somebody gets some use out of it.
Cheers,
Once Upon a Time There Was a Monkey. He Stared. The End.
EDIT: 100th post? Coincidence? I think it not.
I just wanted to let people know that OgreTok is, at least temporarily, complete. I've added all the features that I feel I need for my projects, and have decided not to bother with sensors, controllers, and other Tokamak features with (in my opinion) very limited usage. I'll continue to add stuff and fix bugs as I find it necessary, but I don't see any reason to work on this "full time" any longer, especially since there doesn't seem to be too much interest in it. I'm not bitching, not really anyway. If anyone comes up with any ways to improve it I'll be more than happy to maintain the release, I just don't plan on actively developing it on a day to day basis any longer. Thanks to those that have tested it, and I hope somebody gets some use out of it.
Cheers,
Once Upon a Time There Was a Monkey. He Stared. The End.
EDIT: 100th post? Coincidence? I think it not.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
Got this on a fresh checkout from cvs.OgreTokSimulation.cpp(174) : error C2664: 'SetTerrainTriangleQueryCallback' : cannot convert parameter 1 from 'void (const struct neV3 &,const struct neV3 &,int ** ,class neTriangle ** ,struct
neV3 ** ,int *,int *)' to 'void (__cdecl *)(const struct neV3 &,const struct neV3 &,int ** ,class neTriangle ** ,struct neV3 ** ,int *,int *,class neRigidBody *)'
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Well... this is truly beyond bizzare... at first I thought you had an older version of Tokamak's SDK. I went to their webisite and, mostly on a whim, redownloaded version 1.10 for myself. To my surprise I have an old version of the SDK, which is quite strange because I already had 1.10. So... I now have two versions of Tokamak 1.10, with different function prototypes for the Tri callback, that's just strange. It would appear that somebody decided it was easier to just replace the zip than document a new version. I'll see about getting a fix committed.
staringmonkey
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
I just changed while you were posting i guess
Code: Select all
inline void OgreTok_TriMeshQueryCallback(const neV3& minBound,
const neV3& maxBound,
signed int** candidateTriangles,
neTriangle** triangles,
neV3** vertices,
signed int* candidateCount,
signed int* triangleCount,
neRigidBody * body)