ODE Middleware

Return to Code Snippets

Postby coppertop » Thu Jul 21, 2011 5:41 pm

This "phenomenon" occurs the instant the KCC touches the ground (confirmed with visualization)

Always?

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

I could make a video, or some pictures; would either of those help?

A video would be nice. I'm not sure how helpful it would be, but worth a try.

To be honest, I have no idea what happens. The bad news is that I currently have no access to my desktop computer and limited access to the Internet (make-over at my apartment), so that might make tracking it down a little more difficult.

Please try commenting out the moving platform code in kcc.py to eliminate one possible cause.

Thanks again for supporting your library

I do what I can ;).
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby DangerOnTheRanger » Fri Jul 22, 2011 1:54 pm

coppertop wrote:
This "phenomenon" occurs the instant the KCC touches the ground (confirmed with visualization)

Always?

Always.
coppertop wrote:
I could make a video, or some pictures; would either of those help?

A video would be nice. I'm not sure how helpful it would be, but worth a try.

Okay, I'll make a video. How would you like me to send it to you?
coppertop wrote:
To be honest, I have no idea what happens. The bad news is that I currently have no access to my desktop computer and limited access to the Internet (make-over at my apartment), so that might make tracking it down a little more difficult.

Please try commenting out the moving platform code in kcc.py to eliminate one possible cause.

Thanks again for supporting your library

I do what I can ;).


I just tried commenting that code out, the KCC still "slid" off the ground. Also, in case this can't be solved too quickly (I'm trying to release my project [again] in 2-3 days), would replacing the KCC with a staticObject be a viable, interim solution?
Last edited by DangerOnTheRanger on Fri Jul 22, 2011 2:48 pm, edited 1 time in total.
User avatar
DangerOnTheRanger
 
Posts: 240
Joined: Fri Aug 27, 2010 4:59 pm

Postby coppertop » Fri Jul 22, 2011 2:40 pm

Also, in case this can't be solved too quickly (I'm trying to release my project [again] in 2-3 days), would replacing the KCC with a staticObject be a viable, interim solution?

I wouldn't say so. A static object won't work as a character controller. You would basically need to rewrite those parts of the KCC that you need. The thing is, the KCC's behavior is almost 100% custom, including all reactions to collisions.

However, if what you say happens always, in any and all test cases, on any map, then this is seriously strange, because it would certainly manifest itself for me too. And all others.

I have to ask. I assume you've modified the code. How deep are the modifications?

Sorry, but I'm a bit lost here. I've done a lot of testing and never experienced anything like that.

Also, which version of Panda and under which OS are you using? I found that ODE can behave differently between versions and systems.

Another question is, since you want to release your game in a couple of days, I assume you've been working on it for some while now. Is this a new bug, or was it there since the beginning?

Don't get me wrong, I'm not pointing at you, I'm just trying to eliminate possible causes. Especially since I can't reproduce this bug.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby DangerOnTheRanger » Fri Jul 22, 2011 2:51 pm

coppertop wrote:
Also, in case this can't be solved too quickly (I'm trying to release my project [again] in 2-3 days), would replacing the KCC with a staticObject be a viable, interim solution?

I wouldn't say so. A static object won't work as a character controller. You would basically need to rewrite those parts of the KCC that you need. The thing is, the KCC's behavior is almost 100% custom, including all reactions to collisions.

However, if what you say happens always, in any and all test cases, on any map, then this is seriously strange, because it would certainly manifest itself for me too. And all others.

I have to ask. I assume you've modified the code. How deep are the modifications?

Sorry, but I'm a bit lost here. I've done a lot of testing and never experienced anything like that.

Also, which version of Panda and under which OS are you using? I found that ODE can behave differently between versions and systems.

Another question is, since you want to release your game in a couple of days, I assume you've been working on it for some while now. Is this a new bug, or was it there since the beginning?

