OgreTok - Comments / Questions / Suggestions / Help / etc.
- 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
Interesting - switched in that mesh i posted and collisions now work with the flat surface but the ball mostly just slides over the gap where I had a quickly created ravine. For now I'll blame my mesh but it is interesting.
I've spent so much time on physics stuff trying to get one engine to cover all my needs. Also bunch of learning curve time in there.
Still not sure ultimately whether to go with ode or tokamak. I have a feeling the first one I get working for all collisions and lack of odd effects is the one.
I've spent so much time on physics stuff trying to get one engine to cover all my needs. Also bunch of learning curve time in there.
Still not sure ultimately whether to go with ode or tokamak. I have a feeling the first one I get working for all collisions and lack of odd effects is the one.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
That's the same thing I saw, not sure what to make of it. I'm hesistant to say it's the mesh, given that we can see the triangles, but at the same time, I can't imagine what the problem could be as all my other test meshes have worked great. If you get it figured out I would really appreciate knowing.Slicky wrote:Interesting - switched in that mesh i posted and collisions now work with the flat surface but the ball mostly just slides over the gap where I had a quickly created ravine. For now I'll blame my mesh but it is interesting.
staringmonkey
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
Just a quick heads-up, I built this today (finally - sorry for the delay!) and if you happen to have the Python include folder ahead of OpCode, OgreTokTriMesh.cpp fails to compile (or rather, the opcode.h it includes, which is from the Python distro, fails to). Making sure Python is after OpCode sorts this out.
@staringmonkey: this is truly great work, I love playing with it! Definitely a great addon, thanks very much for investing your time in it. I also like the fact that the code follows OGRE coding conventions closely too, it makes it very easy to get to grips with. Full kudos!
@staringmonkey: this is truly great work, I love playing with it! Definitely a great addon, thanks very much for investing your time in it. I also like the fact that the code follows OGRE coding conventions closely too, it makes it very easy to get to grips with. Full kudos!
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Why thank you Sinbad, that compliment makes all the work I put into it seem significantly more worthwhile. I only wish that when it was said and done it had actually suited my intended project a little better. It's strange to have just finished work on this and now be toying with the idea of writing a verlet integrator system to handle my actual game. Oh well, such is life.
Thanks for the info on the Python folder, I'll keep that in mind if anyone else hits that problem. I used Python once, but that was a while back and I no longer have it installed so I never ran into that.
Speak soon,
staringmonkey
Thanks for the info on the Python folder, I'll keep that in mind if anyone else hits that problem. I used Python once, but that was a while back and I no longer have it installed so I never ran into that.
Speak soon,
staringmonkey
-
- 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
Thanks and that's good to hear Slicky. I was hoping that was it, wasn't even sure where I was gonna start if I had to debug that mesh loading code again. I'm sure you've noticed that I didn't implement sensors in OgreTok. They should be a reasonably simple addition, and I may go ahead and add them. I left them out because they, like a few other things, would be impossible to integrate with the TriMesh code. This is unfortunantly a limitation of Tokamak that I've been unable to get around. I vastly expanded Tokamak's TriMesh implementation, but there was no way to integrate collision callbacks with TriMeshes, sensors with TriMeshes, etc. Quite sad really as that would be by far one of the coolest uses. Anyway, I'll probably go ahead and add sensor support sometime in the next few days since you've expressed a desire for it. I'll let you know.
staringmonkey
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
I couldn't find anyway to determine if a sensor is detecting terrain. If you run across a way to make that work let me know. I still doubt I would be able to implement detection of discrete 'TriMesh' objects, as their is no way (that I know of) of accessing the triangle userData. (The same problem I had with the collision callback.), but even limited usage would be better than nothing. I've basically implemented a limited usage technique for the collision callback. If a returned PhysicalObject is null (either A or B) then that object was terrain. That at least lets the user know when a terrain collision is happening, but it doesn't allow them to know which one. If I could do the same thing for sensors then that would be better than nothing. Let me know what you find out.
staringmonkey
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
@Slicky
I just wanted to let you know that I looked into adding sensor support to OgreTok again and, once again, decided not to. I realized that even if sensors can be used to detect terrain/TriMesh collisions, they definantly can't when the TerrainTriangleQueryCallback (Tokamak's TriMesh callback) is being used. As OgreTok uses this callback 100% of the time you could never sense terrain. This is just too great of a loss to bother implementing them (that's the biggest reason I could ever see to use them).
However, I'm happy to say that with a little ingenuity I think I've found a very nice workaround. If you want to detect any object simply use Ogre's RaySceneQuery. This works just like a sensor but with bunches of benefits, including culling, a list of contacts instead of just first contact, contact sorting, etc. You can then take the MoveableObject(s) you collided with and determine the PhysicalObject via the getUserObject() method (OgreTok maintains reverse linkage with all entities via Ogre's UserDefinedObject paradigm).
If your worried about detecting a bunch of non-physical objects then you can simply set a query mask to filter in only the physical objects. Wah-lah, instant uber-sensor! I intend to use this method for explosion/shockwave effects in my game, hopefully it will work well. Personally I think it's vastly more powerful then Tokamak's sensors (not to mention the added flexibility). Anything you can do in with Tokamak sensors (such as the car demo) can be done with these plus about a million other things.
Anyway, let me know what you think,
staringmonkey
I just wanted to let you know that I looked into adding sensor support to OgreTok again and, once again, decided not to. I realized that even if sensors can be used to detect terrain/TriMesh collisions, they definantly can't when the TerrainTriangleQueryCallback (Tokamak's TriMesh callback) is being used. As OgreTok uses this callback 100% of the time you could never sense terrain. This is just too great of a loss to bother implementing them (that's the biggest reason I could ever see to use them).
However, I'm happy to say that with a little ingenuity I think I've found a very nice workaround. If you want to detect any object simply use Ogre's RaySceneQuery. This works just like a sensor but with bunches of benefits, including culling, a list of contacts instead of just first contact, contact sorting, etc. You can then take the MoveableObject(s) you collided with and determine the PhysicalObject via the getUserObject() method (OgreTok maintains reverse linkage with all entities via Ogre's UserDefinedObject paradigm).
If your worried about detecting a bunch of non-physical objects then you can simply set a query mask to filter in only the physical objects. Wah-lah, instant uber-sensor! I intend to use this method for explosion/shockwave effects in my game, hopefully it will work well. Personally I think it's vastly more powerful then Tokamak's sensors (not to mention the added flexibility). Anything you can do in with Tokamak sensors (such as the car demo) can be done with these plus about a million other things.
Anyway, let me know what you think,
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
I did some work yesterday. I don't think my skills are as good as yours. I am self taught and try and improve as I go. Anyway, maybe I don't understand but I am using some sensors which I believe are interacting with the terrain because I have collision depth. I have a cube sliding under force. I need to add in some visualization so I can be sure where the sensors are and add an overlay so I can see in real time the values. The damping or something seems to need tweaking or spring force I am not sure yet.
I think what you are saying is detecting which trimesh you are interacting with? I haven't tried since the trimesh is the terrain and it doesn't matter to me. I think you can access the userdata of the collision object.
Oh further thought - I just reread your post. I don't even think I am using the trimesh callback.
Anyway I have a wip vehicle class object if you need.
I think what you are saying is detecting which trimesh you are interacting with? I haven't tried since the trimesh is the terrain and it doesn't matter to me. I think you can access the userdata of the collision object.
Oh further thought - I just reread your post. I don't even think I am using the trimesh callback.
Anyway I have a wip vehicle class object if you need.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hehe, well I don't count myself much of a programmer, but I've certainly gotten better since I ceased to code of necessity and began to code out of enjoyment. It's amazing what a change of perspective can do for you.Slicky wrote: I did some work yesterday. I don't think my skills are as good as yours. I am self taught and try and improve as I go.
Yes, if you are using SetTerrainMesh() then the sensor will detect the terrain. However, it won't if you are using the callback (like OgreTok does), because it has no triangle data.Slicky wrote: Anyway, maybe I don't understand but I am using some sensors which I believe are interacting with the terrain because I have collision depth.
I haven't found any way to access the userdata of the detected triangles. If you find a way I'd appreciate knowing. On a related note I did get a response from the Tokamak team about being unable to get the userdata during the collision callback and as I understand that is being addressed so hopefully this will be as well.Slicky wrote: I think what you are saying is detecting which trimesh you are interacting with? I haven't tried since the trimesh is the terrain and it doesn't matter to me. I think you can access the userdata of the collision object.
For your purposes it may be easier to simply collapse the terrain into a single mesh and use SetTerrainMesh(), at least then your sensors will work. However, it's going to seriously compromise your flexibility and for that reason I'm opting for the approach detailed in my previous post.Slicky wrote: Oh further thought - I just reread your post. I don't even think I am using the trimesh callback.
Hmmm, if your using the sensor method then I don't think I need to see it. I've pretty much decided that I'm 100% against Tokamak sensors at this point, but thanks for the generous offer.Slicky wrote: Anyway I have a wip vehicle class object if you need.
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
I actually didn't include the option to create child nodes from the Objects scene nodes. At the time I couldn't see any use for it, but I suppose there are times when it might be needed. Three things. 1) If you just want the sphere to be the object, then pass it as the mesh parameter. 2) You can add a mesh after creation of the object using attachObject() (but not position it because it doesn't have it's own node). 3) If you just need a debugging sphere then pass true as the last parameter to your creation function. If none of these fit your needs then you'll probably want to add a getSceneNode() function to the Object class. Should only take a second, just like:
Then you can access the SceneNode directly and create children. Alternatively, you could abstract out all the scenenode creation functions into Object, but thats probably overkill for your needs (that's how I will do it if I decid to add that at some point).
Hope that helps,
staringmonkey
Code: Select all
// getSceneNode()
SceneNode* Object::getSceneNode(void)
{
return mSceneNode;
}
Hope that helps,
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hi Staringmonkey
I've had a good look through OgreTok, and let me say that this is a great add-on. Well done.
I also came unglued on the "older-current-version-of-Tokamak" problem - so downloaded the latest.
On simulation 1, if you fire the bullet into the lower part of that big pole on the left (obstacle3), it passes straight through and doesn't bounce off! It also passed through the very top. Odd behaviour.
I've had a good look through OgreTok, and let me say that this is a great add-on. Well done.
I also came unglued on the "older-current-version-of-Tokamak" problem - so downloaded the latest.
On simulation 1, if you fire the bullet into the lower part of that big pole on the left (obstacle3), it passes straight through and doesn't bounce off! It also passed through the very top. Odd behaviour.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Thanks K9. Just out of curiosity, the name is a Dr. Who reference I assume?K9 wrote: I've had a good look through OgreTok, and let me say that this is a great add-on. Well done.
Yeah, I'm working on a fix for this at the moment. You can see in my post before this that I knew I had a problem with cylinder sizes, but I was wrong when I thought I had fixed it. For some seriously strange reason when I create DynamicCylinder's I have to divide the height by two when I set it in Tokamak. For StaticCylinder's I don't need to do this. I could create a workaround for this easily, but I haven't just yet because I'm instensely curious why this is happening, and I can't figure that part out. I'm gonna go over this thoroughly this weekend (or sooner) and see if this is my fault or something internal to Tokamak. If anyone happens across a reason for this let me know.K9 wrote: On simulation 1, if you fire the bullet into the lower part of that big pole on the left (obstacle3), it passes straight through and doesn't bounce off! It also passed through the very top. Odd behaviour.
Cheers ,
staringmonkey
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
Dr Who? No it's just a play on my real name. K9 = KayNine if you didn't guess.
The more I play with this, the more I love it! You've created Ogre Mechano. The interface for creating objects is brilliant.
I'm currently seeing if I can recreate the RadDude demos using OgreTok. Seems to be going ok, but I can't work out how to set the joint limits (I also haven't read you todo list yet, so maybe it's there).
The more I play with this, the more I love it! You've created Ogre Mechano. The interface for creating objects is brilliant.
I'm currently seeing if I can recreate the RadDude demos using OgreTok. Seems to be going ok, but I can't work out how to set the joint limits (I also haven't read you todo list yet, so maybe it's there).
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hehe, yeah I figured K9 and KayNine were one and the same. There was a robotic dog in Doctor Who (old British BRAND NAME, hopefully soon to return), I thought you that was the inspiration. Silly me.KayNine wrote:Dr Who? No it's just a play on my real name. K9 = KayNine if you didn't guess.
Hehe, thanks! I keep working away to make it better, let me know if there is anything you would like to see in it.KayNine wrote: The more I play with this, the more I love it! You've created Ogre Mechano. The interface for creating objects is brilliant.
You should be able to set joint limits, the functions are called getUpperLimit, setUpperLimit, and the like, basically like the Tokamak versions.KayNine wrote: I'm currently seeing if I can recreate the RadDude demos using OgreTok. Seems to be going ok, but I can't work out how to set the joint limits (I also haven't read you todo list yet, so maybe it's there).
Oh and FYI I'm still working on the cylinder collision bug, it may be a problem with Tokamak's collision detection...
[Edit]
Ah, one more thing! If you do get a nice ragdoll demo worked out I'd be happy to include it as a demo in the distribution. I wanted to include one, I just hadn't had the time to put one together. You'd, of course, get appropriate credit.
[/Edit]
Later,
staringmonkey
- Robomaniac
- Hobgoblin
- Posts: 508
- Joined: Tue Feb 03, 2004 6:39 am
Havn't really looked at this, as i cannot access cvs from here (damn overprotective school firewall), but i'm looking into it, is it possible to say run a command like apply physics which applies physics to the whole scene, or do i need to set up every object in my level to include collision detection. Also, it would be great to see a ragdoll demo, i didn't think it was possible w/ tokomak (sp?)
Thanks in Advance
Thanks in Advance
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Nope, it's pretty much 100% automated. Just setup your objects and call Simulation::step(time) each frame.Robomaniac wrote:Havn't really looked at this, as i cannot access cvs from here (damn overprotective school firewall), but i'm looking into it, is it possible to say run a command like apply physics which applies physics to the whole scene, or do i need to set up every object in my level to include collision detection.
It's very possible, not as intuitive as a system like Havok has, but certainly feasible, just a collection of boxes and appropriately limited joints.Robomaniac wrote: Also, it would be great to see a ragdoll demo, i didn't think it was possible w/ tokomak (sp?)
Later,
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
Hmm having a problem with a ball partially dropping through a simple extended box mesh when testing adding more than one mesh to a scene. Just when I think I've got a physics/collision setup almost working. Do i need to worry much about the
part of the code? It seems that I can add meshes with or without it. I tried making the mesh more detailed or just loading it alone. It's weird since my larger test level geometry appears to collide well. I played with masses and materials. I even collapsed it into the level. Here is the example mesh. One thing is that i load all meshes using the origin but they have uvw positions so that they show up at the correct location in the scene.
It's been about a week or so since last cvs update.
Example mesh -> http://www.battleop.net/temp/ramp02.zip
Code: Select all
// Manually load the terrain mesh without the WRITE_ONLY flag, for direct access
// Mesh* terrain = MeshManager::getSingleton().load("base.mesh", HardwareBuffer::HBU_STATIC, HardwareBuffer::HBU_STATIC, false, false);
//
It's been about a week or so since last cvs update.
Example mesh -> http://www.battleop.net/temp/ramp02.zip
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Actually, you can leave this out, although as I understand it, you shouldn't be able to. According to the Ogre manual reading from a write-only buffer is a no-no, and they default to write-only... but they do seem to work fine, so I'm guessing something has changed. Sinbad talked about possibly making shadow buffers the default at some point, so I'm guessing something along those lines has changed. Might be best to include it for clarity, but it probably isn't needed. Either way it shouldn't make the slightest difference to anything OgreTok related.Slicky wrote: Do i need to worry much about thepart of the code? It seems that I can add meshes with or without it.Code: Select all
// Manually load the terrain mesh without the WRITE_ONLY flag, for direct access // Mesh* terrain = MeshManager::getSingleton().load("base.mesh", HardwareBuffer::HBU_STATIC, HardwareBuffer::HBU_STATIC, false, false); //
I looked over your mesh, and there are a few things that jump out at me. Firstly, it strikes me that all the problems with this mesh are conspicously similar to the problems I saw with the first terrain mesh you sent me. In this case I seem to get collision with only the bottom of the box. At first I thought this was a SubMesh loading problem, however, I also get some collision near (0, -500, 0) with an invisible surface. When I debugged your mesh, I got the following info (ignore the timestamps):Slicky wrote: I tried making the mesh more detailed or just loading it alone. It's weird since my larger test level geometry appears to collide well. I played with masses and materials. I even collapsed it into the level. Here is the example mesh. One thing is that i load all meshes using the origin but they have uvw positions so that they show up at the correct location in the scene.
Code: Select all
22:38:55: Mesh = ramp02.mesh
22:38:55: SubMeshes = 6
22:38:55: SubMesh 0
22:38:55: VertSize = 12
22:38:55: VertCount = 1526
22:38:55: IndexSize = 2
22:38:55: IndexCount = 8616
22:38:55: SubMesh 1
22:38:55: VertSize = 12
22:38:55: VertCount = 1534
22:38:55: IndexSize = 2
22:38:55: IndexCount = 8664
22:38:55: SubMesh 2
22:38:55: VertSize = 12
22:38:55: VertCount = 211
22:38:55: IndexSize = 2
22:38:55: IndexCount = 840
22:38:55: SubMesh 3
22:38:55: VertSize = 12
22:38:55: VertCount = 127
22:38:55: IndexSize = 2
22:38:55: IndexCount = 576
22:38:55: SubMesh 4
22:38:55: VertSize = 12
22:38:55: VertCount = 211
22:38:55: IndexSize = 2
22:38:55: IndexCount = 840
22:38:55: SubMesh 5
22:38:55: VertSize = 12
22:38:55: VertCount = 127
22:38:55: IndexSize = 2
22:38:55: IndexCount = 576
22:38:55: TotalVertices = 3736
22:38:55: TotalIndices = 20112
22:38:55: LastVertex = -750 -750 5170.21
I did an update tonight and I can gaurantee there will be another one tommorow, although I don't know exactly when. (Figured out the cylinder bug, but it's gonna require a few large changes to fix.) Also the new code for stepping in the CVS should be considered very experimental. I'd like some people to take a look at it and tell me what they think. It should be faster, but offers less direct control over the framerate. If everyone hates it, I'll go back to the fractional stepping method (or more likely just include both with a #ifdef toggle).Slicky wrote: It's been about a week or so since last cvs update.
Bye bye for now,
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
I will check into the mesh export - I actually didn't notice submeshes I was leaving it up to the exporter. The extra detail was in there while I tested with smaller triangles.
The mesh is placed in the modeller and then all meshes are loaded at 0,0,0 so they all have a consistent offset point.
I agree the submesh thing is suspicious - it may be done when converting the primitive to a shape automatically I will have to check.
The mesh is placed in the modeller and then all meshes are loaded at 0,0,0 so they all have a consistent offset point.
I agree the submesh thing is suspicious - it may be done when converting the primitive to a shape automatically I will have to check.
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
Well I've got a basic rag-doll falling down stairs, but I'm struggling a little with the joint limits. If there are incorrectly setup, my Dude goes flying into space. But I'll get it worked out.
Oh, do you happen to know what neT3 in Tokamak? I need to find the Ogre equivilent to replicate some of the functionality of the Dude samples.
Oh, do you happen to know what neT3 in Tokamak? I need to find the Ogre equivilent to replicate some of the functionality of the Dude samples.