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 » Sat Apr 24, 2004 5:06 am

That's great to hear Beau! It's really nice to hear that the work I put into that payed off. It was entirely conceptual at the time I wrote it (purpose-wise I mean) and I never had the opportunity to put the code to a worthwhile demonstration. So I'm glad to that you've made use of it! Best of luck on your project, let me know how it goes. :)

staringmonkey
0 x

segfault
Gnoblar
Posts: 23
Joined: Tue Feb 10, 2004 5:36 pm

Post by segfault » Tue Apr 27, 2004 2:57 pm

hello,
I have some probleme to use motor and fiction.
I have read that friction coef is between 0 to 1 but i have to put minimun 4 to have friction.
For the motor it's more radical, when i call setMotor (i did a method that call the tokamak method) and enableMotor it does not make anythings. I have put an hinge joint in the center of an capsule link to the capsule and a end of a box and the same things at the other side.
When i apply velocity to the box capsules doesnt rotate around the hinge.
(i can post the code)

By the way i made the things of the coef that i explane before and it's working (i hope that's not my probleme) i can use a rate of 60 without the moving sand effect :)
0 x

segfault
Gnoblar
Posts: 23
Joined: Tue Feb 10, 2004 5:36 pm

Post by segfault » Tue Apr 27, 2004 4:33 pm

i made some test and it appere tu be he add of my coef that cause the probleme... someone have an idea what could cause that ?

//edit
so i have found why there was a friction probleme and now i have my coef things working ... :)
but i can't find a way to make work setMotor and enableMotor i must have miss something.
0 x

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Tue Apr 27, 2004 9:28 pm

Hey segfault,

To be honest, I've never used the motor things myself. Even when using "pure" Tokamak (not OgreTok) I was never able to make them function properly. The code that's in OgreTok is purely pass-through, so whatever the trick to making them work is, it would be the same for Tokamak. In other words, I'm fairly sure I didn't break it. ;):P A rather unproductive answer, I know, but that's about all I can tell you on the subject. You might check the Tokamak forums for info on motor joints.

staringmonkey
0 x

User avatar
tenkei
Kobold
Posts: 27
Joined: Mon Mar 01, 2004 5:48 pm
Location: Paris, France
Contact:

Post by tenkei » Wed Apr 28, 2004 1:06 pm

Hi Staringmonkey, sramsby, Beau.

I'm facing a similar problem as what you talked about (generating a collision geometry from a .scene with the dotsceneoctree plugin).

I'm rather confused as to where to start doing this.
Do I have to modify the dotsceneoctree plugin? Or can I keep it confined to my own code?

It seems I'd have to modify dotsceneoctree, if only because it doesn't have accessors to either its VertexData * or its IndexData * built in.

Other than that, in order to keep the trimesh in sync with octree, would I have to regenerate it in my framelistener's frameStarted() method? Or am I misunderstanding something?

I'm a little confused about how this whole thing works, so a little clarification would be nice :)

Also, my scene (map) is a rather large outdoors urban area. Is this the "right" way to manage collisions for this, or is there something better?

Thanks guys :)
0 x
tenkei | overdrive

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Wed Apr 28, 2004 4:05 pm

Hey,

Sramsby or Beau might be able to better answer this since they've actually implemented it, but I believe you should be able to get the necessary information from the SceneOctree class, using the follow functions

Code: Select all

	float* GetVerticesPtr( int MeshIndex );
	int*  GetIndexPtr( int MeshIndex );
	int GetNumVertices( int MeshIndex );
	int GetNumIndex( int MeshIndex );
That should provide you with the vertex/index information for each octet.

As for whether or not this is the correct way to do it, that's sort of a divisive question. :P I remain somewhat split over whether I can really recommend OgreTok, as development on Tokamak has stopped, while numerous bugs still exist. I personally would not use it on my own project (although I'm quite proud of it :P), but it seems that quite a few people are still using it for their projects. So I gather it depends on the type of project and people. As for using it for a "large outdoors urban area", I would say it's pretty much ideal for that, providing you don't hit any of hte aforementioned bugs.

That's the short answer to the question, if you want the long answer you can read back through this thread for a long, detailed history of the troubled childhood of OgreTok. :P

HTH,
staringmonkey
0 x

User avatar
tenkei
Kobold
Posts: 27
Joined: Mon Mar 01, 2004 5:48 pm
Location: Paris, France
Contact:

Post by tenkei » Wed Apr 28, 2004 4:30 pm

Thanks Staringmonkey.

