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 =)
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.
True thing 
A new version (0.9) has been released. Please see the first post in this topic for information.
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?
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.
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:
-
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).
-
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.
-
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.
Your welcome. Have fun.
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
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:
(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: ode.org/ode-latest-userguide.html
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
Yes, exactly.
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
Ok I’ve found it.
In the update function of the kcc:
newPos += speedVec*(stepSize*100)There you need to add the (stepSize100)
Then it runs more fluid and the speed is correct =)
blenderkid
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:
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.
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…
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
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
Thanx for spotting that. I forgot to update two things there. Uploaded a fixed version.
No prob, it was very easy to miss.
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.
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
Can you be a little more precise? Which changes are you asking about?
The ladder changes ^^ To get the ladder working