To answer your question more directly: yes, it is undoubtedly more expensive to do 8 collision checks rather than just one. But the choice of solid is orthogonal to the choice of handler: even when you are using a sphere you have the choice of whether to use the pusher or not.
Are you having issues with using a sphere+pusher for the horizontal collisions?
@rdb @Thaumaturge I tried using a pusher for horizontal collisions, my code is here. Press ‘b’, move the building around with arrow keys, press ‘[’ or ‘]’ to size it up/down, and press ‘enter’ to place it, press ‘b’ to turn the building tool off.
The problem is that it doesn’t stop the player from moving, it detects (if you try to go to one of the corners of the building, you fall past the dock) and if you try to walk towards the mountains opposite the river, collision somehow acts up.
WASD to walk around, mouse scroll to zoom in/out, ‘escape’ to exit.
You might want to look at player.py, the building gets initiated from tools.py
I find these two lines particularly suspect:
if (self.playerHolder.getZ() > entry.getSurfacePoint(render).getZ() - 70):
self.playerHolder.setZ(entry.getSurfacePoint(render).getZ() - 130)
I would suggest that you disable the gravity and Z adjustment for now until you’ve got the horizontal collisions working, to rule that out as a potential cause of issues. I don’t think you should be having that upwards check at all.
Normally you shouldn’t check for collisions above the player. One reason I can think you might have done this is because you first apply gravity (which you are doing incorrectly—more on that in a moment) and then you check for vertical collisions, but by that time you might already have positioned the player below the ground. You should first check how far the ground is below the player, and then use that to limit the application of gravity.
The way you apply gravity is that in your task you should increase a velocity variable by globalClock.dt * -9.81, ie. accelerating the object, then you calculate by how much the player should be moved (velocity * globalClock.dt — note how the dt, ie. time since last frame, is multiplied twice, which makes sense because acceleration is in m/s²), and you should limit this by how far the player is above the ground, and if distance is within that limit, you zero the current velocity.
I’ll add the detail that you likely want to place a limit on just how large the velocity vector can become: if you don’t, then a long fall can result in a ridiculous–and potentially problematic–speed.
(It’s also somewhat accurate to physics, at least within an atmosphere and using normal matter: it’s a “terminal velocity”, a velocity at which the force of gravity is balanced by the force of air resistance (if I recall correctly), thus resulting in no change in speed.)
That said, I’m overall inclined to agree with rdb: this looks like it may well be a problem with your vertical-positioning code, gravity included.
In fact, I’m suspicious of the line above both of the places in which you position you character vertically in response to ray-collisions: You’re positioning your object vertically relative to each and every collision that the ray makes, not just the first one. As a result, your object could be placed multiple times, and in ways that conflict with other collisions, potentially resulting in untoward behaviour.
You mention scaling of your building-models, by the way. If that scaling affects their collision-nodes, then that might be a problem, too: scaling and collision-detection can interact poorly, if I recall correctly.
I have disabled gravity and vertical movements, the main reason why I am checking for upward collisions is that I don’t really want the player to fly upwards through an object when using the jetpack, here is the updated code after addressing what was mentioned:
# checking for collisions - downwards
entries = list(self.groundHandler.entries)
entries.sort(key=lambda x: x.getSurfacePoint(render).getZ())
do = False
self.performGravity = False
if self.performGravity == True:
self.velocity -= (deltaTime*9.81)
if self.velocity <= -15:
self.velocity = -15
self.playerHolder.setPos(self.playerHolder, Vec3(0, 0, self.velocity)) # Gravity
if len(entries) > 0 and do:
if (self.playerHolder.getZ()<entries[-1].getSurfacePoint(render).getZ()+8):
self.playerHolder.setZ(entries[-1].getSurfacePoint(render).getZ()+8)
self.velocity = 0
However I am still facing issues regarding horizontal issues with those turned off.
I have also updated the GitHub repository.
I think that it might help a lot to be able to see the collision shapes that are used for the building. Where are those assigned? I didn’t see anything obvious in your code–but there’s a fair bit there to go through, given that I’m not already familiar with it.
By the way, you don’t need to manually sort the entries produced by a CollisionHandlerQueue: it has a “sortEntries” method that arranges the collisions from closest to furthest, I believe. (That is, such that the nearest hit is the first in the list, at index 0.)
I’m using bitmasks.
It also detects without them contacting visually, perhaps I should use a smaller radius for collision sphere?
I’m not sure of the relevance of Bitmasks in this case?
Hmm… Perhaps it’s worth showing the sphere, too, just in case.
If I may ask, where in your repository or code is the collision for the building? I’d like to take a look at it.
I felt it was the most appropriate/fastest/easiest one to implement, would you recommend a better option? I exported it with blend2bam with the built-in physics flag but apparently, it didn’t work.
It was at 1, It showed up when I changed it to 5 so the collision sphere turned out to be small than the actual model.
Look at player.py and around the beginning, you’ll see a section dealing with the collisions for the player model (Line 37) and at line 234 you’ll see the gravityand vertical collision stuff.
objectLib.py contains the small code for bitmasks for the building.
I feel like we’re talking across purposes here.
Bitmasks aren’t a type or method of collision -detection or -response–they’re a means of filtering which objects take part in collisions with each other.
Thus the presence or absence of Bitmasks doesn’t seem likely to be relevant to the problems that you’re seeing.
Ah, yes, that makes sense! And thank you for the recording. 
Got it! I’ll take a quick look there, I think.
[edit]
I’m still not seeing the actual collision-geometry for the building when I look at the contents of the repository. Examining the building models in PView doesn’t seem to reveal any collision geometry, and indeed, printing out their hierarchies or opening the egg-files in a text-editor shows no sign of collision-objects being present. o_0
I’m presumably missing something!
Apologies, I incorrectly remembered where the bitmask stuff is, there is nothing related to collisions in objectLib.py ~ it’s quite late here and I am quite sleepy, so please forgive my clumsiness at this time
If it helps, bitmasks are being made at the placeObject class at line 162 in tools.py, which gets called whenever you enter ‘enter’ at line 131 there.
I find this strange considering the options I’ve opted in when exporting, I used the command blend2bam building1.blend building1.bam --blender-dir "/Applications/Blender.app" --textures copy --physics-engine builtin when exporting, I just did it again and got building1.bam (340.7 KB)
If you don’t mind, could you check again for collision geometry for this file?
Don’t worry, it’s pretty late here too! Indeed, I’ll confess that I’m pretty tired, so I hope that you don’t mind if I decide to leave this tonight before finding the source of the problem.
Thank you for the corrected reference!
Sure!
I’m still not seeing collision surfaces, oddly. Which is doubly odd, because some sort of collision is happening in-game!
I even checked a model of my own that includes collision geometry, and said geometry was both discoverable in the egg-file and displayable in PView.
That said, viewing the model in PView with lighting active, and based on the behaviour that I saw, I wonder whether part of the problem isn’t in the surface-normals of your model–perhaps they’re inverted, or not pointing along the expected lines.
I also note that your building seems to have single-planes for walls, which, if used as the source of your collision, might be causing part of the problem when the player approaches them from “the wrong side”. I doubt that this possibility fully accounts for the issues that you’re seeing, however.
I’m afraid that I don’t use blend2bam, and so am not in a position to comment on the command that you used to invoke it. Perhaps someone who knows it better will be able to comment there!
No worries, good night.
I tried to avoid single planes in modeling the object mainly for that reason. The walls aren’t really single planes:
, but still, collision still should work properly for that side. I am just going to take another look at how it reacts to that after changing our collision sphere radius.
I feel like it might be because those walls are made out of single planes that form up several cuboids, and since the entire wall is one object, it might map those collisions on those super-thin planes instead of detecting it as a cuboid, so whenever I move across them, it doesn’t resist a lot, if I am guessing correctly, there is nothing else in the code that deals with collisions, I’ll just check through the several files of code to see if I have forgot about something.
The only bit I haven’t brought up is how the building detects the height of terrain and changes it’s Z axis, I can’t see what’s relevant about it here but they are at line 24/182 in tools.py if you still want to look at it.
The repository is updated once again if you want to have a hands-on inspection/look at it.
Thank you, and I hope that you had a good night!
If I’m understanding you correctly, then that shouldn’t be a problem–I’ve used polygonal collision-models without any real trouble.
By way of comparison, I’ve mocked up a simple “building”, including collision-geometry, using Blender. Try substituting it into your game in place of your current building–you should find that collision against it is rather more reliable.
mew.egg (35.5 KB)
That said, there does seem to be a problem with very thin walls–here’s a version that shows this issue:
mew2.egg (29.9 KB)
It’s still more stable than your building, but you should find that similar issues have begun to appear.
I think that there may be a penetration issue here: when you move your sphere, it ends up penetrating multiple polygons–potentially polygons on both sides of the walls.
Hum. At this point I’m afraid that I’m not sure of why it’s proving quite so unreliable! :/
Perhaps one of the others on the forum has some insight.
Good morning, hope you had a good one too
I just downloaded and loaded in that file, it worked perfectly! I am thinking of exporting my building again (with no --physics-engine parameter being fed in) and make a separate model that is a super basic version of this with thicker walls and use that as collision geometry (and obviously using .hide()) as a potential solution.
That’s fine, you helped a lot and I can only appreciate it at this point, thanks a lot 
, the purpose of these assets and collisions were to help me figure out how to correctly design and code certain aspects before diving into more complex and bigger stuff, in other words, I’m trying to get the base/basics correct first, this has been a useful lesson in doing so.