What I have trouble understanding is how exactly does the logic behind this concept of having a trimes that works with the octree.

I understand (please correct me if I'm wrong) that you're supposed to generate a trimesh from your scene's geometry, then subdivide the trimesh according to the octree and only "activate" the appropriate part of it. Am I following so far?

But how exactly do I subdivide it?
Do I have to recreate the "active" trimesh each frame using the vertices from SceneOctree and delete the unused trimesh? Wouldn't that be horribly resources-consuming?

Or am I completely misunderstanding something?

[edit]
Also, how do I build the VertexData* and IndexData* needed by Simulation::createTriMesh() from the functions you mentioned? They return float*s, and the VertexData class doesn't seem to have any appropriate constructors or methods to handle that...
[/edit]
0 x
tenkei | overdrive

sramsby
Gnoblar
Posts: 2
Joined: Thu Apr 01, 2004 6:48 am

Post by sramsby » Wed Apr 28, 2004 10:24 pm

We just iterated through all the Octree chunks that DotScene generated and created OgreTok trimeshes for all of them to get the collisions going.

Code: Select all

	int totalMeshes = m_pDotSceneMgr->GetNumMeshes(NULL);

	for (int CurMesh = 0; CurMesh < totalMeshes; CurMesh++)
	{ 
		TriMesh* pTrimesh_debug = Simulation::getSingleton().createTriMesh(
			"Terrain" + StringConverter::toString(CurMesh), 
			String::BLANK, "TestLevel.material", 
			Vector3(0.0f, 0.0f, 0.0f), Quaternion::IDENTITY, 
			String::BLANK, m_pDotSceneMgr->GetVertexDataPtr(NULL, CurMesh), m_pDotSceneMgr->GetIndexDataPtr(NULL, CurMesh)); 
	}
You could dynamically activate/deactivate them if you want, but the divisions that exist in the Octree should reduce the number of collision checks you have to do already. This kind of thing should get you going.

We still have a problem though that the DotScene isn't displaying visually in debug mode, even though the Trimesh collisions for it still work. If anyone has any ideas on this we'd love to hear them, as the DotScene author seems to not have time to be working on this right now.
0 x
-Scott

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Wed Apr 28, 2004 11:47 pm

Hey,

Well I would say Sramsby pretty well hit it square on the head, but I'll expand a bit where I can.
tenkei wrote: What I have trouble understanding is how exactly does the logic behind this concept of having a trimes that works with the octree.
Well the basic idea is that since the Octree pre-divides the mesh, you can use those divisions to cull potential collisions, thus vastly reducing the number of per-poly collision checks.
tenkei wrote: I understand (please correct me if I'm wrong) that you're supposed to generate a trimesh from your scene's geometry, then subdivide the trimesh according to the octree and only "activate" the appropriate part of it. Am I following so far?
You shouldn't ever really have to deal with active/inactive TriMeshes, unless your dealing with a very large map and you want to "page" in and out the colliding sections. For the moment the OgreTok only takes advantage of the Octree at the "highest" level, that is doing a bounding-box check against each component. If your project is very speed critical it would be much more effective to simply build the Octree into OgreTok, thus further refining the collision culling. I chose not to do this and leave it open to user-defined methods of culling, rather than forcing an Octree on them.
tenkei wrote: But how exactly do I subdivide it?
The Octree generator has already done it.
tenkei wrote: Do I have to recreate the "active" trimesh each frame using the vertices from SceneOctree and delete the unused trimesh? Wouldn't that be horribly resources-consuming?
You only have to create it once, unless your terrain is dynamic, something which OgreTok won't handle well at all. (No point in even trying it.)
tenkei wrote: Or am I completely misunderstanding something?
I hope Sramsby and I cleared it up. :)

HTH,
staringmonkey
0 x

User avatar
tenkei
Kobold
Posts: 27
Joined: Mon Mar 01, 2004 5:48 pm
Location: Paris, France
Contact:

Post by tenkei » Thu Apr 29, 2004 12:23 pm

Thanks a ton, Sramsby and Staringmonkey. You guys spared me a LOT of headache.
0 x
tenkei | overdrive

RiX
Gnoblar
Posts: 2
Joined: Sun Apr 11, 2004 1:07 pm

Post by RiX » Thu Apr 29, 2004 1:33 pm

Im trying to compile the ogretokamak demo but i get this error:

Compiling...
OgreTokObject.cpp
C:\ogreaddons\ogretokamak\OgreTok\src\OgreTokObject.cpp(449) : error C2039: 'setCastShadows' : is not a member of 'Entity'
C:\ogrenew\ogremain\include\ogreentity.h(70) : see declaration of 'Entity'
Error executing cl.exe.


plz help me i'm so close :(

EDIT: ok this is prolly cus i have the stable rls 0.13.1 ?
0 x

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Thu Apr 29, 2004 3:54 pm

RiX wrote: EDIT: ok this is prolly cus i have the stable rls 0.13.1 ?
Correct, you need the latest CVS build. :)

