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
Wumpee
Gnoblar
Posts: 1
Joined: Sat Aug 02, 2003 5:48 am

Post by Wumpee »

neT3 is a 4x4 row based transformation matrix. Ogre::Matrix4 uses columnar transformation matrices, so you need to transpose an neT3 before passing it to / from any ogre methods.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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

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

Post by staringmonkey »

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

Post by staringmonkey »

Ok, a fix has been committed for ALL outstanding issues on my TODO list, except for SubMesh testing. New features/fixes:
  • 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. :P 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.
I'm sure all the people who are using OgreTok on something approaching a regular basis will be at least a little irritated by the change of names for all the cylinder-related classes and files. I really do apologize for this, I tried my best to structure the class/files so that I would never have to do that, but this is an in-development project and this was something I couldn't possibly foresee.

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

Post by KayNine »

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.

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);	
Also, I've recreated RadDude, but he flys to pieces after hitting the ground when I use limits. Adding....

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

Post by staringmonkey »

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.
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: Also, I've recreated RadDude, but he flys to pieces after hitting the ground when I use limits. Adding....

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

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

Post by KayNine »

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.
Excellent, thanks.
As a debugging procedure, I would try only setting one limit and seeing how things behave (if your not already)
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.
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
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.

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

Post by Slicky »

If anyone gets something bashed together of what they are working on I would love to see some screenshots in this thread.
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.

The pic is a test vehicle with 6 wheels on a ramp.

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

Post by staringmonkey »

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.
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: 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.
My thoughts exactly. :)

@Slicky

That looks really good man! :) Glad it's working for you!

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

Post by staringmonkey »

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

Post by staringmonkey »

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

Ah cool on the trimesh fix. Does that mean for example that the box with the submeshes works ok now? I'll give it a spin. I've been busy creating a fresh base app since I did my initial testing within the Ogretok demo :wink:
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

Slicky wrote:Ah cool on the trimesh fix. Does that mean for example that the box with the submeshes works ok now?
Yep, tested with it, works great. :D

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

Post by KayNine »

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.

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;
}
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!).
KayNine
Halfling
Posts: 71
Joined: Wed Dec 03, 2003 10:53 am
Location: Adelaide, Australia

Post by KayNine »

Mmmm, well replacing the above joint code with original Tokamak code...

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

Post by KayNine »

Woo hoo. Adding

Code: Select all

		// Set the Joint Length
		mTokamakJoint->SetJointLength(100.0f);
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.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

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

Post by KayNine »

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

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

Post by staringmonkey »

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.
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: [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.
Done. ;)
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
Unspecified does seem to be the name of the game with regards to physics, doesn't it. :P

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

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

Post by staringmonkey »

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

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
K9

Post by K9 »

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.

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;
}
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 :-(
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 »

I'm jigging up and down on the spot at the thought of a stair/truck dismount demo on Ogre :) Keep it up chaps, you rock.
User avatar
staringmonkey
Greenskin
Posts: 116
Joined: Wed Dec 10, 2003 4:42 am

Post by staringmonkey »

@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 :D 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
Locked