ODE Middleware

Return to Code Snippets

Postby coppertop » Mon Jul 19, 2010 7:19 am

Ok, here's a working version:

Code: Select all
"""
Create a box
"""

box = loader.loadModel("box")
box.setPos(0,-6.0,2.0)
box.reparentTo(render)
#box.flattenLight() -- don't use.
   
boxBody = OdeBody(self.worldManager.world)
M = OdeMass()
M.setBoxTotal(5.0, 1.0, 1.0, 1.0)
boxBody.setMass(M)
boxBody.setPosition(box.getPos(render))
boxBody.setQuaternion(box.getQuat(render))

# Create a BoxGeom
boxGeom = OdeBoxGeom(self.worldManager.space, Vec3(1.0, 1.0, 1.0))
boxGeom.setCollideBits(BitMask32(0x00000122))
boxGeom.setCategoryBits(BitMask32(0x0000111))
boxGeom.setBody(boxBody)

boxData = odeGeomData()
boxData.name = "box"
boxData.isTrigger = False
boxData.surfaceFriction = 0.1

self.worldManager.setGeomData(boxGeom, boxData, box)


And a little bit of explanation.

I use setBoxTotal because it feels better for me, but I've tried setBox and it should work as well (with correct values).

Don't use flattenLight. I don't know why, and I don't know if it's the fault of my code of whatever else, but it seems to produce completely unstable results.

Also, for dynamic stuff try to use meshes that have centers in the middle. The "box" mesh that comes with Panda (with that colorful texture) doesn't, so to see the difference you can use this: http://dl.dropbox.com/u/196274/companion_cube.egg

And try to use built in shapes for dynamic stuff. In some cases it might not make any difference, but trimesh is not the best (not the most stable) choice here.

Check it and inform me of the result.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Mon Jul 19, 2010 1:20 pm

Ok, thank you very much it does not have any crazy behaviour anymore, but the cube still slips on the ground, is that intented to be so?

Thanks in advance
blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Mon Jul 19, 2010 2:51 pm

the cube still slips on the ground, is that intented to be so?

You mean that it slides like on an ice rink? That's a matter of friction set.

I just noticed that this version only takes the ground's friction into consideration. I'm not sure why ATM (since both are added to the contact), so for now just set your ground's friction to a higher value while I investigate on the problem.

FIY, I'm planning a major update to this code. The new version will make it easier to add stuff and bring some other nice features. But there's still some things I need to cross off my to-do list before I can extract the updated framework from the rest of my code and upload it. So just stay tuned.

Also, remember that this is still a work in progress, so keep informing me of any glitches you happen to find.

Thanx for your interest in this code, have fun with it.

Coppertop
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Tue Jul 20, 2010 6:31 am

Ok, I'll have a look =)

I'm now rewriting my whole game and wanted to have another collisionsystem and physics. I found this and I think it is realy realy good and useful =)

You'll find your code in my game, if I am allowed to use it =)

blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Tue Jul 20, 2010 4:21 pm

I'm now rewriting my whole game and wanted to have another collisionsystem and physics. I found this and I think it is realy realy good and useful =)

I'm really glad to read that. I hope you won't be disappointed with it :).

You'll find your code in my game, if I am allowed to use it =)

Everyone is, of course ;). Commercial and non-commercial. The licence, as you probably noticed, is the exact same one as for Panda itself.

Also, I'd love to know what kind of game you're making. It'd be nice to know what this code is used for :).

Have fun with the code,

Coppertop
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Wed Jul 21, 2010 7:49 am

It'll be a multiplayer online FPS game.

here some screenshots: http://filip.hasecke.com/stuff/game-images

The screenshots are all wip (not ingame) images of the models ^^

Do you have an approximate date of the update of your code =) ?


blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Wed Jul 21, 2010 9:17 am

The models look really, really good. I especially like the trees, but the rest looks great too.

As for the release date for the new version, I can't give you anything exact, but I want to make it in a week or two from now.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Wed Jul 21, 2010 11:34 am

Ah, cool 1-2 weeks is very good =)
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby blenderkid » Thu Jul 22, 2010 5:24 am

Hi,

What will be new?