staringmonkey
0 x

RiX
Gnoblar
Posts: 2
Joined: Sun Apr 11, 2004 1:07 pm

Post by RiX » Thu Apr 29, 2004 7:15 pm

well i have it working by just commenting that line, maybe ill update ogre some time :)
0 x

segfault
Gnoblar
Posts: 23
Joined: Tue Feb 10, 2004 5:36 pm

Post by segfault » Fri Apr 30, 2004 2:59 pm

help please,
i was thinking a had finish with my F.....g scalling coef but i forgot one things i didn't use ... Trimesh and i have no idea how trimesh works, so i don't know where divide the position and the size for scalling my trimesh :cry:

please staringmonkey be my hero :)
0 x

segfault
Gnoblar
Posts: 23
Joined: Tue Feb 10, 2004 5:36 pm

Post by segfault » Tue May 04, 2004 9:07 pm

nobody to help me ?
0 x

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Tue May 04, 2004 9:43 pm

Sorry segfault, I lost track of this post. Unfortunantly, I'm afraid I don't quite understand what your asking. There is a certain amount of documentation for the TriMesh in the from of Doxygen comments in the "OgreTokTriMesh.h" header file. You can't directly scale a TriMesh object, because I don't support scaling for any of the physics objects. I couldn't come up with a clean way to support it that wouldn't risk crashing the Simulation. If you need the "size" of the TriMesh, then I would suppose you just need to grab the bounding box. If at all possible you'll be best off scaling things externally in your modelling program to be the correct size, rather than resizing everything in your application.

HTH,
staringmonkey
0 x

griff

Post by griff » Sat May 08, 2004 8:36 pm

Hello, I'm another member of srambsy and beau's project team. We have had excellent luck with your sdk in creating a game environment, and are all really excited in the progress that can be accomplished in only one month. Thanks again for providing such a useful tool! :)

We've run into an interesting problem with using Ogre RaySceneQueries after creating trimeshes from vertex/index buffers. For some reason, these ray scene queries never find intersections with these trimeshes.

We use the following code to create trimeshes for dot scene chunks:

Code: Select all

	
int totalMeshes = m_pDotSceneMgr->GetNumMeshes(NULL);

for (int CurMesh = 0; CurMesh < totalMeshes; CurMesh++)
{ 
	TriMesh* pTrimesh_debug = Simulation::getSingleton().createTriMesh(
		"Terrain" + StringConverter::toString(CurMesh), 
		String::BLANK, "TestLevel.material", 
		Vector3(0.0f, 0.0f, 0.0f), Quaternion::IDENTITY, 
		String::BLANK, m_pDotSceneMgr->GetVertexDataPtr(NULL, CurMesh), m_pDotSceneMgr->GetIndexDataPtr(NULL, CurMesh)); 
}
After looking into OgreTok, it appears that in the OgreTok::Object constructor, Entities are only created and attached to visual nodes when a mesh is specified. This won't occur when we create from vertex and index data. I'm not sure if this is related to our problem, but I was hoping you may have some insight into a possible solution.

Thank you!

-Griff Hazen
0 x

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Sun May 09, 2004 12:51 am

Hey again team member ;),

I believe you've found your way right to the problem. When using vertex and index buffers, no entities are created. In this way, I'm sort of abusing the vertex/index buffers to hold potentially dynamic data. I do this so that IF the buffers your passing already belong to an entity, any manipulations on that entity will carry through.

When your in a situation where you need a "visual entity" what you'll probably want to do is load up your mesh into OgreTok and then set Object->setVisible(false). Then load up another copy of your data as an actual entity and attach it to the same scene-node so that the objects coincide. The cool thing about this is that you can use a low-poly model for collision and a high-poly model for viewing.

On the other hand, this can be memory consuming, so if your application is trying to eek out performance, you might look into possibly manually "constructing" and entity with the vertex and index buffers and then passing that to OgreTok. That way it would respond both physically and to SceneQueries.

