OgreTok - Comments / Questions / Suggestions / Help / etc.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
@Slicky
If your using 3DS you need to make sure you assign a material id to your object in subobject mode (Element selection) after you convert it to an editable mesh. This will allow it to be expected as a single SubMesh. I had this problem for quite a while too. Let me know if you have any luck. I have tested the SubMesh support before, but only with the OgreHead model. If you continue to have problems I'll bust out a couple more tests and see if I can track anything down.
@KayNine
Wumpee has it right, it's a basically a Matrix4. There are Matrix4_to_neT3() and neT3_to_Matrix4() conversion functions in OgreTokConversions.h.
Hope that helps ,
staringmonkey
If your using 3DS you need to make sure you assign a material id to your object in subobject mode (Element selection) after you convert it to an editable mesh. This will allow it to be expected as a single SubMesh. I had this problem for quite a while too. Let me know if you have any luck. I have tested the SubMesh support before, but only with the OgreHead model. If you continue to have problems I'll bust out a couple more tests and see if I can track anything down.
@KayNine
Wumpee has it right, it's a basically a Matrix4. There are Matrix4_to_neT3() and neT3_to_Matrix4() conversion functions in OgreTokConversions.h.
Hope that helps ,
staringmonkey
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
Assigning the material ID knocked the submesh count down to one. Now collision works fine. That probably will leave me with the question of what to do about multiple materials in the future. I don't know if it is with this primitive only or all submeshes. Sounds like the ogrehead worked so I am not sure.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
It actually has to do with the 3DS exporter more than anything else. You can still easily apply materials by using a multimaterial and assigning different material ids to each element. Check out the skateboard tutorial that comes with the 3DS exporter, it shows how. Regardless, this still leaves in doubt whether or not my SubMesh loading is correct, so I've added more thoroughly testing it to my TODO list. It's behind a few other things (finishing up the cylinder fix, cleaning up the new step/update code, and redocumenting the updateRate functions, to name the big ones), but I should get to it early next week at the latest.
I have a feeling the reason why the multiple SubMeshes were breaking it isn't that the code is wrong, but rather has something to do with duplication of vertices and/or OPCODE not correctly building the polygon tree (because edge vertices weren't shared). Never-the-less, it's incumbant on me to more thoroughly test things, so that's what I'll do.
Thanks for the report,
staringmonkey
I have a feeling the reason why the multiple SubMeshes were breaking it isn't that the code is wrong, but rather has something to do with duplication of vertices and/or OPCODE not correctly building the polygon tree (because edge vertices weren't shared). Never-the-less, it's incumbant on me to more thoroughly test things, so that's what I'll do.
Thanks for the report,
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Ok, a fix has been committed for ALL outstanding issues on my TODO list, except for SubMesh testing. New features/fixes:
If anyone gets something bashed together of what they are working on I would love to see some screenshots in this thread. If I get to a point where I feel comfortable with it and no-one is making feature requests I will probably do a 1.0 release, including binaries, and start an OgreTok 1.0 thread with some pictures and stuff, so people know what it's about. I've finally got some webspace again. But I'm getting ahead of myself...
Enjoy ,
staringmonkey
- Both fractional stepping and absolute stepping methods are included, selectable via a compile-time switch in OgreTokPrerequisites.h. Absolute stepping is the default, because it's significantly faster, but if you need the increased accuracy of the other method, it's included as well. See the documentation for Simulation::getUpdateRate() for more info.
- Fixed all the cylinder glitchiness. What was wrong I hear you ask? Well, they weren't cylinders, they were capsules. I renamed all the cylinder classes to 'capsule' and updated all the documentation to reflect this. I'm not sure why Tokamak calls them cylinders, but I suppose, it wasn't really a complex fix.
- All debug objects now properly scale to match their physical bodies if they are resized. I thought I had already done this, but apparently I hadn't, must have gotten erased off my TODO list on accident. Anyway, this is really cool because you can dynamically change the size of your objects via the setSize() methods and your debug object will change size to match. All sorts of cool.
- Increased documentation in areas I thought needed it, most notably with regards to updating.
If anyone gets something bashed together of what they are working on I would love to see some screenshots in this thread. If I get to a point where I feel comfortable with it and no-one is making feature requests I will probably do a 1.0 release, including binaries, and start an OgreTok 1.0 thread with some pictures and stuff, so people know what it's about. I've finally got some webspace again. But I'm getting ahead of myself...
Enjoy ,
staringmonkey
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
staringmonkey, this might already be possible, but.......
The debug mode is awesome. It's a great way of auto-generating visibile objects around the physics objects. It would be nice to over-ride the std OgreTok material used for debug objects. I fed a material name into a createStaticBox, but it ignored it (when using debug mode). Would be nice to have the OgreTok material overridden by that texture.
Also, I've recreated RadDude, but he flys to pieces after hitting the ground when I use limits. Adding....holds the Dude when he's falling to the ground, then the pieces all vibrate and fly through the air when he hits the ground. With limits switched off, it all works ok. Any clues?
The debug mode is awesome. It's a great way of auto-generating visibile objects around the physics objects. It would be nice to over-ride the std OgreTok material used for debug objects. I fed a material name into a createStaticBox, but it ignored it (when using debug mode). Would be nice to have the OgreTok material overridden by that texture.
Code: Select all
Simulation::getSingleton().createStaticBox("ground",
String::BLANK,
String::BLANK,
Vector3(0.0f, -300.0f, 0.0f),
Quaternion::IDENTITY,
String::BLANK,
Vector3(2500.0f, 5.0f, 2500.0f),
true);
Code: Select all
BallSocket* rightArmBodyJoint = Simulation::getSingleton().createBallSocket("RightArmBodyJoint",
rightArm,
body,
DudePosition + Vector3(-22.0f, 28.0f, 0.0f));
rightArmBodyJoint->setLowerLimit(0.0f);
rightArmBodyJoint->setUpperLimit(NE_PI/2.5f);
rightArmBodyJoint->setLimitEnabled(true);
rightArmBodyJoint->setLowerTwistLimit(0.1f);
rightArmBodyJoint->setTwistLimitEnabled(true);
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
I hadn't done this because I wanted to be able to have both the regular object and the debug object show at the same time and the debug object would have the nice bright white and red texture so it would be easily visible where it "poked through" the real object. But now that I think about it, it would be pretty easy to just check if(mesh == String::EMPTY && material != String::EMPTY) and if that's the case then override the default debug material. That would perhaps allow for easier visualization of scene objects. I'll see about getting that in for the next update for you.KayNine wrote: The debug mode is awesome. It's a great way of auto-generating visibile objects around the physics objects. It would be nice to over-ride the std OgreTok material used for debug objects. I fed a material name into a createStaticBox, but it ignored it (when using debug mode). Would be nice to have the OgreTok material overridden by that texture.
Arg, honestly I don't have nearly as much experiance with joints as I should. That's why the included demos are so simple, I had a hell of a time wrapping my head around the angles involved. I've only got a minute to go over this before I need to get to bed, but I'm gonna have family at the house over the weekend and may not get much other chance to help out, so let me see what I can do now.KayNine wrote: Also, I've recreated RadDude, but he flys to pieces after hitting the ground when I use limits. Adding....holds the Dude when he's falling to the ground, then the pieces all vibrate and fly through the air when he hits the ground. With limits switched off, it all works ok. Any clues?Code: Select all
BallSocket* rightArmBodyJoint = Simulation::getSingleton().createBallSocket("RightArmBodyJoint", rightArm, body, DudePosition + Vector3(-22.0f, 28.0f, 0.0f)); rightArmBodyJoint->setLowerLimit(0.0f); rightArmBodyJoint->setUpperLimit(NE_PI/2.5f); rightArmBodyJoint->setLimitEnabled(true); rightArmBodyJoint->setLowerTwistLimit(0.1f); rightArmBodyJoint->setTwistLimitEnabled(true);
I see that your recreating the Tokamak demo's numbers, which is certainly a good idea to start. As a debugging procedure, I would try only setting one limit and seeing how things behave (if your not already), rather than setting them all at once. I'm comparing the Tokamak source here to what you have and I notice that for joints on the right half of the body they rotate them 180 degrees on the x-axis to orient them in the correct direction. This doesn't appear to be something your doing. You might try setting only the left arm joint and then only the right arm joint and see if there is a difference.
Other than that I don't see any obvious problems. Although, and I'll be candid, I haven't really tested the Joint code that thoroughly. I don't think there is anything wrong with it, because it is 99% pass through. There is almost nothing in there that I wrote, but that doesn't eliminate the potential for typos. If you don't get it worked out soon and you don't mind, post the code what you have so far on here, or private message it to me, or e-mail me, and I'll try and replicate it on my end, that way I can debug as I go. Together we ought to be able to get it figured out, but like I said, not too much free time this weekend.
Later,
staringmonkey
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
Excellent, thanks.But now that I think about it, it would be pretty easy to just check if(mesh == String::EMPTY && material != String::EMPTY) and if that's the case then override the default debug material. That would perhaps allow for easier visualization of scene objects. I'll see about getting that in for the next update for you.
Tried that, and it just seems to be certain joint limits. I think you are right in that the arm has been rotated 180 degrees - I'll try that.As a debugging procedure, I would try only setting one limit and seeing how things behave (if your not already)
The code I've developed is a direct lift from the Sample4 code in Tokamak, so it's no big secret. I'll post it here once I've played around with it a little more and convinced myself I'm not doing something stupid.If you don't get it worked out soon and you don't mind, post the code what you have so far on here, or private message it to me, or e-mail me, and I'll try and replicate it on my end, that way I can debug as I go
Once the RadDude demo is working, it should only be a small step to implementing rag-doll for Ogre meshes. I was thinking, robot.mesh in the rag-doll demo! But as you've said before, there would be some manual tweaking to set joint types and limits.
-
- Bronze Sponsor
- Posts: 614
- Joined: Mon Apr 14, 2003 11:48 pm
- Location: Was LA now France
- x 25
This is my current testing. I have now been through ODE and liked it except couldn't get stable vehicle physics. Tokamak seems more stable at least for me.If anyone gets something bashed together of what they are working on I would love to see some screenshots in this thread.
The pic is a test vehicle with 6 wheels on a ramp.
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
If you can narrow it down and figure out exactly which joints are being problamatic, that should simplify the process of finding the problem. If the right arm joint is and the left one isn't then the rotation is almost certainly a problem. I didn't have too much chance to look over how the leg joints are setup, but I think there is some additional rotation applied to the forearm joints. Then on the thighs they do some additoinal manipulation of the x and z axes of the joint frame, but only relative to object B. This could be problamatic because I left relative positioning out (was trying to avoid having 20 constructors). It may be necessary to put it back in to truly replicate the Tokamak demo for the bottom limbs.KayNine wrote: Tried that, and it just seems to be certain joint limits. I think you are right in that the arm has been rotated 180 degrees - I'll try that.
My thoughts exactly.KayNine wrote: Once the RadDude demo is working, it should only be a small step to implementing rag-doll for Ogre meshes. I was thinking, robot.mesh in the rag-doll demo! But as you've said before, there would be some manual tweaking to set joint types and limits.
@Slicky
That looks really good man! Glad it's working for you!
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
@KayNine
I've made it so that when constructing a primitive (box/sphere/capsule), if a material is specified and not a mesh, then the material will applied to the debug object. Thanks for the request mate. Unfortunantly, I can't update to the CVS just yet because of...
@Slicky
I've confirmed that there IS a problem with TriMesh loading. It's a very strange one and I have a feeling it's gonna be a real pain to sort out, but you were definantly correct. Finding a fix for this is my #1 priority for the moment. I'll post an update when I know more.
Thanks guys,
staringmonkey
I've made it so that when constructing a primitive (box/sphere/capsule), if a material is specified and not a mesh, then the material will applied to the debug object. Thanks for the request mate. Unfortunantly, I can't update to the CVS just yet because of...
@Slicky
I've confirmed that there IS a problem with TriMesh loading. It's a very strange one and I have a feeling it's gonna be a real pain to sort out, but you were definantly correct. Finding a fix for this is my #1 priority for the moment. I'll post an update when I know more.
Thanks guys,
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Well that wasn't too hard... found the TriMesh loading bug. I wasn't properly incrementing the indicies, which was an easy bug to find once I knew approximentaly what I was looking for, but wasn't something I thought about before. Anyway, the fix for that and the new debug material feature have both been committed, should make it to the public CVS within a day or two. Enjoy.
@KayNine
I'm gonna be going over the Joint system as my next endeavor. I've already decided that I can simplify things drastically by making them take PhysicalObjects as parameters instead of having seperate constructors for DynamicObjects and StaticObjects. I'll also just accept a null argument for "constrain to world" instead of having a seperate constructor. I've also decided to add the functions for relative positioning. This way the constructors will accept a global position/orientation, but then their will be functions for objectA/objectB relative positioning. I'll see if see if I come up with any other features that I need to support as I go. Let me know if you think of any.
staringmonkey
@KayNine
I'm gonna be going over the Joint system as my next endeavor. I've already decided that I can simplify things drastically by making them take PhysicalObjects as parameters instead of having seperate constructors for DynamicObjects and StaticObjects. I'll also just accept a null argument for "constrain to world" instead of having a seperate constructor. I've also decided to add the functions for relative positioning. This way the constructors will accept a global position/orientation, but then their will be functions for objectA/objectB relative positioning. I'll see if see if I come up with any other features that I need to support as I go. Let me know if you think of any.
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
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
After much testing, I've come to the conclusion that either OrgeTok joints are broken, or Tokamak joint are very very complex. I can't even get a plain old static to dynamic object hinge to work. It does all sorts of wierd and wonderful spinning around lots of different axes.
For example, if you paste this code into one of the demo sims....fire a ball at the hanging lever - notice it rotates in all sorts of directions - and it is supposed to be a hinge! It acts more like a ball-socket.
I've played around with all sorts of values in q.FromAxis. Nothing seems to do the trick.
In fact, if you change the Hing to a BallSocket, the outcome is identical. It's also as if the Hinge is being created as a BallSocket.
Disclaimer: Yes, I know I'm probably doing something stupid, but getting this to work is not obvious. (But hey, it wouldn't be fun if it was easy!).
For example, if you paste this code into one of the demo sims....fire a ball at the hanging lever - notice it rotates in all sorts of directions - and it is supposed to be a hinge! It acts more like a ball-socket.
Code: Select all
DynamicSphere* setupDudeSim1(SceneNode* rootNode)
{
// Test sims will return a bullet object for interactivity
DynamicSphere* bullet;
if(Simulation::getSingleton().isInitialised())
Simulation::getSingleton().shutdown();
Simulation::getSingleton().initialise(rootNode, // Node at the top of the object hierarchy (usually root)
Vector3(0.0f, -490.0f, 0.0f), // Gravity
20, // Maximum StaticObjects
50, // Maximum DynamicObjects
20); // Maximum Joints
Simulation::getSingleton().setStepsPerSecond(300);
// Create the Ground
Simulation::getSingleton().createStaticBox("ground", // Name
String::BLANK, // Mesh
String::BLANK, // Material
Vector3(0.0f, -300.0f, 0.0f), // Position
Quaternion::IDENTITY, // Orientation
String::BLANK, // Surface
Vector3(2500.0f, 5.0f, 2500.0f), // Size
true); // Create a debug object
StaticBox* base = Simulation::getSingleton().createStaticBox("base", // Name
String::BLANK, // Mesh
String::BLANK, // Material
Vector3(0.0f, 0.0f, -500.0f), // Position
Quaternion::IDENTITY, // Orientation
String::BLANK, // Surface
Vector3(100.0f, 200.0f, 50.0f), // Size
true); // Create a debug object
DynamicBox* lever = Simulation::getSingleton().createDynamicBox("lever",
String::BLANK,
String::BLANK,
Vector3(0.0f, -200.0f, -500.0f),
Quaternion::IDENTITY,
String::BLANK,
Vector3(100.0f, 200.0f, 50.0f),
true);
// Head - Body joint
Quaternion q;
q.FromAxes(Vector3(1.0f, 0.0f, 0.0f), Vector3(0.0f, 0.0f, 0.0f), Vector3(0.0f, 0.0f, 0.0f));
Hinge* baseLeverJoint = Simulation::getSingleton().createHinge("BaseLevelJoint",
lever, base,
Vector3(0.0f, -100.0f, -500.0f),
q);
baseLeverJoint->setLength(100.0f);
//baseLeverJoint->setLowerLimit(-NE_PI/2.0f);
//baseLeverJoint->setUpperLimit(NE_PI/2.0f);
//baseLeverJoint->setLimitEnabled(true);
bullet = Simulation::getSingleton().createDynamicSphere("bullet", // Name
"sphere100.mesh", // Mesh
"Demo/Scales", // Material
Vector3(1000.0f, 25.0f, 1000.0f), // Position
Quaternion::IDENTITY, // Orientation
String::BLANK, // Surface
50.0f, // Diameter
25.0f, // Mass
false); // Create a debug object
bullet->scale(50.0f / 100.0f, 50.0f / 100.0f, 50.0f / 100.0f);
bullet->setAngularDamping(0.0025f);
return bullet;
}
In fact, if you change the Hing to a BallSocket, the outcome is identical. It's also as if the Hinge is being created as a BallSocket.
Disclaimer: Yes, I know I'm probably doing something stupid, but getting this to work is not obvious. (But hey, it wouldn't be fun if it was easy!).
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
Mmmm, well replacing the above joint code with original Tokamak code...fixes the problem.
Looks like SetJointLength needs to be set BEFORE Enable(true) is called. I'll test this theory by modifying the Tokamak library. Back soon...
Code: Select all
neT3 jointFrame;
jointFrame.rot[0].Set(0.0f, 1.0f, 0.0f);
jointFrame.rot[1].Set(1.0f, 0.0f, 0.0f);
jointFrame.rot[2].Set(0.0f, 0.0f, -1.0f);
neJoint * joint = Simulation::getSingleton().mTokamakSimulator->CreateJoint(lever->_getTokamakObject(), base->_getTokamakObject());
jointFrame.pos.Set(0.0f, 0.0f, -500.0f);
joint->SetType(neJoint::NE_JOINT_HINGE);
joint->SetJointFrameWorld(jointFrame);
joint->SetJointLength(100);
joint->Enable(true);
Looks like SetJointLength needs to be set BEFORE Enable(true) is called. I'll test this theory by modifying the Tokamak library. Back soon...
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
Woo hoo. Adding to the Hinge constructors fixes the problem. The actual length probably should be one of thebody lengths, but I'll leave that to staringmonkey to work out.
Code: Select all
// Set the Joint Length
mTokamakJoint->SetJointLength(100.0f);
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hehe, I just figured this out today as well. It appears that a good deal of Tokamak's joint info (read ALL) can not be modified after the joint has been enabled. I added relative joint positioning to OgreTok yesterday, only to see that it changed nothing at all. After playing around with it I realized that relative positions (or absolute ones) can only be set before the joint is created. This appears to be the case with length, limits, etc. Probably the reason why everything about joints has been so unpredictable. So I'm going to have to work over the joint system pretty thoroughly, and unfortunantly, it's going to involve moving a ton of stuff to the constructor. Anyway, thanks for the heads up on length KayNine, I'll try and get all this joint stuff sorted later today. I'll post again when I have something to report.
staringmonkey
staringmonkey
-
- Halfling
- Posts: 71
- Joined: Wed Dec 03, 2003 10:53 am
- Location: Adelaide, Australia
Nice one. I can report that with the code above, setting Length to 1.0 or 10.0 DOESN'T work. Setting it to 100.0 does, so not sure if the hinge joint length needs to be set to the length of the physical body or not. I'm suprised the Dude demo's in Tokamak work, since they don't set the joint length.
Anyway, thanks a heap for looking into this.
[Edit]Oh, and it is cool the way you have included Joint::_getTokamakJoint for testing purposes. Would be nice if there was a similar function to expose the neSimulation.
Anyway, thanks a heap for looking into this.
[Edit]Oh, and it is cool the way you have included Joint::_getTokamakJoint for testing purposes. Would be nice if there was a similar function to expose the neSimulation.
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Hmmm... that's quite strange. I'll see if I can't work out what it's supposed to be. I swear with all the little usage notes I keep having to add to the OgreTok documentation just for myself, it's going to end up being better documented than Tokamak (if it isn't already).KayNine wrote:Nice one. I can report that with the code above, setting Length to 1.0 or 10.0 DOESN'T work. Setting it to 100.0 does, so not sure if the hinge joint length needs to be set to the length of the physical body or not. I'm suprised the Dude demo's in Tokamak work, since they don't set the joint length.
Done.KayNine wrote: [Edit]Oh, and it is cool the way you have included Joint::_getTokamakJoint for testing purposes. Would be nice if there was a similar function to expose the neSimulation.
Unspecified does seem to be the name of the game with regards to physics, doesn't it.Sinbad wrote: Interestingly ODE has a very similar set of undocumented dependencies with joints. I remember swearing a lot whilst testing the joint support in referenceapp because the order in which you do things is both very important and unspecified
@KayNine
So I meant to ask you, with that self-fix for the hinge joints, does your rag-doll work correctly now? If so any chance you could post/send a copy of your setup source code. I'd much rather be using that for testing than my arbitrary chain of boxes. If it's still not working could you let me know which parts are still broken? I'm trying to work out whether anything related to limits needs to be set before joint->Enable() is called. At the moment it looks like only the position, type, and length information needs to be set prior to enabling it, but I'm not positive. Any info you could provide on that front would be immensely useful. Also (last thing I swear) did you manage to get things setup without using the relative positioning that Tokamak uses in it's rag-doll setup code? I'm trying to decide how to (and if I should) include the relative positioning method as an alternate constructor. When I was messing with it yesterday I found it to be... well, not what I thought it was. In fact I'm not even totally sure I understand it, it appears to be in global coordinates, which doesn't make much sense... Anyway, I'm rambling.
staringmonkey
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
Woohoo, after two hours of tweaking I think I've finally managed to wrap my head around Hinge joints. I moved the length parameter to the constructor, as it happened that was the only thing that needed to be moved. About the only other thing I changed (remebering that I'd already made a ton of changes the two days before) was to alter demo #6 to use Hinge joints with limiters, providing for a much more instructional demo.
I haven't put in the relative positioning stuff. It seems like it's only going to make things more complicated. The code is already written if I need it, but I think it's unnecessary. If someone needs it I'll put it back in.
Now to work on my website which will soon be hosting OgreTok binaries.
staringmonkey
I haven't put in the relative positioning stuff. It seems like it's only going to make things more complicated. The code is already written if I need it, but I think it's unnecessary. If someone needs it I'll put it back in.
Now to work on my website which will soon be hosting OgreTok binaries.
staringmonkey
Looks like everything is progressing well staringmonkey.
Following is the setup code for the Dude demo. Just paste it into one of your sim setups. Should work straight out of the box. I've adjusted gravity a little to make it more realistic, but the body still seems to thud down the stairs rather than bounce. More fine-tuning needed. I've also changed the relative rotation setup for the lower legs, so it is much simpler. I can only assume that the dude setup that way as an example of the relative stuff.
I also haven't implemented the Iterations refinements that the Dude demos do - I assume that would also need to be done in the Joint contructor (before Enable is called).
Maybe the Joint constructors should NOT call Enable, and make the calling code call Enable once the joint is fully setup.
I've gotta say it - the above code was super-simple (once the hing bug was found) to set-up using your library. A real credit to a well designed library. Much easier than using the native Tokamak library.
The next step for me is to rig the robot.mesh/skeleton up with this rag-doll, and throw it down the stairs! Might take a couple of days ....I only get an 1 hour or so per day on this stuff
Following is the setup code for the Dude demo. Just paste it into one of your sim setups. Should work straight out of the box. I've adjusted gravity a little to make it more realistic, but the body still seems to thud down the stairs rather than bounce. More fine-tuning needed. I've also changed the relative rotation setup for the lower legs, so it is much simpler. I can only assume that the dude setup that way as an example of the relative stuff.
I also haven't implemented the Iterations refinements that the Dude demos do - I assume that would also need to be done in the Joint contructor (before Enable is called).
Maybe the Joint constructors should NOT call Enable, and make the calling code call Enable once the joint is fully setup.
Code: Select all
DynamicSphere* setupDudeSim1(SceneNode* rootNode)
{
// Test sims will return a bullet object for interactivity
DynamicSphere* bullet;
if(Simulation::getSingleton().isInitialised())
{
// Shutdown the Simulation (clears all existing objects automatically)
Simulation::getSingleton().shutdown();
}
Simulation::getSingleton().initialise(rootNode, // Node at the top of the object hierarchy (usually root)
Vector3(0.0f, -900.0f, 0.0f), // Gravity
20, // Maximum StaticObjects
50, // Maximum DynamicObjects
20); // Maximum Joints
Simulation::getSingleton().setStepsPerSecond(300);
// Create the Ground
Simulation::getSingleton().createStaticBox("ground", // Name
String::BLANK, // Mesh
String::BLANK, // Material
Vector3(0.0f, -300.0f, 0.0f), // Position
Quaternion::IDENTITY, // Orientation
String::BLANK, // Surface
Vector3(2500.0f, 5.0f, 2500.0f), // Size
true); // Create a debug object
// Create the steps
for (s32 i = 0; i < 10; i++)
{
Simulation::getSingleton().createStaticBox(String("step") + StringConverter::toString(i), // Name
String::BLANK, // Mesh
String::BLANK, // Material
Vector3(0.0f, -280.0f + i * 50.0f, -1000.0f - i * 40.0f), // Position
Quaternion::IDENTITY, // Orientation
String::BLANK, // Surface
Vector3(1000.0f, 40.0f, 80.0f), // Size
true); // Create a debug object
}
// Create the body parts
//====================================================================================
// Body
Vector3 DudePosition(0.0f, 500.0f, -1250.0f);
DynamicBox* body = Simulation::getSingleton().createDynamicBox("body", // Name
String::BLANK, // Mesh
String::BLANK, // Material
DudePosition + Vector3(0.0f, 0.0f, 0.0f), // Position
Quaternion::IDENTITY, // Orientation
String::BLANK, // Surface
Vector3(55.0f, 70.0f, 30.0f), // Size
true); // Create a debug object
// Head
DynamicSphere* head = Simulation::getSingleton().createDynamicSphere("head",
String::BLANK,
String::BLANK,
DudePosition + Vector3(0.0f, 55.0f, 0.0f),
Quaternion::IDENTITY,
String::BLANK,
40.0f,
true);
// Right Arm
Quaternion q;
q.FromAngleAxis(-NE_PI/2.0f, Vector3(0.0f, 0.0f, 1.0f));
DynamicCylinder* rightArm = Simulation::getSingleton().createDynamicCylinder("rightArm",
String::BLANK,
String::BLANK,
DudePosition + Vector3(-45.0f, 28.0f, 0.0f),
q,//Quaternion::IDENTITY,
String::BLANK,
/*Vector3(25.0f, 40.0f, 25.0f),//*/25.0f, 40.0f,
true);
// Left Arm
q.FromAngleAxis(NE_PI/2.0f, Vector3(0.0f, 0.0f, 1.0f));
DynamicCylinder* leftArm = Simulation::getSingleton().createDynamicCylinder("leftArm",
String::BLANK,
String::BLANK,
DudePosition + Vector3(45.0f, 28.0f, 0.0f),
q,//Quaternion::IDENTITY,
String::BLANK,
/*Vector3(25.0f, 40.0f, 25.0f),//*/25.0f, 40.0f,
true);
// Right Forearm
q.FromAngleAxis(-NE_PI/2.0f, Vector3(0.0f, 0.0f, 1.0f));
DynamicBox* rightForearm = Simulation::getSingleton().createDynamicBox("rightForearm",
String::BLANK,
String::BLANK,
DudePosition + Vector3(-90.0f, 28.0f, 0.0f),
q, //Quaternion::IDENTITY,
String::BLANK,
Vector3(24.0f, 60.0f, 24.0f),
true);
// Left Forearm
q.FromAngleAxis(NE_PI/2.0f, Vector3(0.0f, 0.0f, 1.0f));
DynamicBox* leftForearm = Simulation::getSingleton().createDynamicBox("leftForearm",
String::BLANK,
String::BLANK,
DudePosition + Vector3(90.0f, 28.0f, 0.0f),
q, //Quaternion::IDENTITY,
String::BLANK,
Vector3(24.0f, 60.0f, 24.0f),
true);
// Right Thigh
DynamicCylinder* rightThigh = Simulation::getSingleton().createDynamicCylinder("rightThigh",
String::BLANK,
String::BLANK,
DudePosition + Vector3(-20.0f, -60.0f, 0.0f),
Quaternion::IDENTITY,
String::BLANK,
27.0f, 70.0f,//Vector3(27.0f, 70.0f, 20.0f),
true);
// Left Thigh
DynamicCylinder* leftThigh = Simulation::getSingleton().createDynamicCylinder("leftThigh",
String::BLANK,
String::BLANK,
DudePosition + Vector3(20.0f, -60.0f, 0.0f),
Quaternion::IDENTITY,
String::BLANK,
27.0f, 70.0f,//Vector3(27.0f, 70.0f, 20.0f),
true);
// Right Leg
DynamicBox* rightLeg = Simulation::getSingleton().createDynamicBox("rightLeg",
String::BLANK,
String::BLANK,
DudePosition + Vector3(-20.0f, -130.0f, 0.0f),
Quaternion::IDENTITY,
String::BLANK,
Vector3(30.0f, 80.0f, 30.0f),
true);
// Left Left
DynamicBox* leftLeg = Simulation::getSingleton().createDynamicBox("leftLeg",
String::BLANK,
String::BLANK,
DudePosition + Vector3(20.0f, -130.0f, 0.0f),
Quaternion::IDENTITY,
String::BLANK,
Vector3(30.0f, 80.0f, 30.0f),
true);
// Create the Joints
//====================================================================================
// Head - Body joint
Hinge* bodyHeadJoint = Simulation::getSingleton().createHinge("BodyHeadJoint",
body, head,
DudePosition + Vector3(0.0f, 35.0f, 0.0f));
bodyHeadJoint->setLowerLimit(-NE_PI/4.0f);
bodyHeadJoint->setUpperLimit(NE_PI/4.0f);
bodyHeadJoint->setLimitEnabled(true);
// Right Arm - Body joint
q.FromAngleAxis(NE_PI, Vector3(0.0f, 0.0f, 1.0f));
BallSocket* rightArmBodyJoint = Simulation::getSingleton().createBallSocket("RightArmBodyJoint",
rightArm,
body,
DudePosition + Vector3(-22.0f, 28.0f, 0.0f),
q);
rightArmBodyJoint->setLowerLimit(0.0f);
rightArmBodyJoint->setUpperLimit(NE_PI/2.5f);
rightArmBodyJoint->setLimitEnabled(true);
rightArmBodyJoint->setLowerTwistLimit(0.1f);
rightArmBodyJoint->setTwistLimitEnabled(true);
// Left Arm - Body joint
q.FromAngleAxis(0, Vector3(0.0f, 0.0f, 1.0f));
BallSocket* leftArmBodyJoint = Simulation::getSingleton().createBallSocket("LeftArmBodyJoint",
leftArm,
body,
DudePosition + Vector3(22.0f, 28.0f, 0.0f),
q);
leftArmBodyJoint->setLowerLimit(0.0f);
leftArmBodyJoint->setUpperLimit(NE_PI/2.5f);
leftArmBodyJoint->setLimitEnabled(true);
leftArmBodyJoint->setLowerTwistLimit(0.1f);
leftArmBodyJoint->setTwistLimitEnabled(true);
// Right Forearm - Arm Joint
q.FromAxes(Vector3(1.0f, 0.0f, 0.0f), Vector3(0.0f, 1.0f, 0.0f), Vector3(0.0f, 0.0f, 1.0f));
Hinge* rightForearmArmJoint = Simulation::getSingleton().createHinge("RightForearmArmJoint",
rightArm,
rightForearm,
DudePosition + Vector3(-65.0f, 28.0f, 0.0f),
q);
rightForearmArmJoint->setLowerLimit(0.0f);
rightForearmArmJoint->setUpperLimit(NE_PI/2.0f);
rightForearmArmJoint->setLimitEnabled(true);
// Left Forearm - Arm Joint
q.FromAxes(Vector3(-1.0f, 0.0f, 0.0f), Vector3(0.0f, -1.0f, 0.0f), Vector3(0.0f, 0.0f, 1.0f));
Hinge* leftForearmArmJoint = Simulation::getSingleton().createHinge("LeftForearmArmJoint",
leftForearm,
leftArm,
DudePosition + Vector3(65.0f, 28.0f, 0.0f),
q);
leftForearmArmJoint->setLowerLimit(0.0);
leftForearmArmJoint->setUpperLimit(NE_PI/2.0);
leftForearmArmJoint->setLimitEnabled(true);
// Right Thigh - Body Joint
q.FromAngleAxis(NE_PI * 6.0f / 8.0f, Vector3(0.0f, 0.0f, 1.0f));
BallSocket* rightThighBodyJoint = Simulation::getSingleton().createBallSocket("RightThighBodyJoint",
rightThigh,
body,
DudePosition + Vector3(-20.0f, -32.0f, 0.0f),
q);
rightThighBodyJoint->setLowerLimit(0.0f);
rightThighBodyJoint->setUpperLimit(NE_PI/4.0f);
rightThighBodyJoint->setLimitEnabled(true);
rightThighBodyJoint->setLowerTwistLimit(0.8f);
rightThighBodyJoint->setTwistLimitEnabled(true);
// Left Thigh - Body Joint
q.FromAngleAxis(NE_PI * 6.0f / 8.0f, Vector3(0.0f, 0.0f, 1.0f));
BallSocket* leftThighBodyJoint = Simulation::getSingleton().createBallSocket("LeftThighBodyJoint",
leftThigh,
body,
DudePosition + Vector3(20.0f, -32.0f, 0.0f));
leftThighBodyJoint->setLowerLimit(0.0f);
leftThighBodyJoint->setUpperLimit(NE_PI/4.0f);
leftThighBodyJoint->setLimitEnabled(true);
leftThighBodyJoint->setLowerTwistLimit(0.8f);
leftThighBodyJoint->setTwistLimitEnabled(true);
// Right Leg - Thigh Joint
q.FromAngleAxis(-NE_PI * 0.5f, Vector3(0.0f, 0.0f, 1.0f));
Hinge* rightLegThighJoint = Simulation::getSingleton().createHinge("RightLegThighJoint",
rightLeg,
rightThigh,
DudePosition + Vector3(-20.0f, -95.0f, 0.0f),
q);
rightLegThighJoint->setLowerLimit(0.0f);
rightLegThighJoint->setUpperLimit(NE_PI/2.0);
rightLegThighJoint->setLimitEnabled(true);
// Left Leg - Thigh Joint
q.FromAngleAxis(-NE_PI * 0.5f, Vector3(0.0f, 0.0f, 1.0f));
Hinge* leftLegThighJoint = Simulation::getSingleton().createHinge("LeftLegThighJoint",
leftLeg,
leftThigh,
DudePosition + Vector3(20.0f, -95.0f, 0.0f),
q);
leftLegThighJoint->setLowerLimit(0.0f);
leftLegThighJoint->setUpperLimit(NE_PI/2.0f);
leftLegThighJoint->setLimitEnabled(true);
// Create the bullet
bullet = Simulation::getSingleton().createDynamicSphere("bullet", // Name
"sphere100.mesh", // Mesh
"Demo/Scales", // Material
Vector3(1000.0f, 25.0f, 1000.0f), // Position
Quaternion::IDENTITY, // Orientation
String::BLANK, // Surface
50.0f, // Diameter
25.0f, // Mass
false); // Create a debug object
bullet->scale(50.0f / 100.0f, 50.0f / 100.0f, 50.0f / 100.0f);
// Prevent the bullet from rolling forever
bullet->setAngularDamping(0.0025f);
// Return the bullet
return bullet;
}
The next step for me is to rig the robot.mesh/skeleton up with this rag-doll, and throw it down the stairs! Might take a couple of days ....I only get an 1 hour or so per day on this stuff
- sinbad
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
- Contact:
- staringmonkey
- Greenskin
- Posts: 116
- Joined: Wed Dec 10, 2003 4:42 am
@KayNine
Kick ass! I will give that code a run later today (have class now ). About setting iterations, I played with that and it looked to me like it worked without being in the constructor. I tried to test all the joint features and from what I could tell on the position/orientation, type, and (in the case of Hinge joints) length needed to be setup early. Limits, Damping, Iterations, etc. all seemed to work fine when setup after the joint had been initially enabled. As for the obvious question of why I don't just do it that way anyway? Well, it's mostly because I want to keep uniformity throughout the lib and everything else can be setup with a single function call. I'd really like to maintain that if possible.
@Sinbad
Lol Ill see about getting that for you.
Now I'm off to class for a few hours, keep up the good work everyone.
[Edit] One final thing, I can't guarantee any updates the next couple days unless someone finds a bug, because I'm working on my website so that I can put up some binaries and screenshots for OgreTok. I've had a few requests for such things. [/Edit]
staringmonkey
Kick ass! I will give that code a run later today (have class now ). About setting iterations, I played with that and it looked to me like it worked without being in the constructor. I tried to test all the joint features and from what I could tell on the position/orientation, type, and (in the case of Hinge joints) length needed to be setup early. Limits, Damping, Iterations, etc. all seemed to work fine when setup after the joint had been initially enabled. As for the obvious question of why I don't just do it that way anyway? Well, it's mostly because I want to keep uniformity throughout the lib and everything else can be setup with a single function call. I'd really like to maintain that if possible.
@Sinbad
Lol Ill see about getting that for you.
Now I'm off to class for a few hours, keep up the good work everyone.
[Edit] One final thing, I can't guarantee any updates the next couple days unless someone finds a bug, because I'm working on my website so that I can put up some binaries and screenshots for OgreTok. I've had a few requests for such things. [/Edit]
staringmonkey