I'd realy like to know that =D, and are there changes in the api of your code?
Just asking that, because I want to start using your code, but I don't know, if I have to redo much, when you release your update =)


Thank you,
blenderkid

BtW: I know now, why the box slipped on the ground... the grounds friction was to low. it was 2.0 I've set it to 200 and there did not slip anything =)
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Thu Jul 22, 2010 6:35 am

Just asking that, because I want to start using your code, but I don't know, if I have to redo much, when you release your update =)

Wait for the new release. It will break backward compatibility, so there is no point in you getting into codding now, since you'd need to do some rewriting. Not that much, but enough to make it pointless to start before the new version.

The stuff that will come with the new release (probably tagged 1.0) includes:
  1. Continuous Collision Detection -- it's not as good as, let's say, Bullet's, but it does it's job, which is to prevent tunneling. CCD is crucial for any shooter or any other game that features fast moving small objects. My implementation is based on casting geoms between the positions in two frames and it supports OdeBox and OdeSphere shapes. It also has visualization of the CCD process. It makes objects act less realistically after they bump off of something because I need to cut velocity on collisions, so it's good enough for shooters and the like, but don't try to make a sports game with it ;).
  2. More Object Oriented approach to object types (static, kinematic, dynamic).
  3. Easily extensible interface for loading egg maps in an "ode-aware" fashion. With that, the code will know what kind of object you want a certain node to be and it will automatically wrap an appropriate class around it. All you need to do is set a tag, or two, in Blender.
  4. Eliminating the need to use TriMesh for environment (except for details that can't be approximated with OdeBox). There's an interface that will get a Cube from an Egg and transform it automatically into a OdeBox (dunno, maybe sphere will come two, but not in this release). I did this because TriMesh is rather unstable, and it's good to limit it's usage
  5. Other: Optimization and ODE's detailed friction model enabled by default.

That's the most important stuff. So, as you can see, you should really wait for the new version. It will bring a lot of stuff and, let me stress this, it will break backward compatibility.

Coppertop

PS.
BtW: I know now, why the box slipped on the ground... the grounds friction was to low. it was 2.0 I've set it to 200 and there did not slip anything =)

Technically yes, but it's all because ODE uses a rather strange friction model by default. It contains a more detailed one though, which can be set with a flag on the OdeContact. As you can read above, this more detailed one is enabled by default in the new version.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Thu Jul 22, 2010 8:55 am

I especially like 3. , that's the way I do most stuff in my game too, like billboard effects, textureanimations, model loading using an empty, loading grass and other repeating plants on special areas, etc...

I am looking forward to see your update =)
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Thu Jul 22, 2010 9:51 am

I especially like 3

Since you're making an FPS, you probably are going to have stuff like grenades, rockets or explosions throwing stuff around, right? ;) If that's the case, you'll eventually like point 1 the most, trust me ;D.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Thu Jul 22, 2010 11:04 am

True thing ;)
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Tue Jul 27, 2010 10:08 am

A new version (0.9) has been released. Please see the first post in this topic for information.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Wed Jul 28, 2010 10:56 am

hi coppertop,

this is an awesome update =)

Now I just need to install a newer panda version... with 1.7.0 it gets slower and slower, as you said ;)

The next days I'll have a closer look at the code and will add it to my game =)

Thank you very much

blenderkid

P.S: Is that now the release I can use for my game, or will there be major changes in the near future?
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Wed Jul 28, 2010 11:51 am

Now I just need to install a newer panda version... with 1.7.0 it gets slower and slower, as you said

Also, since we're on slow downs, if you make your own map, make sure it's closed, i.e. that the world has walls and ceiling so that nothing can fly out of it into the void. The map I included in the sample has, by mistake, no collider of the sky, so if you use a grenade something might fly through the sky and then out of the world. Once in the void, it will start gaining speed and thus slowing things down to a hold (that's because the ccd will need to put more and more stuff between the frame positions). I will update the map as soon as I have a moment, but you can use this oversight of mine as a training task in adding OdeBoxGeoms from Blender ;D.

Is that now the release I can use for my game, or will there be major changes in the near future?

This is a difficult question to answer. This code, as I wrote in the first post, is extracted from the project I'm working on and thus it might see any kind of changes as needed. You must understand that releasing this code here is not my priority ATM.

So far, since the release, the code has seen some minor refurnishing already. The readme PDF mentions that I was planning to ditch the odeGeomData class, and this is exactly what I did. I didn't want to wait with the release, though, since I had no idea how long that would take. It proved to be not that difficult (which is good news actually, since that means it's not that big of a change).

