qu3e for a voxel engine?

[999pingGG]

Hi! I'm looking into using this as the physics engine for a Minecraft-like (voxel-based) game I'm making. It will run in Windows, Linux and Android. I just need something simple that can simulate non-rotating AABB entities, and this looks perfect, but for terrain collision I would need to make triangle meshes... My main question is, can I instead just create a bunch of physical boxes for the exposed blocks without losing lots of performance (memory and CPU-wise)? Additionally, I need to do raycasting and get the world location and normal vector of the box face that has been hit...

And now, about the planned features, it would be nice to have springs to make fun stuff! Multithreading would be great for performance, too. I'm even willing to help developing those features, but I know almost nothing about physics. I could do my research, though.

[RandyGaul]

Voxels is a good use case! qu3e was actually used briefly in a voxel-based indie game by a friend of mine before he stopped working on it.

Personally I don't have an interest in extending this library with any features, but I do like physics and am happy to offer advice and point you in the right direction if you want to add anything. I can tell you that directly adding triangle mesh support would be a huge amount of work, and if you really need this feature I recommend to simply use Bullet.

Depending on your game, if you can actually get away with only boxes, then this library will work. You can create a huge number of boxes and the simulation will run quite smoothly. There's already some basic raycasting support. You can cast a ray into the scene to see which boxes are hit. There's no normal returned, but this is a trivial function to write yourself (or find a copy online) or include into qu3e directly.

I've done multi-threading for a physics simulation like this before, and can happily point you to the exact pieces I'd recommend modifying if you're interested.

Springs would be fairly easy to add, and I can help get you started on this if you're interested.

Overall I'm active and here to offer advice or fix bugs, but am not planning on adding new features myself :)

[999pingGG]

Oh many thanks for your support! Just to clarify, I can get away with just box colliders everywhere, I just wanted mesh colliders for the terrain because I thought it could be more performant or memory efficient than spawning thousands of (static) boxes. As for the raycasting, in the case of boxes instead of meshes for the terrain, if I can just know what box was hit or it's position, that will do the trick, no normal required. I will use raycasts to know what block the player is looking at, and maybe for AI line of sight, etc.

So for now, I will just do basic integration of this physics engine with my game (make a test scene, just spawn some falling boxes, simulate their physics and render them). I will implement some other functionality, maybe upload the code to GitHub, and when I feel like it I could start to use raycasts and implement springs and multithreading if you say it's easy! You said you don't want to bloat this library so is it okay to pull request changes here, or should I fork this?

Oooh and I just recalled, I also want to implement a character controller like Unity3D, do you think it would be hard to do? A Minecraft-like feeling would be awesome, in the sense that while grounded you are in full control of your character, there is no friction or slippery floor, you can run and stop instantly, but you can still be pushed by entities, free fall, and be launched by explosions. This is hard to do by using forces to control the rigidbody.

Thank you again, and looking forward to contribute!

[RandyGaul]

Don't worry about bloat regarding multi-threading or raycasting. These are smaller features.

Here's some of my thoughts on character controllers: https://github.com/RandyGaul/player2d

[999pingGG]

Woha, I don't understand much of that link.. At least not right now. I'm going to try to implement a character controller later anyway.