ODE Middleware

[Stoo]

Just started fiddling with Recast, too - that is an impressive package. I’m not seeing any sort of exported nav meshes though… I suspect that’s part of the version that would eat my food I have seen a few references to people adding export functionality to the demo, so I’d guess it’s a newer function if it is there.

In any case, I think the steering behavior by itself will give me enough to work with short-term; I can add pathfinding once players can do something interesting with my NPCs. Thanks for posting it!

[coppertop]

No problem.

Yeah, the story of exporting in Recast is kinda complicated. First it wasn’t there at all. Then it was added, but I’m not sure if it ever worked well OOTB. Anyhow, given the pace of Recast/Detour development, that’s nothing strange. This stuff is great, but very experimental – even more then Bullet, I guess.

Remember, however, that you can also create navigation meshes by hand – for testing purposes that’s good enough. It would just be a major pain for real, large maps.

[Krush]

What would be the easiest way for me to turn off all the bouncy physics (like the grenade in the example has) and instead make it so the first thing the grenade hits it sticks to?

I’m currently setting up a whole array of weapons and this (once I figure it out) would allow the creation of at least 5 different weapons I can think of right off the bat.

[coppertop]

@Krush

I must admit I haven’t anticipated such mechanics. As I wrote in the first post and in the pdf, this code is patchwork and was never meant to handle everything, and what you’re asking about will expose a number of it’s limitations. Including such that I’ve never thought about.

Still, it all depends on how sophisticated the behavior you need.

If all you need is a single shape that sticks to walls, then it’s very simple. All you need to do is use a callback to know when the geom hit something, and then clear the object, leaving just the visible geometry (you can obviously make it selective too). At the same time, once you cleared it so it doesn’t move, you can set up something new around the collision point to make use of the new stuck-to-something state, for instance: an area trigger to make a mine.

For something that can stick to generic kinematic objects (not the KCC), you would probably want to do the same, but keeping the update method, so you can update the position of the visible geometry and the stuff you set up around it. That way your dynamic object would change into a kinematic-ish object on the fly.

That should work for the simplest scenarios, i.e. a singular object. If you want the thing you throw/shoot to be more complex, for instance having something hanging on a joint (or a set of joints) off the back of it (i.e. something like a meteor hammer), then that will be more problematic or even impossible with the current code.

For sticking to static geometry it shouldn’t be a problem. You would just need to remove the joint connecting the chain with the grenade, replace it with a joint connecting the chain to the environment, and you’re good to go. That way, with some work, you could even make a cannon shooting Half Life’s Barnacles that attach themselves to the ceiling with physically accurate “tongues”.

Note, though, that in such case you would need to use the discreet, instead of continuous, collision detection dynamics variant. My CCD implementation is meant for simple singular objects – compound shapes and joints don’t work there ATM.

However, if you wanted to have a meteor hammer sticking to kinematic (animated) objects, then that’s not possible out of the box. My kinematic stuff was made with animation, collisions and moving-platforms in mind, but not joints; because that’s all I needed. That’s why you can’t attach joints to them (contact joints are a different thing).

In fact, I’ve tried to make that in the past and it should be possible using a body with zero mass, but for some reason this always results in instability, nans, crashes and other bad things happening. Maybe I was just doing something wrong, dunno. My game did not depend on that and I have limited time so I left it out.

I can see that the new version of ODE supports apparently full-featured kinematic bodies OOTB, but it seems like Panda depends on an older version, or just doesn’t expose that functionality. Interestingly, PyODE’s newest snapshot seems to support it, though. That makes me wonder about porting my stuff to it, but even if I do some day, it will sure not be anytime soon. By which I mean probably not this year.

Ok, back to the original point. I’m currently occupied with other stuff so I can’t really tinker with the framework much. However, you could experiment with the old way of making “jointable” kinematics and maybe you can find out how to use that zero mass approach. Unfortunately, that’s currently your only option if you want to have behavior as complex “as stuff with other stuff hanging off of it sticking to script-animated geoms”.