That's why, as you can see, I've decided to tag this release 0.9 instead of 1.0, exactly because I was preparing for that little change.

Is it safe to use it? I guess so. The changes in the API, so far, include ditching odeGeomData in favor of operating strictly on physicalObjects, removing the isTrigger flag in favor of "trigger" value for the objectType variable and not much more actually. Other things are internal and shouldn't affect your code that much.

If you started now and switched to 1.0 once it's released, you'd basically just need to remove all odeGeomData objects from your code, as well as calls to odeWorldManager.getGeomData and .setGeomData methods. To make the future switch less painful, if you decided to start real codding (and not just some testing, prototyping and training) now, keep this in mind:

1) The code will operate strictly on physicalObject class children (it's not required for your classes to inherit from that as soon as they have methods of the same names and contain an objectType variable).

2) The callbacks will be moved into the physicalObject classes themselves, so they won't be assigned to any variables in odeGeomData (which will no longer exist). Thus make sure your selection callback methods are called selectionCallback and your collision callback methods are called collisionCallback. That way you won't need to rename them.

3) Make sure that, in your collision callbacks, you get to physicalObjects as soon as possible and get the geoms and bodies from those objects. That way you can save more time on changing callbacks in the future -- all you will need to do is remove a part of the code.

That's all of the most important stuff I guess. I do a lot of writing and don't usually keep records (except for version control) so I might have forgotten something, sorry if I have.

I'm planning to get 1.0 uploaded sooner than later, but it takes some time to extract and comment the code (I generally don't use comments with Python).

FYI, the 1.0 will contain, aside of much cleaner code (due to the lack of odeGeomData, of course), classes for guns. Pistols, shotguns and assault rifles based on raycasting. You might be interested in those, I guess ;).

I would suggest you only test for now, and not dive into some real codding of the actual game. I will try to get 1.0 up as soon as I can, but surely not before the weekend.

Thank you very much

Your welcome. Have fun.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Fri Jul 30, 2010 1:19 pm

I've read the code today.
And..

Your code is brilliant, well-documented, easy to use and well done =)

I've understood everything =)

Ok, almost everything... I don't understand bitMasks...
Do you know a tutorial or description which bitMask hits which and which not ^^

And is CategoryBits the incoming collision and CollisionBit for the outgoing collision... CatergoryBit for, which can hit the object and CollisionBit for what does the object hit?

Thank you very much - your code will help me realy much!

Blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Fri Jul 30, 2010 1:41 pm

Thanks for the good word. I hope this code will make a good foundation for your work.

As for the BitMasks, the concept is simple (although, I had hard time grasping it at first as well). The names are, actually, irrelevant. They could as well be called value1 and value2 as far as I'm concerned :P. All you need to dig in order to use this mechanism is how the masks are calculated. So here's the equation:

Code: Select all
(cat1 AND col2) OR (cat2 AND col1)


If this is True, the two objects are meant to collide. if not -- they don't. That's the whole philosophy ;). That's why, in my code, I keep all masks the way I do -- that allows me to easily do the calculation in memory for new masks or tweaking the existing ones.

If you want to find out more about it just check the manual here: http://www.ode.org/ode-latest-userguide.html
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Fri Jul 30, 2010 2:19 pm

So, when (cat1 & col2) or (cat2 & col1) != BitMask32(0) they will collide, so:

Just for my understanding =P

BitMask32(0b001) & BitMask32(0b100) do not collide
BitMask32(0b001) & BitMask32(0b101) do collide
BitMask32(0b001) & BitMask32(0b111) do collide
BitMask32(0b101) & BitMask32(0b010) do not collide
and so on...

Thanks

blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Fri Jul 30, 2010 3:23 pm

(cat1 & col2) or (cat2 & col1) != BitMask32(0) they will collide

Yes, exactly.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Sun Aug 08, 2010 5:35 am