Don't get me wrong, I'm not pointing at you, I'm just trying to eliminate possible causes. Especially since I can't reproduce this bug.


The only modification I've made (at least right now) is removing the need for map.py.

I'm using Panda 1.7.2, on Ubuntu 10.04.

I can't really say if this is a new bug or not; I only decided to use the KCC a week or so ago :(
User avatar
DangerOnTheRanger
 
Posts: 240
Joined: Fri Aug 27, 2010 4:59 pm

Postby coppertop » Fri Jul 22, 2011 3:09 pm

I'm using Panda 1.7.2, on Ubuntu 10.04.

That's the same I use... What the hell?

Does it happen with the default release for you?

Can you show me (on a PM or email, if you so wish) the code where you initiate the KCC along with that where you create the ground object?

Another thing I haven't asked about. Is there any way to stop the KCC once it stops sliding? I don't know, jumping, pressing movement keys, crouching?

Sorry for the flood of questions with no proposed solution, but since I have no way of recreating it, I also have no way of tracing it down and solving other than asking you stuff that I hope can help.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby nano13 » Mon Aug 22, 2011 11:55 am

First i would like to thank you for this great work.

I have a Problem with copperode 1.2.x on my system (arch linux):

when i try to run main.py, i get the following error message:

Code: Select all
LOADING
  type: position
  node: render/map.egg/-PandaNode/GrenadePos.008
Creating: grenade
LOADING
  type: position
  node: render/map.egg/-PandaNode/GrenadePos.009
Creating: grenade
LOADING
  type: chair
  node: render/map.egg/-PandaNode/Chair
LOADING
  type: position
  node: render/map.egg/-PandaNode/BoxPos.097
Creating: box
LOADING
  type: position
  node: render/map.egg/-PandaNode/BoxPos.090
Creating: box
LOADING
  type: position
  node: render/map.egg/-PandaNode/BoxPos.091
Creating: box
LOADING
  type: position
  node: render/map.egg/-PandaNode/BoxPos.092
Creating: box
LOADING
  type: position
  node: render/map.egg/-PandaNode/BoxPos.093
Creating: box
Enabling player input

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4() [../../include/ode/odemath.h]
Abgebrochen


I have version 1.7.2 of panda3d, and version 1.0.1 of copperode works fine, but i would like to switch to 1.2.1

edit:
i have traced back the problem until:
Code: Select all
self.world.quickStep(self.stepSize)


line 1518 in odeWorldManager in simulationTask(self, task):

I think, that is not a very big help, the error is somewhere inside ode, but in the older versions of copperode (<= 1.0.1) it was not triggered.

edit2:
i have tried the latest cvs-version of panda3d, the same error.
Last edited by nano13 on Mon Aug 22, 2011 2:12 pm, edited 1 time in total.
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby coppertop » Mon Aug 22, 2011 2:07 pm

What OS are you using?
Did you try version 1.0.1 on the same OS and the same Panda install?
Is what you're trying to run the standard demo, or some custom scene made by you?
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby nano13 » Mon Aug 22, 2011 2:14 pm

coppertop wrote:What OS are you using?

arch linux
http://www.archlinux.org/

Did you try version 1.0.1 on the same OS and the same Panda install?

yes

Is what you're trying to run the standard demo, or some custom scene made by you?

the standard demo
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby coppertop » Mon Aug 22, 2011 2:48 pm

Ach, sorry, somehow I missed that you've given the name of the OS. I'm a little tired ATM, so my bad :)

Anyway, that might complicate the case a little bit, because I'm on Ubuntu and using the standard Panda package. You, however, had to build it from source, I assume, and ODE seems to be rather delicate. Differences in how it's built may cause such errors, which, as you can see, are not the most descriptive in the world ;).

If you know how to use it, you could try throwing pdb, the python debuger, at it and see what comes out. I don't remember how helpful it was in case of these errors (I encountered them many times in the past), but it's worth a shot.