As far as the KCC goes everything written so far about kinematics applies, but there’s yet another layer of complexity. I.e. you would need to make the sticky objects attach themselves to the actual character, and not the capsule. That means the more accurate representation of the character, possibly the one you could also use for hit boxes. Obviously, the capsule stays there for environment collisions, but sticking the grenades to the capsule would look wrong.

[Krush]

@coppertop

I must admit I haven’t anticipated such mechanics. As I wrote in the first post and in the pdf, this code is patchwork and was never meant to handle everything, and what you’re asking about will expose a number of it’s limitations. Including such that I’ve never thought about.

Still, it all depends on how sophisticated the behavior you need.

I think I’ll just start with it being simple and just sticking to the environment and then maybe later see about having it attachable to other objects that might be walking around.

@coppertop

If all you need is a single shape that sticks to walls, then it’s very simple. All you need to do is use a callback to know when the geom hit something, and then clear the object, leaving just the visible geometry (you can obviously make it selective too). At the same time, once you cleared it so it doesn’t move, you can set up something new around the collision point to make use of the new stuck-to-something state, for instance: an area trigger to make a mine.

For something that can stick to generic kinematic objects (not the KCC), you would probably want to do the same, but keeping the update method, so you can update the position of the visible geometry and the stuff you set up around it. That way your dynamic object would change into a kinematic-ish object on the fly.

That should work for the simplest scenarios, i.e. a singular object. If you want the thing you throw/shoot to be more complex, for instance having something hanging on a joint (or a set of joints) off the back of it (i.e. something like a meteor hammer), then that will be more problematic or even impossible with the current code.

For sticking to static geometry it shouldn’t be a problem. You would just need to remove the joint connecting the chain with the grenade, replace it with a joint connecting the chain to the environment, and you’re good to go. That way, with some work, you could even make a cannon shooting Half Life’s Barnacles that attach themselves to the ceiling with physically accurate “tongues”.

Note, though, that in such case you would need to use the discreet, instead of continuous, collision detection dynamics variant. My CCD implementation is meant for simple singular objects – compound shapes and joints don’t work there ATM.

However, if you wanted to have a meteor hammer sticking to kinematic (animated) objects, then that’s not possible out of the box. My kinematic stuff was made with animation, collisions and moving-platforms in mind, but not joints; because that’s all I needed. That’s why you can’t attach joints to them (contact joints are a different thing).

In fact, I’ve tried to make that in the past and it should be possible using a body with zero mass, but for some reason this always results in instability, nans, crashes and other bad things happening. Maybe I was just doing something wrong, dunno. My game did not depend on that and I have limited time so I left it out.

I can see that the new version of ODE supports apparently full-featured kinematic bodies OOTB, but it seems like Panda depends on an older version, or just doesn’t expose that functionality. Interestingly, PyODE’s newest snapshot seems to support it, though. That makes me wonder about porting my stuff to it, but even if I do some day, it will sure not be anytime soon. By which I mean probably not this year.

Ok, back to the original point. I’m currently occupied with other stuff so I can’t really tinker with the framework much. However, you could experiment with the old way of making “jointable” kinematics and maybe you can find out how to use that zero mass approach. Unfortunately, that’s currently your only option if you want to have behavior as complex “as stuff with other stuff hanging off of it sticking to script-animated geoms”.

As far as the KCC goes everything written so far about kinematics applies, but there’s yet another layer of complexity. I.e. you would need to make the sticky objects attach themselves to the actual character, and not the capsule. That means the more accurate representation of the character, possibly the one you could also use for hit boxes. Obviously, the capsule stays there for environment collisions, but sticking the grenades to the capsule would look wrong.

Could you explain what you mean by ‘joints’ do you mean like if there was a human model the joints connecting the various parts of the body?

[coppertop]

I think I’ll just start with it being simple and just sticking to the environment and then maybe later see about having it attachable to other objects that might be walking around.

Yeah, starting simple is usually the good way to go.

Could you explain what you mean by ‘joints’ do you mean like if there was a human model the joints connecting the various parts of the body?