Theres a lot of different ways I can see the "TriMesh system" being used to different ends. It's very flexible, but I'm afraid it's not terribly intuitive either. If I ever work on this project again I would probably rework it so that it would have a higher level of compatibility with other Ogre system under all likely circumstances.

I think I covered all that right. Let me know if that clears things up, or if I left anything out.

Later,
staringmonkey

PS: I'd very much like to see a copy of your project when it gets to a workable state. :)
0 x

Telamon

OgreTok is Great!

Post by Telamon » Wed May 19, 2004 4:23 am

Staringmonkey:

After trying to make ODE play nice with Ogre for a couple of days, I gave up and tried OgreTok. OgreTok is awesome! I'm taking an experimental haptics class and a group of us are using it in our final project. Thanks to being able to leverage Ogre and OgreTok, our project will look and feel twice as good as anyone elses'. Thanks a lot for such a great library.

PS - The .sln file in the CVS repository is a bit out of sync (still includes the Cylinder files in the project and has the wrong code generation setting set (should be "Multithreaded DLL" - It was set to "Single Threaded" in both release and debug mode). The last was a rather nasty thing to try to hunt down, since the linker just spews a lot of what look like STL errors.
0 x

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Wed May 19, 2004 5:09 am

Hey,

Glad you like it. :) Sorry about the .sln file, I don't maintain that because I don't use VC 7. Sinbad simply added it in as a courtesy one day. If someone has an updated file they can e-mail me I will gladly commit an updated version to the repository. :)

Also, see my response to your other "Help" thread Telamon.

Cheers,
staringmonkey
0 x

Mhiriacor
Gnoblar
Posts: 12
Joined: Thu Nov 06, 2003 12:48 pm

Post by Mhiriacor » Thu May 27, 2004 6:18 pm

Hi friends, i have an important question for my project. I am using OgreTok to use collisions. I would like to move a person around an scenary. I use a dynamic sphere but i have a problem. When i try to go up stairs o go down this sphere rolls and my person too. How can i do not to move it and to be all the time vertical (person).

One more thing. How can i move (translate) my mesh (person), to be in different position in relation with sphere?. Thank you for your help. Try to answer fast, its very important.
0 x

User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey » Thu May 27, 2004 7:00 pm

Hey Mhiriacor,

Well, that's not an easy question. I believe Monster pointed you to one thread where this is discussed, although I don't believe it tackles the specific issue your dealing with. I'm not sure there is a "good" or simple way to accomplish what your trying to do.

I would say that the best way to make this work be to modify OgreTok so that you have a class (perhaps based on DynamicSphere) which constrains the rotation of the object so that it remains vertical. This way you could allow the physical object to roll while keeping the visual object vertical. This would also allow you to show your mesh as offset from the Tokamak object.

I can't see any reliable way to solve either of these problems without modifying OgreTok. You might be able to simply make a class which is derives from DynamicSphere and then reimplement only those parts which you need to change. It would probably work this way, but I sense it could get messy.

Regardless, there is no simple answer. I don't believe either of these problems can be solved with a simple routine. However, I provide the disclaimer that I haven't been working on OgreTok regularly for a while now, so nothing I say should be taken as gospel.

I hope that helps,
staringmonkey
0 x

Mhiriacor
Gnoblar
Posts: 12
Joined: Thu Nov 06, 2003 12:48 pm

Post by Mhiriacor » Fri May 28, 2004 1:20 pm

I used angularDamping and linearDamping to managed and disable rotation of dynamicsphere. This works perfectly, otherwise, when i try to go up or go down stairs or collision with others spheres, it rotates a bit but constatly. If you now any other simple solution to resolve this, answer as soon as possible. Thank you for your help.
0 x

segfault
Gnoblar
Posts: 23
Joined: Tue Feb 10, 2004 5:36 pm

Post by segfault » Tue Jun 01, 2004 2:50 pm

hello,

i have some probleme with collision with trimesh.
When i drop a cube from very high the cube go through the trimesh. I think it's a bug of tokamak but does someone had the same bug and solved it ?

@ staringmonkey

I don't understand why you didn't integrate sensor because it seems to works when use it directly from tokamak (it seems ... :) )

thanks
0 x

Mhiriacor
Gnoblar
Posts: 12
Joined: Thu Nov 06, 2003 12:48 pm

Post by Mhiriacor » Wed Jun 09, 2004 12:56 pm

Hi segfautl, i think it can be because of one parameter. Try to change STEPS_PER_SECOND parameter of the initial function. I had this problem and i resolve changing this parameter.

Please if you don´t resolve with this your problem, post a message.
0 x

Locked