Okay, so in light of my recent attempts to make the physics engine do its job, I’ve duplicated my test map, and then rewrote the basic flow of object instantiation.
…And the behavoir of the code is identical to that of my issues in my game; The models just sink into the floor, with the exception of sloped edges, where they’ll usually bounce.
I’m putting this up for the sake of trying to find a solution, since I can’t seem to figure it out myself, and I’m getting married in 10 days 
I’ve got a little shortage of free time 
Download it, test it, see what you think might be wrong: http://timvalenta.wordpress.com/panda-physics-test/
While in game, press “enter” to generate a new model, which will pop into the sky and drop to the ground (though he won’t stop there, don’t be fooled). “escape” exits.
Can ANYBODY offer any suggestions?
This is what has already been done:
-Tried different CollisionSolids
-Played with variables on lines 33, 34, 35 (The Friction numbers)
-Check rechecked and rerechecked the association of NodePaths with models, handlers, and traversers…
-Rebuilt it from scratch this evening, to ensure that I had no goofy code from the rest of my game interfering
-Removed all other handlers, so that only the Physics one is in play (the HandlerFloor one didn’t seem to help at all anyway)
First of all, congratulations on your impending wedding! May your marriage be happy and blessed. 
As to your physics issue, my own experimentation with the code that you provided has produced what may be a useful solution for you:
On my end, at least, changing your box collision spheres to no longer collide with visible geometry, instead either leaving their from mask with the default value or assigning it to the arbitrary value of 1, and editing your terrain egg file so that your island is a collision object (with the geometry tagged to nevertheless be visible) produced far more stable results. It is probably, in any case, rather more efficient than having them collide with all geometry.
I’m not sure, but perhaps the problem lay in the box collision spheres colliding with the boxes themselves.
In order to set up the terrain model to be visible collision geometry, you can either use Blender’s object properties functionality or edit your .egg file to include
<ObjectType> { barrier }
<Collide> { Polyset keep descend }
in the appropriate places.
For the former method, with your object selected, go to the Buttons Window, select “Logic” (or press F4) and click on “Add Property” To make the object collision geometry, make the property a string property, name it “ObjectType”, and fill in the value “barrier” (all without inverted commas, of course). I haven’t tried to use the same technique to make such collision geometry visible, but I would guess that the same pattern applies - name the property “Collide” and give it the value “Polyset keep descend”. However, I stand for correction on that.
Thank you-- I do appreciate your reply.
I agree, that making explicit collision geometry may very well help the problem. That being the case though, I’d rather not just use that “Polyset keep descend” thing. That can’t possibly be efficient… I’d rather make simplified geometry with the “barrier” tag.
But for the floors, I was really hoping I could just throw it in “as is”. Maybe i’ll try keeping the ground seperate from all other objects, and then use the barrier/Polyset-keep-descend setup on the floor only. For the most part, there’s absolutely no reason why the collision geometry needs to be as intricate as the visual representations thereof. Besides, visible geometry is in polygons, the most expensive kind of solid, and the most prone to slip-throughs.
I do appreciate the commentary, though. I shall give it a shot.
It’s my pleasure. 
As to polyset keep geometry, indeed, it probably would be less efficient than simplified collision geometry… but it’s probably at least rather less inefficient than attempting to collide with all visible geometry, as you seem to have previously been doing. 
However, if you’re willing to do it, then separate and simplified invisible collision geometry probably would be a good idea for you, depending on how well you make it conform to the shape of the terrain.
Well, that’s more or less what my edit did, if I’m not much mistaken. I didn’t edit the egg file such that all geometry was treated as such; only the island geometry was tagged, as I recall.
touché
My thought though is for the bigger picture: I most certainly would not want to use the “keep” method on an entire map, or even single, complex models because “keep” duplicates the geometry in memory and makes the copy as “Collision” geometry. At least without specifying the “keep” command in the egg file, I’m not doubling the effective size of my egg file in memory.
Fair enough - although, depending on the structure of your terrain mesh, I’m not sure of how much you would gain with a separate lower-polygon-count collision mesh, since you’ll presumably want it to match the terrain fairly well.
Nevertheless, if you’re willing to put in the extra work, that probably is your best bet. If not, then I’d suggest the “polyset keep” method, I think.
Precisely the point, for the terrain-- It would be awfully complex to make simplified geometry for the terrain, since you’d have to make it match up perfectly. That is something that would be best done with the polyset-keep-descend method.
But for buildings, walls, long staircases with handrails… in those cases, there’s going to be parts of the models that I simply couldn’t care less to actually detect collision with them, like a handrail. In a case such as that, I’d be uselessly creating collision geometry over a bunch of handrail polygons that are completely unimportant to the environment.
Though, again, terrain would best be done with those few lines added into the egg file.
Oh yes - fair enough, then. It sounds as though you have a good plan now, then.
Question for you…
Where did you put the “barrier” and “polyset keep descend” stuff? I can’t seem to make it behave any differently when I add those lines.
I put it in your terrain.egg file, here:
<Group> Plane {
<ObjectType> { barrier }
<Collide> { Polyset keep descend }
In case you have trouble finding it (egg files being large things at times), let me elaborate:
Inside your egg file you should find a variety of elements. Skipping the first few, we encounter one that should read (presuming that you haven’t renamed anything) " Sphere". This should be the first of three objects that you have declared in your file, one each for your water plane, sky sphere and terrain, if I recall correctly. If I’m not much mistaken, the sky was named “Sphere”, the terrain “Plane”, and the water “Plane.001” (presumably the primitives that you started off with in each case, with the “.001” suffix having been appended due to the name “Plane” already being in use; it should be possible to change these names in Blender using either the “Object” panel of the "Buttons Window or the Transform Properties box in a 3D view).
Since I wanted to make your terrain “solid”, I went to its “” entry and added the relevant items after the first opening curly-bracket.
However, if you want to do this in Blender, you should be able to do so by going to the Logic Panel of the Buttons Window and giving the terrain model the properties “barrier” and “Polyset keep descend”, with the names “ObjectType” and “Collide” respectively; however, I haven’t tried this for the Polyset keep descend case myself, so I don’t know that that case will indeed work, I’m afraid.
Well, I’ve already tried putting those properties where you’ve just described, and I get the same behavior as without.
It appears to me though that I need to remove the BitMask-setting code from the python source. Once I remove that, then the Collision geometry seems to be respected, and the boxes won’t fall through the floors.
Thanks muchly for the aid–This is exactly the extra help that I needed It’s always good to have a fresh pair of eyes
It’s my pleasure! I’m glad to be of aid.
By the way…
