- Home /
2D Procedural Voxel Collision, how?
I am working on a small 2D Voxel prototype and I was wondering, what is the best method I could use for Collision? I was thinking of using the Polygon collider / Edge collider however it is proving quite difficult to implement this. I would need to write a search algorithm to find the edges of the blocks and build loops for the Polygon collider, which is quite a lot more than I was planning on doing. I also looked into using separate box colliders for blocks with the implementation of some sort of greedy meshing kind of system to stretch boxes over the area's of the chunks, this however would be quite a messy way of doing it and in certain cases quite intensive.
I have managed to do this with a 3D Voxel game through the use of Mesh Colliders, however this is not possible with 2D. I do however need to make it compatible with the 2D physics engine, this is why I have not just simply used a 3D extruded mesh as a mesh collider.
Is there any way in which I could implement 2D collision to a procedural Voxel game?
If it works with 3D I guess you could extend the 2D meshes backwards to become cubes, other than that I got no better suggestion.
I originally did that, however it then removes the ability to integrate it with the 2D physics engine, which is what I need to do.
Did you ever figure this out? I am trying to use a 3D voxel engine for a 2.5D game where I use 2D physics for game logic and 3D physics for visual effects particles, ragdolls etc) so I am in the exact sam position here...
Answer by camander321 · Jul 19, 2016 at 06:36 AM
Not sure how well this would work for your game or if you are still looking for a solution (I'm only 2 years late), but awhile back I came up with a system that I'm reasonable happy with.
Simply create a small grid of 2d box colliders (3x4? 5x5? Depends on character size) that stays centered on the player, but snaps to your tile grid. Then simply enable/disable the colliders depending on whether there is a tile behind them or not. This can save you a lot of time and memory space by only having colliders where they actually matter
Expanding on this, I don't see it being terribly difficult to swap the box colliders out for other collider shapes that better match your tiles (ramps, half-tiles...). Perhaps using enums for different shapes.
A few drawbacks:
If your map has a lot of players/enemies/npcs, you can still end up with a lot of colliders. It can quickly become less efficient than other methods, especially since characters close together will each have their own collider on the same tile. (Maybe figure out some sort of pooling/sharing?)
Even if your colliders are aligned perfectly, the player can still end up "tripping" on the edges. A quick fix is to actually scale down colliders that are not immediately adjacent to the player ever so slightly. Then return them to normal when the player is on them.
Perhaps I had simply set things up improperly, but oftentimes, my player would pass through one or more layers of tiles when falling or moving fast. Though as I type this, I'm realizing that I probably should have moved the colliders in "FixedUpdate" rather than "Update". Live and learn...
Thanks for sharing! cool idea! In my project I ended up using 3d colliders with locked z-axis. That works as well but it also has a slight performance overhead compared to pure 2d.
Thanks for the great idea, regarding the gird of colliders around the character. Just implemented that, and its real quick for me, and saves me all sorts of problems that I was going to be getting from trying to 'maintain' my colliders. I now have it perfor$$anonymous$$g under 1ms, and with zero garbage! :)
Answer by boxing_rex · May 09, 2014 at 03:10 PM
If you plan on having a collider for each voxel, then I would suggest casting multiple rays from your player / object and checking if there is a collision. I done some digging and found this video on YouTube, the script he uses is available in the description and should work for all types of 2D games. Hope it helps.
Thanks for the info but that is not exactly what I am planning, I would require too many colliders for such a thing to happen, ins$$anonymous$$d I need to somehow generate all the colliders into a single mesh / collider to use, this is a problem however because I do not know how I would approach it.
Your answer
Follow this Question
Related Questions
Best approach for collision in shape combination game? 0 Answers
Random 2D tile engine question 0 Answers
2D Detect collisions of a 2D block only on left/right (not top/bottom) 0 Answers
Objects don't collide 1 Answer
Particles and 2D games 1 Answer