Hi,
I think I found some kind of a bug. When the framerate is higher the player speed is higher, a lower framerate causes the player to be slower. But I don't know why, there is a stepsize defined in your code but somehow, when I set the framerate to the highest possible, the game is faster...

Maybe you know why?

Thanks, blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby blenderkid » Sun Aug 08, 2010 5:42 am

Ok I've found it.
In the update function of the kcc:
Code: Select all
newPos += speedVec*(stepSize*100)


There you need to add the *(stepSize*100)

Then it runs more fluid and the speed is correct =)

blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Sun Aug 08, 2010 9:33 am

Thanks for spotting that! I actually have no idea why it was that way... Anyhow, I will make sure to update the package asap. Thanks again.

EDIT:

Let me think aloud ;).

After looking into the code, this issue seems a little strange to me. I can't really reproduce it though, because I'm on a quite slow machine, so I generally have low framerate (I did try it on faster machines though and it seemed right...). Anyway, here's what bothers me.

Your suggestion seems correct, however, it should not be needed. A few lines above the one you posted there's this:

Code: Select all
speedVec = Vec3(self.speed[0]*stepSize, self.speed[1]*stepSize, 0)


So the speed is, in fact, multiplied by stepSize (not in the best way, I admit), which should make it constant regardless of the framerate. I do notice, that this is not the case (especially with very low FPS), but this problem also applies to the rest of the simulation. I.e. when the framerate goes down, the speed of stuff falling down, exploding and so on also goes down as well.

That's, as far as I can tell, probably caused by the way Panda deals with repeating doMethodLater tasks, such as the one I use for stepping the sim -- the real interval between the calls is just not exacly what you set it to be, but rather what the system can keep up with (which shouldn't come as a surprise). Or that's related to how Panda calculates the time -- whether it's real time or some interpolation, or whatever, I have no idea how it's actually done.

Anyway, if I do the change you suggest, the character basically starts moving a lot too fast. That's because of the 100 value. Can you tell me why you see that as necessary?

Also, maybe you've removed/changed the line I posted in the code tags? That would explain the need to multiply by stepSize (but not the need to multiply by 100). Otherwise, I don't see how that would solve the problem.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby coppertop » Sat Aug 14, 2010 4:40 pm

Version 1.0 is up, along with an updated readme pdf.

New stuff includes ditching odeGeomData and a Gun class with some nice features.

Sorry for the gigantic lag between 0.9 and 1.0, but I just couldn't upload it earlier (and I didn't want to do it in a quick and dirty way).

Unfortunately, I still can't figure out that varying simulation speed case...
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Sun Aug 15, 2010 6:42 am

Sorry, I just did not see that line ;)

I'll try the new version in the following days, and will give you a feedback =)

blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby blenderkid » Sun Aug 15, 2010 8:33 am

Hello,

The guns are very good, they don't cause any lag caused by the collisiondetection... as mine did in my first game =/

But the ladder does not work anymore, you don't climb them up but you jiggle when hitting the trigger.

blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Sun Aug 15, 2010 10:49 am

But the ladder does not work anymore, you don't climb them up but you jiggle when hitting the trigger.

Thanx for spotting that. I forgot to update two things there. Uploaded a fixed version.

Sorry, I just did not see that line

No prob, it was very easy to miss.

The guns are very good, they don't cause any lag caused by the collisiondetection... as mine did in my first game =/

Yeah, my first implementation caused a significant lag as well. A shotgun could just freeze everything for a second or so even. That's why I decided to go with a little different approach, a little unusual but much more ODE-ish and much faster (though the performance gain in this case is a little unintuitive perhaps). It's all explained in the pdf.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Sun Aug 15, 2010 11:53 am

Umm, what exactly did you change? I can't find the lines and I'd like to add it to my game =)

Thank you very much

Blenderkid
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

Postby coppertop » Sun Aug 15, 2010 11:57 am

Umm, what exactly did you change?

Can you be a little more precise? Which changes are you asking about?
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby blenderkid » Sun Aug 15, 2010 11:58 am

The ladder changes ^^ To get the ladder working
blenderkid
 
Posts: 85
Joined: Sat Jun 20, 2009 4:15 am
Location: Germany

PreviousNext

Return to Code Snippets

Who is online

Users browsing this forum: No registered users and 2 guests

cron