In general, yes, although you shouldn’t confuse that with the joints between the bones in an Actor’s skeleton. The concept (and hence the name) is similar, but the usage is entirely different.

Still, joints are of more general use. Other analogies would include a hinge, attaching a door to its frame in such way that it can be opened; or a suspension arm, attaching a wheel to the rest of the car in such way that the wheel can move up and down on a bumpy road. Generally, it’s something that binds two bodies together, so they can only move in certain ways relative to each other.

You can read about it in here: opende.sourceforge.net/wiki/inde … anual_(All#Joints_and_constraints .

[Krush]

Also, you probably already found this but this line

self.surfaceBrounce = 1.2

in

def setupGeomAndPhysics(self, map, pos, quat=None, hasDamage=True):

of the pickableObject class should be

self.surfaceBounce = 1.2

which gives quite a vast difference of effect when that stack of boxes lands.

[coppertop]

Actually, I haven’t found this . Sure it makes a difference. Damn typos! Thanks, I’ll update the downloads tomorrow.

[Krush]

		"""
		No point hitting triggers or ccd helpers.
		"""
		if object2.objectType is ["trigger", "ccd"]:
			return

This one just bit me unless it’s doing something that I don’t know about (i’m still new to python). I believe that should be an ‘in’ not ‘is’ because you are trying to see if it’s any of them, and not all of them right?

I had copied this code and was using it for my sticky test and couldn’t figure out why it wouldn’t ignore the right things.

Did you have a version control setup for this? I could setup one on assembla.com (I already use it for other things) if not.

[coppertop]

I believe that should be an ‘in’ not ‘is’ because you are trying to see if it’s any of them, and not all of them right?

Yeah, you’re right. Simply another typo. I’m glad you’re reading the code so intently. Sometimes it’s easy to miss stuff like that.

I was thinking about setting up a code repository, but I guess GitHub would be a better place. It has a really nice interface (and a one that many already got used to) and allows downloading stuff easily from the website.

EDIT: For the future – when you find a bug, please give the file and the line. That’s much more helpful than a quote.

EDIT2: Updated the download (1.2.1-1), but I just can’t find the second bug you found. Searched through the code, and couldn’t find that line. Please provide the file name and line number.

[Krush]

guns.py line 103 was that one I mentioned about ‘is’ should be ‘in’

[coppertop]

Thanks. It’s fixed.

[Krush]

In guns.py you have:

class gun(pickableObject, DirectObject):

I was just wondering why you have your gun class deriving from DirectObject? It seems to work without that base class as long as I remove the self.ignoreAll call.

[coppertop]

I don’t remember, to be honest. Probably I used it for something in my game, and forgot to remove that inheritance when extracting the code.

[Krush]

Another question regarding line 1359 in odeWorldManager.py

if body1 or body2 and type1 not in ignoredTypes and type2 not in ignoredTypes:

I’m confused what this if statement is supposed to be doing, because to me it looks like it is making sure that there is at least one body, and that neither type is in ignoredTypes. But when it runs it seems to go into the following code if either type isn’t in the ignoredTypes array.

I noticed this when trying to figure out when I was trying to make a ‘bullet’ seems sometimes when two dynamic objects hit each other the collision callback isn’t triggered (so in my case the bullet sometimes bounces off stuff it should destroy itself on). I’m sure these two things aren’t related but just explaining what made me stumble onto this if statement.

Oh and I tried using () to make the statement the way I thought it was by doing this:

if (body1 or body2) and (type1 not in ignoredTypes and type2 not in ignoredTypes):

but then stuff just starts falling through the world cause statics are ignored.

Thanks for yet another answer.

[DangerOnTheRanger]

This is really nice software! I’ll probably use it for my GDK (eventually).

I have a question, though: Can you separate everything from map.py, so it’s not required to use your middleware? It’s incompatible with how I store worlds/levels, so I’ve had to resort to hacking the code as a workaround.

[coppertop]

Can you separate everything from map.py, so it’s not required to use your middleware?

Actually, it’s not required. You’re meant to modify it, remove it, change it. It’s just there for the thing to work when you want to test it.

I know making it more library-ish would be a better idea (and I wanted to do it initially), but I just don’t have the time to do it. I suspect it would require a lot of designing and analysis, which I just can’t afford. I regret that largely, because it would be awesome to see this code used that way, but life is life.

On a side note, I actually use a different way of managing my maps in my actual game too. I used something more similar to what’s in the snippet back when I released it, but now it’s changed a lot. This map.py file is only there to be relatively simple (tho, I still think it’s too complicated for the purpose) and to make things work so you can test it. But you’re expected to scrap it.

I know this is a big inconvenience…

The alternative, to doing what you’re asking for the right way (i.e. transforming this into a library-ish thing), is basically detaching everything off of each other and putting the code up as a set of unconnected, seemingly unrelated classes. That wouldn’t take much time, but it would be very difficult to understand, I guess, so I don’t see a point in doing that.

[DangerOnTheRanger]

I’d just like to say I’m now using your code successfully in my game development kit, coppertop, and it’s working great!

I’m having a problem with the KCC, though: When my KCC collides with the ground (a staticObject), the KCC suddenly slides quickly towards the edge of the ground.
Any ideas on what the problem might be? I’ve checked that friction is working correctly, so friction can be ruled out.

[coppertop]

I’d just like to say I’m now using your code successfully in my game development kit, coppertop, and it’s working great!

Great to know! I hope it stays that way ;D.

Any ideas on what the problem might be? I’ve checked that friction is working correctly, so friction can be ruled out.

Friction is not used in the KCC at all, IIRC (haven’t taken a look into that code in a while). Only velocity is, but that’s for dynamic and kinematic objects, not for static environment.

On a side note, it’s good to hear that the friction is working correctly ;D.

I can’t really tell what’s happening. I’m not sure if I can imagine the situation right. If you explained the case in more detail and told me how to reproduce it (or provided a small example, because it might be related to the map setup), that could help.

A couple of questions that come to my mind.

Is the ground horizontal, or is there a slide? Maybe stairs?
When exactly does it happen?
Is the ground using an ODE solid or a trimesh?
Is the slide immediate (over one frame), or does it take place over some time?

Also, is there another surface beneath the one you’re standing on? I remember I had a lot of problems with the code misinterpreting collisions with multiple “layers” of objects, especially when trimeshes were used. Maybe you have found a situation I haven’t bumped into.

Are you sure this isn’t the case of input locking? I mean, you strafe, release the button, but the character keeps moving?

Also, what happens when it reaches the edge? If it reaches a wall, does it tunnel through it, or does it stop on it? If it reaches an actual edge of something, does it fall?

EDIT:

Something came to my mind. The KCC takes the linear velocity of the ground into account, in order to work with moving platforms. The code should prevent this in case of static objects, but it you’ve modified it, or if I did something wrong somewhere, it might happen that the ground acts like a “conveyor belt” despite being a static object.

Make sure it actually is a static object (no offence, I know I do such mistakes so it’s good to point at it ;D).

You could also comment out all of the code responsible for the moving platform functionality in the KCC. In the default release, that’s lines 460 to 467 in kcc.py. This could help eliminate one possible cause.

[DangerOnTheRanger]

Well, let’s see:

• The ground does indeed use a staticObject
• The ground is horizontal
• The ground never moves
• This “phenomenon” occurs the instant the KCC touches the ground (confirmed with visualization)
• The ground uses an ODE solid
• The “slide” occurs over at least 10 frames (the actual number of frames depends on how large the ground is)
• There is no other ODE body/solid beneath the ground
• Placing another ODE solid in the path of the “sliding” KCC did nothing; the KCC just went through it
• This can’t be a case of input locking; the KCC is solely under the influence of gravity (no player input)
• The instant the KCC reaches the edge of the ground (the ground is basically a thick plane), it starts to fall

I can’t really provide a quick example (my project is open-source, but I’d probably have to send you my project’s code as well). I could make a video, or some pictures; would either of those help?

Thanks again for supporting your library!