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 »

Hehe, just committed a fix as well. :P

EDIT: If you don't want to wait for a new version to propagate you just have to make that parameter addition in like four places and it will be fixed (if you haven't already :)).

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 »

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

Post by staringmonkey »

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

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 »

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

Post by staringmonkey »

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

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
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 »

Yep not sure if I mentioned it before but excellent work and nice documentation in the code.

I just created a new mesh in Max and seem to have no problems with collisions. Now I want to learn about sensors do to some testing.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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. :P 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
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 there is some sensor and terrain capability. I'll dig in later tonight.

[edit]oh maybe you mean the way you implemented it. Anyway, I still need to look at it :shock:
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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

Post by staringmonkey »

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

Post by staringmonkey »

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.
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: 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.
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: 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.
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: Oh further thought - I just reread your post. I don't even think I am using the trimesh callback.
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: Anyway I have a wip vehicle class object if you need.
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. :)

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 »

Is there an easy way to create a childscenenode from within say the dynamicbox class? I was playing around using the supplied parent scenenode * and couldn't get a sphere for example to show up.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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:

Code: Select all

// getSceneNode()
SceneNode* Object::getSceneNode(void)
{
return mSceneNode;
}
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
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

A quick FYI for anyone using OgreTok, I just uploaded a fix for a problem with cylinder sizing and spiced up the TriMesh demo a bit.

Cheers,
staringmonkey
K9

Post by K9 »

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

Post by staringmonkey »

K9 wrote: I've had a good look through OgreTok, and let me say that this is a great add-on. Well done.
Thanks K9. :) Just out of curiosity, the name is a Dr. Who reference I assume? ;)
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.
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. :)

Cheers :),
staringmonkey
KayNine
Halfling
Posts: 71
Joined: Wed Dec 03, 2003 10:53 am
Location: Adelaide, Australia

Post by KayNine »

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

Post by staringmonkey »

KayNine wrote:Dr Who? No it's just a play on my real name. K9 = KayNine if you didn't guess.
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: The more I play with this, the more I love it! You've created Ogre Mechano. The interface for creating objects is brilliant.
Hehe, thanks! :D I keep working away to make it better, let me know if there is anything you would like to see in it. :)
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).
You should be able to set joint limits, the functions are called getUpperLimit, setUpperLimit, and the like, basically like the Tokamak versions. :)

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
User avatar
Robomaniac
Hobgoblin
Posts: 508
Joined: Tue Feb 03, 2004 6:39 am

Post by Robomaniac »

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
phear hingo

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

Post by staringmonkey »

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.
Nope, it's pretty much 100% automated. Just setup your objects and call Simulation::step(time) each frame.
Robomaniac wrote: Also, it would be great to see a ragdoll demo, i didn't think it was possible w/ tokomak (sp?)
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.

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 »

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

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

Post by staringmonkey »

Slicky wrote: Do i need to worry much about the

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);
//	
part of the code? It seems that I can add meshes with or without it.
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: 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.
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):

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
So my first question, although it shouldn't actually "break" anything is: 3700+ vertices for a box? Something seems voodoo with your method of construction. And secondly, the fact that you have 6 submeshes leads me to believe that each side of your box is being exported as a seperate SubMesh, which probably isn't ideal, although it shouldn't actually break anything. I'm also quite confused on this talk of uvw locations... I'm not sure what you mean by that, but I did find it strange that your mesh wasn't positioned where I loaded it. I assume you are placing it in your modeller? If your using 3ds for this I would try just simplifying your mesh and seeing if that clears it up (moving it to origin would be nice too, although it shouldn't matter). I'm not honestly sure there isn't a bug in my SubMesh loading code, so I'll look at that a bit more, but in the meantime try cleaning up you mesh and see if things work a bit better.
Slicky wrote: It's been about a week or so since last cvs update.
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).

Bye bye for now,
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 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.
KayNine
Halfling
Posts: 71
Joined: Wed Dec 03, 2003 10:53 am
Location: Adelaide, Australia

Post by KayNine »

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