OgreTok - Comments / Questions / Suggestions / Help / etc.

Anything and everything that's related to OGRE or the wider graphics field that doesn't fit into the other forums.
Locked
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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
Guest

Post by Guest »

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)
i get these errors when compiling demo :( ive done a full reinstall and recompile of ogre, then another download of tokamak (out of desperation), still no luck. using .net2003
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

Hmmm... there were some other people having problems compiling with .Net (which I don't have). Did anyone get it figured out? At first glance it appears to be STL related...

staringmonkey
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

That looks like setting the C++ code generation to something other than 'Multithreaded [Debug] Dll'
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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.

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;
		}
	}
staringmonkey
Guest

Post by Guest »

sinbad wrote:That looks like setting the C++ code generation to something other than 'Multithreaded [Debug] Dll'
when demo is set to single threaded debug dll, it gives me a ton of errors. fixing it cuts down on them, but those stl errors are still there
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by Slicky »

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
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

I AM STARINGMONKEY, HEAR MY PROGRAMMATIC ROAR!
:twisted: AAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!! :twisted:

The bug from HELL has been quashed and TriMesh support is in. 8) 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
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by Slicky »

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.
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by Slicky »

Oh, one more thing. Since I am still learning OGRE but getting better does built in culling mean that a generic scene manager would be sufficient? I had been using the octree manager by Proton which seemed to work well.
Guest

Post by Guest »

just curious... what was the bug? I looked at the code and didn't see it.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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. :P 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. :P

@Guest

Fancy name: Memory alignment
The Hard Truth:

Code: Select all

unsigned int originalVertIndex = triMeshIndices[(collisionTriangles[j] * 3) + k];
should have been

Code: Select all

unsigned int originalVertIndex = triMeshIndices[(collisionTriangles[j] * 3) + k] * 3;
Almost a week it took me to find that stupid mistake. :P

Later,
staringmonkey
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by Slicky »

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
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 thing :wink:

I'm looking forward to giving the updated cvs a spin.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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. :P

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. :)
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

Just committed a fix for several TriMesh problems (I dunno if the first commit has even made it to public CVS yet :P). 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). :D

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
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by 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.
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.

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.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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.
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).

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. :P 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
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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. :P 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. :P
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by Slicky »

I'll still report back how it goes. I've been sidetracked setting up Vis Studio 2003 but not sure I want to depart from my tweaked and loyal Vis Studio 6.
Mickael
Gnoblar
Posts: 13
Joined: Thu Jan 22, 2004 12:41 pm
Location: France,grenoble

Post by Mickael »

so,ode or tokamak ?
Mickael
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

I'm afraid I don't understand the question Mickael. You might want to put it in some sort of context. :P

staringmonkey
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by Slicky »

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 *)'
Got this on a fresh checkout from cvs.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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
Slicky
Bronze Sponsor
Bronze Sponsor
Posts: 614
Joined: Mon Apr 14, 2003 11:48 pm
Location: Was LA now France
x 25

Post by Slicky »

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)
Locked