ODE Middleware

Return to Code Snippets

Postby coppertop » Fri Jan 14, 2011 8:27 am

I can't say I fully understand your problem. That is, I think I understand what you're trying to do, but don't fully comprehend how nor what is actually going wrong. I generally avoid using quaternions directly, and instead prefer to extract HPR from them, which I feel a lot more comfortable with.

Still, though, the setQuat() method in the physicalObject (and thus the kinematic object) is just a convenience method. It does nothing more than passing the quaternion to the nodepath and the geom. So there's really not much that could go wrong there.

Now, just to clarify, are you working on an AI vehicle or a car?

In either case, though, if you want smooth turning then perhaps you should take a look into PandaSteer. It might not be 100% what you're looking for, but it might give you some idea of how you can make this using vectors and Panda's lookAt functionality.

Obviously, the easiest way to achieve smooth turns in Panda is to use an HprInterval, but obviously this is not a universal solution and is the most useful for scripting events (such as in-engine cut scenes) rather than anything else.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Stoo » Fri Jan 14, 2011 12:40 pm

Okay, switching to the HPR system fixed it. I just borrowed your setH code from the kcc.py file:

Code: Select all
        quat = self.getQuat()
        hpr = quat.getHpr()
        hpr[0] = hpr[0] + self.rotamt * self.rotspeed
        quat.setHpr(hpr)
        self.setQuat(quat)


Right now, what I'm after is more of a tank - something that can turn whether it's moving or not. I'll be looking at cars and more complicated systems later, when I've got the rest of the game at least sketched out.

Speaking of AI though; do you have any plans to include a basic NPC class in this project at some point? I'm trying to make up my mind which part of my project to sketch out next. :p
Stoo
 
Posts: 16
Joined: Fri Nov 19, 2010 10:34 am

Postby coppertop » Fri Jan 14, 2011 1:36 pm

Speaking of AI though; do you have any plans to include a basic NPC class in this project at some point? I'm trying to make up my mind which part of my project to sketch out next. :p

I'm currently working on AI for my game. However, I'm not writing it from scratch, because it would be reinventing the wheel. Instead, I build it on top of modified versions of two awesome pieces of code -- chombee's PandaSteer2 and et1337's pathfinding code written for his game "Stainless" (GPL2 and MIT licenses accordingly) -- by integrating them with each other and with my code.

With these (and my humble KCC) you can deploy functional NPCs in no time. The biggest change I had to make was replacing the Panda's internal collision detection with my ODE stuff in PandaSteer. Except for that it was mostly tweaking.

Generally, it works quite well already and I'd like to release it aside of my ODE framework, so you can just have basic NPC support OOTB (even though it's not that much work, mostly a matter of integration). However, I don't think I'll find the time to do it anytime soon.

If I were to do it now (or, more realistically, soon), I would have to release it with no documentation, no comments, no sample and no subsequent releases until some time in the future. It would be just bare code. If you're interested in such a "raw" deal, presumably as a starting point for your work, then no problem.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Stoo » Fri Jan 14, 2011 5:28 pm

I would be interested in seeing how you integrate the AI and pathing with the rest of your system; even without the documentation. I *could* just look at PandaSteer too, but if you've already done the work of integrating it... :p
Stoo
 
Posts: 16
Joined: Fri Nov 19, 2010 10:34 am

Postby coppertop » Fri Jan 14, 2011 5:47 pm

Ok, so I'll drop it here as soon as I have a moment.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby coppertop » Sat Jan 15, 2011 12:46 pm

So here is the NPC code I use. I can't say it'll "just work", but it should/might.

http://dl.dropbox.com/u/196274/NPC.zip

I recommend using Recast for navigation mesh generation. It automates the whole process. IIRC the current version should automatically export generated navigation meshes to .obj. I can't attach the one I use, because I've made it by combining code from different revisions, through a process of trial and error, and I'm very surprised it works, so it would probably eat your food.