In any case, though, it would be useful to add some more debug prints to the code. I might take a moment and add some more to the actual release, because in cases like this they would help a lot. But before I do, you will have to help yourself to it.

Please go through the Player and the KCC files and add messages like this:
Code: Select all
print "ClassName -> MethodName"

to the methods that either enable, disable or update something. If you find some other place you think they could be useful at, add them there too.

Ideally, you could place those in between the update methods' instructions too, that way we could hopefully nail down the problem that much faster.

Sorry for the inconvenience, but that's the only way to go. Those ODE error messages basically say nothing and I'm absolutely incapable of reproducing the error here...
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby nano13 » Mon Aug 22, 2011 3:41 pm

coppertop wrote:Please go through the Player and the KCC files and add messages like this:
Code: Select all
print "ClassName -> MethodName"

to the methods that either enable, disable or update something. If you find some other place you think they could be useful at, add them there too.

Ideally, you could place those in between the update methods' instructions too, that way we could hopefully nail down the problem that much faster.


I already did something similar, and get that the problem starts with:

odeWorldManager -> simulationTask
Code: Select all
   def simulationTask(self, task):
      self.space.collide("", self.handleCollisions)
      #self.world.quickStep(self.stepSize)
      self.contactGroup.empty()


without the quickStep-line it works fine, but without any physics-simulation.
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby coppertop » Mon Aug 22, 2011 4:21 pm

Yes, I know, but that's not helpful at all, unfortunately. I was hoping there was at least something more that could lead to the cause. At least on the pdb side, if you're tried it. But I guess that was just wishful thinking.

If you haven't so far, you could try using gdb instead of pdb. That could provide a more complete traceback.

The problem is, inside the quickStep method there's little but ODE itself, with it's marvelous error messages, so the only way to debug this is the most tedious way possible. That means, commenting out everything the code does (going from the map file) and then going through it uncommenting things, one by one. That eventually leads to the one line that causes the problem.

You see, the quickStep method only does the physical simulation, as you have already figured out, which means that what causes the error can be literally anywhere in the code, because running the simulation is the last thing the code does when starting itself.

However, since 1.0.1 works, the problem almost certainly is in those parts that were most changed for 1.2.0 (Captain Obvious to the rescue).

If I had to guess (and I have to), I would point at the double capsule in the KCC. Since 1.2.0 there's an additional "dynamicCollider" capsule there, which might be interfering somehow.

The second guess would be the KCC size changing mechanics.

Another probable contestant would be the improved CCD.

So, anyway, the first thing you should do (aside from uncommenting the quickStep line ;) ) is remove all of the CCD dynamic objects. If it runs, we will know it was CCD or something around it. If not, remove the KCC (the Player controller) and see what happens then.

All of that is created in the map file.

If it doesn't run with both of those removed, then we will think what to do next.

It could also be a good idea to try and build ODE with different settings. As I said, ODE is terrible when it comes to building it -- for instance, the Ubuntu's package doesn't work with Panda at all, IIRC. I have also had problems (sometimes very strange) before caused by differences in how Windows, Ubuntu or a new Panda package was built in that regard. Obviously, I'm not saying it's not a bug in the code, but it as well may be the build. After all, it works on Panda packages for both Windows and Linux.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby nano13 » Mon Aug 22, 2011 5:04 pm

Thank you very much for your help!

inventory/pickables.py
pickableObject -> setupGeomAndPhysics

line 76:
self.map.worldManager.addObject(self)

if i comment this out (and only this), it is working, but surprise, the physical simulation wont work.

#########################################################

if everything else is untouched, only the following:

map -> position
Code: Select all
item = node.getTag("item")
      
      if item == "box":
         asset = "bla"#pickableBox()
      elif item == "ball":
         asset = "bla"#pickableBall()
      elif item == "grenade":
         asset = grenade()
      elif item == "door":
         asset = door()
         asset.state = "close"
         
      elif item == "gun":
         asset = gun()
      elif item == "rifle":
         asset = assaultRifle()
      elif item == "shotgun":
         asset = "bla"#shotgun()
         
      elif item == "movingPlatform":
         asset = movingPlatform()

      if asset != "bla":
         asset.setupGeomAndPhysics(self, pos, quat)
         asset.showCCD = self.defaultShowCCD



it workes.

if i load one of the entities "box", "ball" or "shotgun", it crashes.

The entities "grenade", "door", "gun", "rifle", "movingPlatform" works.

Have you changed in this part of the code something since copperode 1.0.1?

I think, we now now, that the problem is not in the kcc or something player-related at all.
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby nano13 » Mon Aug 22, 2011 5:25 pm

If i play with the grenades in this scenario (without the entities: "box", "ball" or "shotgun")
sometimes the game randomly crashes, when a grenade is exploding.

error message is the same as always
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby coppertop » Mon Aug 22, 2011 5:29 pm

This means it's most probably related to the CCD. At least in part. Since it only happens for the box, ball and shotgun, it must be the specific settings on those objects that cause this crash.

