Seems to me like you didn’t set an OdeBody for that cube. Remember that my code is one thing, but you need to create an OdeBody with OdeMass to have an actual Dynamic object. You do that exactly the same way as described in the Panda Manual. The OdeWorldManager only makes the rest of the process automatic (updating positions of 3d models and stuff), but creation of an OdeBody is your job.
Greetings!
I’ve just started using p3d so I search through forum looking for examples to study.
Just tried your code - seems cool for me since it could be a good base for making a game!
I’ve experienced some problems:
- while walking on the roof player sometime’s shifts forward for some distance.
- when lamp is switched off, FPS meter shows ~120, when I switch a lamp on - framerate drops to ~58-60.
- player walk’s through the desk sometimes
I’ve used panda 1.7.0 and directx9 windowed rendering
Other stuff works fine, I think, and I’d like to thank you for the code.
Hi,
~I could be wrong about this, but I think it’s correct~
the reason you see a drop from ~120 FPS to the mid 50s is because lighting requires shaders, which will cut the FPS down to about 50 on most graphics cards, but note that you can probably do infinite lighting without losing the 50 FPS you did before, also your graphics card (if any) may likely have little to no shader support, which may also cause the problem
I think I’ll try to add more light sources to test…btw, should there be shadows in this sample?
About videocard - it’s an old device(2006), but it understands shader model 1…I think=)…at least it has Hardware T&L support…
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.
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.
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.
No, this is not supposed to look pretty 
. There aren’t even static shadows there.
About walking through desk:
It happens accidentally… but I’d like to note 2 cases(when it happens more, I think):
-when player stands up from chair
-when player approaches desk at an angle(I mean at an angle to desk’s bounding box’s sides or something)
I’m sorry but I don’t have my explanation of that 
That’s actually just an animation. If you look into the code for standing up you’ll see, that it’s just the way camera is moved around with simple Panda intervals set on it. You can tune that as much as you want. The actual ode character controller doesn’t take part in this, it’s just an animation.
Seems like I just forgot to make a collider for it ;D. No idea how I missed that… Anyway, I updated it and should be fine now. Hit me back on the result.
Hi,
first of all this is a great script, thank you very much.
I have got a problem adding a Cube:
this is my code
"""
Create a box
"""
box = loader.loadModel("box")
box.setPos(0,0,7)
box.reparentTo(render)
box.flattenLight()
boxBody = OdeBody(self.worldManager.world)
M = OdeMass()
M.setBox(50000, 1, 1, 1)
boxBody.setMass(M)
boxBody.setPosition(box.getPos(render))
boxBody.setQuaternion(box.getQuat(render))
# Create a BoxGeom
boxMesh = OdeTriMeshData(box, True)
boxGeom = OdeTriMeshGeom(self.worldManager.space, boxMesh)
boxGeom.setCollideBits(BitMask32(0x00000122))
boxGeom.setCategoryBits(BitMask32(0x0000111))
boxGeom.setBody(boxBody)
boxData=odeGeomData()
boxData.name = "box"
boxData.isTrigger = False
boxData.surfaceFriction = 0.0
self.worldManager.setGeomData(boxGeom, boxData, box)So there is a cobe added and it is controlled by gravity but, as it hits the ground the box goes crazy and slips on the ground, rotates and is becoming faster and faster till it slips away…
What did I do wrong =/
I also tryed a OdeBoxGeom but that isn’t effected by anything… it just shakes a bit.
Thanks in advance,
blenderkid
My first thought would be that’s because you set the surfaceFriction to zero. Try changing it to a higher value and tell me if it helps.
I’ve tried with friction = 10 / 100 / 1000 and all the same… =(
Ok, here’s a working version:
"""
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: 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.
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
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
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
I’m really glad to read that. I hope you won’t be disappointed with 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
It’ll be a multiplayer online FPS game.
here some screenshots: 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
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.
Ah, cool 1-2 weeks is very good =)
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 =)
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:
- 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 ;).
- More Object Oriented approach to object types (static, kinematic, dynamic).
- 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.
- 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
- 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.
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.