Note that pathfinding comes from Stainless, which is under the MIT license, and PandaSteer is under the GPL2. Notices inside files. And huge thanks to et1337 and chombee for writing and publishing these pieces of code.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Stoo » Sun Jan 16, 2011 9:20 am

Thanks for putting it up! I'm still digesting how it all works, haven't done much more than look at PandaSteer or Stainless.

Are steerVec.py and vehicle.py the only two PandaSteer classes you've modified, or the only two you've needed in your project? pathfinding.py looks pretty self-contained; and npc.py's easy enough to grok... :p
Stoo
 
Posts: 16
Joined: Fri Nov 19, 2010 10:34 am

Postby coppertop » Sun Jan 16, 2011 10:15 am

Are steerVec.py and vehicle.py the only two PandaSteer classes you've modified, or the only two you've needed in your project?

Yes. They're the essence of PandaSteer, basically. There's also obstacles in the original PandaSteer, but that doesn't really need it's own class in my version -- all you need to do to have an obstacle is add a static/kinematic object with a sphere geom to whatever you want to be avoided by the vehicles. Then you set the bitmask correctly and you're good to go.

The bitmasks should be such that the vehicle's ai capsule collides with obstacles' ai spheres, obviously.

Right now I'm trying to figure out a way to make the most important part of pathfinding-steering interoperability, which is containment on the navmesh. I'm trying to figure out how to keep the agents on the navmesh at all times, because that's extremely important (as the creator of Recast/Detour points out).

As far as the containers that come with PandaSteer, I haven't used them yet, but they don't need to be changed at all to work with my version of PandaSteer (unless I've done something to the containment code and don't remember what ;D).

About pathfinding, yes, it "only" loads the navmesh and allows you to find a path through it, so there was no need to change it to work with my ODE stuff. The only changes I've made to it include better path smoothing and path visualization.

Oh, just note that when you load the navmesh (as egg) it's center MUST be on the world center. Otherwise you will get strange results.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Stoo » Tue Jan 25, 2011 5:12 pm

Okay, so I'm still fiddling with the AI packages, but I'm trying to figure out why you ended up using both of them. Are you using the Stainless pathfinding (via aiVehicle's FollowPath behavior) for gross navigation (from room to room, for instance), and then switching to PandaSteer for fine control?
Stoo
 
Posts: 16
Joined: Fri Nov 19, 2010 10:34 am

Postby coppertop » Wed Jan 26, 2011 7:55 am

Exactly. Pathfinding and steering are two different tools for different purposes. Pathfinding in like GPS -- it can only give you information about when to turn, but it knows nothing about where all the other cars are, so it can't drive for you. That's what your eyes on the road are for in a car, and that's what steering does in AI. It goes in the overall direction of the next path waypoint, while at the same time avoiding, so called, local collisions with other stuff.

So bottom to top it's like this:
1) Pathfinding -- the general set of waypoints to pass through, or (better) a corridor of polygons to stay within.
2) Steering -- avoiding local collisions with dynamic object and vehicles and turning smoothly on the road to the next waypoint
3) Physics and collision detection -- making sure the character doesn't walk through stuff when all of the above fails to prevent a collision.

The thing I still need to work on is keeping the character inside the path corridor and inside the navigation mesh at all times during steering. This is rather complex, for my current standpoint, so it might take a while. Especially that I've currently decided to dive into some other parts of my todo, that've been desperately crying for my attention for months now.

Oh, to make one thing clear. With a dynamic navigation mesh, you *can* make your pathfinding know about dynamic obstacles. Detour does that. However, this is rather complex and even if my skills and time allowed me to extend Stainless' pathfinding by this, I'm not sure python would handle that anyway. Panda AI also has dynamic obstacle avoidance built into pathfinding, but it uses a 2D navigation graph, with which it's a lot easier to achieve (because it doesn't require cutting polygons), but at the same time this type of navigation data is very limited.