To verify, you could change it to use dynamicObjectNoCCD instead of dynamicObjectCCD. This should be trivial (although, now that I think about it, I don't remember how much effort I put into making sure dynamicObjectNoCCD actually works... I focused on the CCD). It should only require you to go into the odeWorldManager file, go to line 970 and change it like this:
Code: Select all
global dynamicObject
dynamicObject = dynamicObjectNoCCD


This will make everything fall through everything, but at least it will make it clear that the problem is found. Then, it might be a matter of tweaking the CCD settings. At least I hope it's nothing more serious than that, but since it works for some objects and doesn't for some others, it should be that.

EDIT:
About the grenades. This could be the same problem. If the CCD doesn't want to work with your build (I still think it might be some rouge setting, it happened a few times to me), then it may be causing problems when stuff is pushed by explosions.

If it's not that, though, I'd like to know if you notice anything spinning or speeding up out of control right before the game crashes after a grenade explosion? If so, that might be a common ODE problem, although I'm almost certain I've eliminated it in 1.2. I might be wrong, though and I will check it later. Right now, let's focus on the main objective.

EDIT #2:
It seems like I haven't changed it. If the explosion crash isn't caused by the CCD (and it's possible that it is), then another possible cause might be the common ODE problem with spinning long and thin box bodies. Fortunately, there's a rather simple solution that seems to work -- instead of box bodies, use sphere bodies.
Last edited by coppertop on Mon Aug 22, 2011 5:49 pm, edited 1 time in total.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby nano13 » Mon Aug 22, 2011 5:43 pm

Mission accomplished, but it still crashes, when i try one of the entities in question
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby coppertop » Mon Aug 22, 2011 6:00 pm

That's interesting. In a way, that's good news. This means the complicated code for the CCD might not be the source. Try something else.

Go into pickables.py, line 61.

Change it to something like this:
Code: Select all
if self.shape == "box":
   self.setBoxGeom(self.geomSize)
   self.setBoxBody(3.82, (0.049, 0.870, 0.218))
elif self.shape == "sphere":
   self.setSphereGeom(self.geomSize)
   self.setSphereBody(self.weight, self.geomSize)


For now, we leave the box and sphere bodies (not switching to pure spheres), because we're investigating only the original problem.

Also for now, I'd like you to only focus on the boxes (as in the pickable box objects). Leave everything else (including the stuff that works) out for now.

The stuff passed, hardcoded, to setBoxBody is from the assult rifle, which seems to work. So if that makes the boxes work, you can uncomment the gun in the map file. If again it works, we'll know that it's the sizes.

If not, we're back where we started...
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby nano13 » Mon Aug 22, 2011 6:21 pm

coppertop wrote:Change it to something like this:
Code: Select all
if self.shape == "box":
   self.setBoxGeom(self.geomSize)
   self.setBoxBody(3.82, (0.049, 0.870, 0.218))
elif self.shape == "sphere":
   self.setSphereGeom(self.geomSize)
   self.setSphereBody(self.weight, self.geomSize)




Now the following works:
grenade, gun, assaultRifle, shotgun (but shotgun and assaultRifle works not simultaneously)

the boxes still does not working, but because of the shotgun now is, i think it still could be the sizes.
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby coppertop » Mon Aug 22, 2011 6:45 pm

If you're sure you're not using CCD right now, then it just must be a nuance in your ODE build. And I think I know what it's triggered by.

It would also explain why 1.0.1 works, while 1.2.x doesn't. You see, in 1.2.0 a way to change the size of the capsule was introduced. This made it possible to bring the whole map to the right scale (hence the name of the blend file shipped -- map_correct_scale.egg).

This, in turn, made everything much smaller. To find out how much, you can compare the blend files. You could even import, for instance, the tunnel object from 1.0.1 into map_correct_scale. It's almost as big as the whole scene for 1.2.1 ;).

I'm guessing that object of this new, small, size may not be handled properly unless some option is enabled.

The good news is that you can still use 1.2.x. The only thing you need to do is either find what that option is (if you ask on this forum, someone should know. Rdb most probably will, because he builds Panda) and rebuild ODE or... make everything bigger. You would, however, need to re-size the map in Blender and reexport the result into Egg. I'm not sure if the map from 1.0.1 would work with 1.2.x, so copying the map egg file might not be an option, but you could try. You would also need to copy the geom and body sizes from 1.0.1.

That way it should work, but obviously getting the build to support small stuff is the better way to go.

In fact, I now recall that I had a similar problem when I was working on 1.2.0 on the Panda build, and then it was fixed with some new ODE configuration option. Or it's just my memory playing with me...
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Postby nano13 » Mon Aug 22, 2011 7:15 pm

Thanks a lot so far!

I will try a new build maybe tomorrow, and i will report my results.

What i would like to know is, what do you call "correct scale"?
What is your reference for the definition of it in panda3d?
nano13
 
Posts: 8
Joined: Mon Aug 22, 2011 11:25 am

Postby coppertop » Mon Aug 22, 2011 7:25 pm

Code: Select all
What i would like to know is, what do you call "correct scale"?
What is your reference for the definition of it in panda3d?

Good point ;D.

Well, in reality that's quite arbitrary, true, that's why you could just make stuff HUGE and it would still work just fine, nobody would notice, as long as proportion is retained. So that "correct scale" is, in fact, an unfortunate choice of words.

That said, what I meant was 1 Panda unit = 1 meter. I think this could be called the "correct scale", because I would expect that's what most people use.

The problem with how the 1.0.1 demo was made was that the units were unrelated to anything in the real world. It wasn't meters or anything else, all I cared about in that version (and the ones before it) was finding a scale that worked for the KCC and fitting everything proportionate to that.
User avatar
coppertop
 
Posts: 527
Joined: Sat Apr 18, 2009 5:48 am

Re:

Postby Mehnix » Wed May 29, 2013 1:06 pm

coppertop wrote:
while walking on the roof player sometime's shifts forward for some distance.

This is probably caused by the room's trimesh. ODE is quite sensitive in this regard, so the models for trimeshing must be very nice and clean, otherwise you get strange results sometimes. I will update the map asap with a better version.

when lamp is switched off, FPS meter shows ~120, when I switch a lamp on - framerate drops to ~58-60.

That's related to lighting and shaders. When you look into the main.py file you'll see that there's render.setShaderAuto(). If you disable that you'll get much better performance at the price of much worse looking flashlight effect. There might be a way to deal with that to some extend (you will always get a frame drop), but I haven't looked into that yet.
On faster graphic cards it obviously shouldn't be an issue.

player walk's through the desk sometimes

Oh... That's interesting. Can you provide more details in what situations this happens? It might be, again, related to trimesh -- with ODE it's much better to use in-engine shapes. I used the trimesh extensively in this sample only because I needed a working environment quickly up and running for codding.

btw, should there be shadows in this sample?

No, this is not supposed to look pretty ;). There aren't even static shadows there.

However if you say It'll happen everytime then I will tell you that that ODE can behave differently between versions and systems.
Mehnix
 
Posts: 1
Joined: Wed May 29, 2013 12:42 pm

Re: Re:

Postby Boldagiri » Wed May 29, 2013 3:26 pm

Mehnix wrote:
coppertop wrote:
while walking on the roof player sometime's shifts forward for some distance.

This is probably caused by the room's trimesh. ODE is quite sensitive in this regard, so the models for trimeshing must be very nice and clean, otherwise you get strange results sometimes. I will update the map asap with a better version.

when lamp is switched off, FPS meter shows ~120, when I switch a lamp on - framerate drops to ~58-60.

That's related to lighting and shaders. When you look into the main.py file you'll see that there's render.setShaderAuto(). If you disable that you'll get much better performance at the price of much worse looking flashlight effect. There might be a way to deal with that to some extend (you will always get a frame drop), but I haven't looked into that yet.
On faster graphic cards it obviously shouldn't be an issue
.


player walk's through the desk sometimes

Oh... That's interesting. Can you provide more details in what situations this happens? It might be, again, related to trimesh -- with ODE it's much better to use in-engine shapes. I used the trimesh extensively in this sample only because I needed a working environment quickly up and running for codding.

btw, should there be shadows in this sample?

No, this is not supposed to look pretty ;). There aren't even static shadows there.

