Which is the best collision solid to use for a maze?

Does it work for .bam?

Sounds like a good idea to me :slight_smile: ; I just posted a similar snippet, not for Bullet but for the built-in collision system.

Here you go: Automatic Collision Generation for Bullet from Preloaded Models

1 Like

An alternative option is to project the x, y coordinates of your player to pixel coordinates and then use a pixel ray on the texture, if you hit a black pixel then it it is a wall, if not then your object can move in that direction.

Wait, is it a 2D game or 3D?

Hi. I have tried to export using the blend2bam with the rigid body physics enabled on the model but this still does not stop the player from traversing through the walls of the maze. Exporting using blend2bam has also made the FPS of the application drop from a steady 144(vsync is on) to around 3/4 FPS. Could the FPS drop be due to the colliders trying to be applied to the complex maze?

Do you have an easy, efficient means of getting the start- and end- points of each wall? (For example, are the lines in your original SVG defined as start- and end- points, or are you processing those lines into something that provides such data?)

If so, then I’d likely be inclined to use those points to construct CollisionCapsules–either in Blender (I recall that YABEE could export tubes natively; I don’t know about blend2bam) or at initialisation-time in code. Specifically, I’d be inclined to look for a way to generate the tubes automatically, without requiring the the developer manually place each one.

Capsules should be fairly efficient, more reliable than polygons (since they have volume), and even provide what might be nice corner behaviour via their end-cap spheres.

My SVG is simply a PNG black and white line drawing of the maze (the original I used is at the top of this post I believe) which I converted into an SVG. Using @Simulan 's code snippet gives me coordinates of the geometry triangles but there are thousands of coordinates (this is when I use print(geom_target)), and to manually add collision tubes, as you said, would be tedious and time-consuming. I have tried both the code snippets linked in this post and have tried exporting the colliders using blend2bam rigid body. I feel like manually adding the collision tubes to each corridor in the maze maybe my next option.

In that case, for so small a maze, adding the collision-shapes manually might indeed be a reasonable solution.

More generally–i.e. for larger mazes–I might suggest looking into some sort of corner-detection algorithm. That might allow you to detect reasonably end-points for the tubes, and so generate them. But for this fairly small maze that’s likely overkill!

I’m not 100% what you are trying to accomplish with your program, but if it were me I would use a standard Bullet infinite ground plane and then have only the vertical Z-axis geometry (the wall of the maze) created with automatic colliders. This way you could move a BulletCharacterController with a capsule shape through the Z-axis geometry.

I would really advise against Bullet unless you’re sure you need a physics engine.

What problems were you encountering with exporting the collision geometry from Blender? We may be able to help with that.

When I was exporting in blender using the rigid body it was still letting my character walk through the maze and the FPS was dropping to around 3/4. I assume the FPS drop is because it is being loaded with the collision geometry and there are a lot of vertices in the maze, but I wouldn’t be surprised if I am wrong.
If I am right and it is creating the collision geometry, I don’t understand why my character is just walking right through the maze.

Have you verified the collision objects are showing up by using the Bullet Debugger?

And @rdb is right, Bullet is not necessary in a lot of cases and the learning curve is significant.

Let me third the sentiment that Bullet is likely over-much for this purpose: the built-in collision system is likely to be easier to use while nevertheless doing the job.

It’s hard to say without more information, as there could be a few things going wrong: perhaps the collision geometry is being generated as a “ghost node” (i.e. intangible); perhaps it’s being generated with gravity applying to it, and is thus falling away before the player interacts with it; perhaps there’s some issue in the application’s handling of Bullet; perhaps it’s something else again.

The first step–presuming that you stick with Bullet–is to turn on the Bullet Debug Renderer, as Simulan suggests above. Then we can check for issues with the collision mesh itself, and see whether it’s perhaps a “ghost node”.

And to make things easier to analyze, I would definitely try to reduce the amount of vertices first. Since the model contains thousands of vertices, it wouldn’t surprise me if they were so close together that their extrusion results in super thin triangles, which might make collisions quite problematic. Check if the script/library/whatever used to convert from image to .SVG hasn’t got any options to detect straight lines or corners more accurately.

I think the classic 3D modeling way would be to draw the lines of the maze from a top down projection in your 3D modeling program, and then extend those edges into Z-axis planes. I would not try to use additional software to convert lines into planes, if that’s the case.

Similarly you can achieve a vase by drawing a single line segment, and spin-extending that around an axis.