Additionally, even with that, you still need steering for interaction between AI vehicles, because no pathfinding can do that.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Stoo » Wed Jan 26, 2011 4:52 pm

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 :p 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!
Stoo
 
Posts: 16
Joined: Fri Nov 19, 2010 10:34 am

Postby coppertop » Wed Jan 26, 2011 5:32 pm

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.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Sticky vs Bouncy

Postby Krush » Mon Mar 14, 2011 2:01 am

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.
- Krush
User avatar
Krush
 
Posts: 58
Joined: Mon Jan 24, 2011 8:13 pm
Location: USA

Postby coppertop » Mon Mar 14, 2011 8:46 am

@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.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Krush » Mon Mar 14, 2011 4:17 pm

coppertop wrote: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 wrote: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?
- Krush
User avatar
Krush
 
Posts: 58
Joined: Mon Jan 24, 2011 8:13 pm
Location: USA

Postby coppertop » Mon Mar 14, 2011 4:33 pm

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: http://opende.sourceforge.net/wiki/inde ... anual_(All)#Joints_and_constraints .
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Krush » Mon Mar 14, 2011 5:29 pm

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.
- Krush
User avatar
Krush
 
Posts: 58
Joined: Mon Jan 24, 2011 8:13 pm
Location: USA

Postby coppertop » Mon Mar 14, 2011 5:35 pm

Actually, I haven't found this :D. Sure it makes a difference. Damn typos! Thanks, I'll update the downloads tomorrow. :)
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Krush » Mon Mar 14, 2011 6:31 pm

Code: Select all
      """
      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.
Last edited by Krush on Tue Mar 15, 2011 12:33 pm, edited 1 time in total.
- Krush
User avatar
Krush
 
Posts: 58
Joined: Mon Jan 24, 2011 8:13 pm
Location: USA

Postby coppertop » Tue Mar 15, 2011 5:30 am

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.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Krush » Tue Mar 15, 2011 12:31 pm

guns.py line 103 was that one I mentioned about 'is' should be 'in'
- Krush
User avatar
Krush
 
Posts: 58
Joined: Mon Jan 24, 2011 8:13 pm
Location: USA

Postby coppertop » Tue Mar 15, 2011 3:40 pm

Thanks. It's fixed.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

question about guns.py

Postby Krush » Wed Mar 23, 2011 8:06 pm

In guns.py you have:
Code: Select all
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.
- Krush
User avatar
Krush
 
Posts: 58
Joined: Mon Jan 24, 2011 8:13 pm
Location: USA

Postby coppertop » Mon Mar 28, 2011 4:14 pm

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.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby Krush » Tue Mar 29, 2011 3:18 am

Another question regarding line 1359 in odeWorldManager.py
Code: Select all
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:
Code: Select all
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.
- Krush
User avatar
Krush
 
Posts: 58
Joined: Mon Jan 24, 2011 8:13 pm
Location: USA

Postby DangerOnTheRanger » Wed May 04, 2011 3:18 pm

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.
User avatar
DangerOnTheRanger
 
Posts: 240
Joined: Fri Aug 27, 2010 4:59 pm

Postby coppertop » Thu May 05, 2011 10:30 am

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.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby DangerOnTheRanger » Wed Jul 20, 2011 8:44 pm

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.
User avatar
DangerOnTheRanger
 
Posts: 240
Joined: Fri Aug 27, 2010 4:59 pm

Postby coppertop » Thu Jul 21, 2011 1:54 pm

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.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby DangerOnTheRanger » Thu Jul 21, 2011 5:08 pm

Well, let's see:
  • The ground does indeed use a staticObject :P
  • 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! :)
User avatar
DangerOnTheRanger
 
Posts: 240
Joined: Fri Aug 27, 2010 4:59 pm

PreviousNext

Return to Code Snippets

Who is online

Users browsing this forum: No registered users and 3 guests

cron