However if you say It'll happen everytime then I will tell you that that ODE can behave differently between versions and systems.

Can you prove what you said ? ODA can behave differently between versions and systems ...I don't think so :-P
Boldagiri
 
Posts: 1
Joined: Wed May 29, 2013 3:19 pm

Re: ODE Middleware

Postby stereoscopic » Mon May 11, 2015 12:37 pm

getting an error.
for childNode in branch.getChildren():
AssertionError: !is_empty() at line 345 of panda/src/pgraph/nodePath.cxx
Here's to the crazy ones, the misfits, the rebels, the troublemakers, the round pegs in the square holes, the ones who see things differently.
stereoscopic
 
Posts: 71
Joined: Tue Jan 13, 2015 3:44 pm

Re: ODE Middleware

Postby rdb » Mon May 11, 2015 1:06 pm

You're calling getChildren() on an empty NodePath.
rdb
 
Posts: 11118
Joined: Mon Dec 04, 2006 5:58 am
Location: Netherlands

Re: ODE Middleware

Postby ramseydonovan » Sat Mar 04, 2017 9:21 pm

I am getting the same error as stereoscopic when running main.py,

Assertion failed: !is_empty() at line 345 of panda/src/pgraph/nodePath.cxx
Traceback (most recent call last):
File "/copperode 1.2.1/main.py", line 138, in <module>
m.startGame()
File "/copperode 1.2.1/main.py", line 125, in startGame
self.map.create()
File "/copperode 1.2.1/system/map.py", line 63, in create
self.processBranch(self.mapRootNode)
File "/copperode 1.2.1/system/map.py", line 117, in processBranch
for childNode in branch.getChildren():
AssertionError: !is_empty() at line 345 of panda/src/pgraph/nodePath.cxx


We know we are calling .getChildren() on an empty node but we do not know why it is empty. We dont fully understand "-PandaNode" in map.egg, we cant find PandaNode anywhere in the file. Any help would be appreciated.
ramseydonovan
 
Posts: 1
Joined: Thu Mar 02, 2017 9:50 am

Previous

Return to Code Snippets

Who is online

Users browsing this forum: No registered users and 3 guests

cron