how to approach 1600 non-dynamic boxes?

[Bombshell93]

Okay the count will be much higher than this when full maps are made. the maps are 128 x 128 x 128 blocks, slopes, spikes, etc.
Their in this format for easy map creation for users of my game.

atm the first obstacle is 1600 static cubes as the floor. I need to cull most of them in some way from collisions.
How should I approach this? I'm fairly new to physics engines in general, I heard the best things from BEPU, but naturally 1600 cubes lags stuff up XD
3 things I can be certain about these blocks, they will never collide with each other (bar their sides touching), they will always be aligned to axis, they will never move (moving objects will be handled at a completely different scale)

Any and all help appreciated,
Thanks in advanced,
Bombshell

[Norbo]

The 'easiest' way (from the perspective of minimizing deeper work with the engine) is to construct a mesh which represents the external surface of the cubes. Shared faces could be bundled together to lessen the triangle count. Since it would all be one mesh, the broad phase would only view it as a single object and the overhead would drop a whole bunch (the lag from the 1600 elements is in large part due to a bunch of failed pairwise tests; the broad phase can't know that the cubes don't generate pairs before it drills down through the hierarchy).

There are two problems:
1) To make an optimal mesh, some fancier algorithms will need to be implemented. Chances are you could get away with doing something simpler, like just including the surface of any cube that is exposed to air. The third and simplest approach of creating 12 triangles for each and every cube face without regard for being in the ground would probably quickly become unusable (over 25 million triangles in the worst case for a 128x128x128 chunk).
2) If you need to add or remove cubes dynamically, a la the 'minecraft' genre, regenerating the collision mesh won't be fast. It is doable with some tricks- in fact, I believe at least one voxel-cube-based game using BEPUphysics does something like this. It requires dynamically maintaining multiple meshes- perhaps a StaticMesh for each 32x32x32 group. Then, when bits are added or removed, the mesh reconstruction is limited to that single chunk.

A much more elegant solution is to create a custom Collidable based directly on voxel data, but this requires much greater familiarity with the inner workings of BEPUphysics. You would also be responsible for implementing the collision pair handlers that define how contacts are generated between different types of objects (but you do have access to BEPUphysics's built in narrow phase tests, so you don't need to problem a box-box test for example). So, while this is definitely the higher quality route, it will take some effort. My last post in this thread goes into depth on what exactly it involves.

[Bombshell93]

Collisions won't be checked in the level editor and when in-game the won't be changed, any objects intended to move, disappear, activate, etc. etc. will be objects in their own right rather than world blocks. So when saving the level a new mesh could be generated with a UV and MatID map. (the scale of everything makes these easy to keep on a byte basis rather than ints or floats so its not a big issue.) If you have any algorithms for welding shapes I'd be glad to look into it.

What I was thinking is some way of tagging the world blocks not to check between each other, only check when a player or enemy is near. Because even if I make a large mesh there's still the matter of handling collisions with interactive objects, many of which being added as blocks for easy use with the level editor (spikes, springs, traps, grind rails, etc. etc.) many of these would still require collision detection on a single block basis, the springs having individual power, traps having individual timings, etc.

also for the record, I would crush my skull before leeching someone elses creativity by cloning minecraft XD

[Norbo]

What I was thinking is some way of tagging the world blocks not to check between each other, only check when a player or enemy is near.

Kinematic objects default to a collision rule that prevents any broad phase pair from being created. The problem is that the broad phase cannot know that until it drills down to check, and unfortunately, a close touching grid of blocks is one of the worse configurations for performance. It forces the broad phase to drill all the way down to leaf nodes across the entire tree.

The advantage of a StaticMesh (or other functionally equivalent Collidable) is that the broad phase views it as a single object, preventing broad phase pollution. The StaticMesh has extra knowledge. Nothing in the mesh can ever collide with anything else in the mesh, so no effort is expended in pursuing that path. The only tests left are those between the mesh and other non-mesh objects which are much, much rarer than individual triangles in the mesh. That cuts down the pressure on the acceleration structure by a factor of a few thousand.

Because even if I make a large mesh there's still the matter of handling collisions with interactive objects, many of which being added as blocks for easy use with the level editor (spikes, springs, traps, grind rails, etc. etc.) many of these would still require collision detection on a single block basis, the springs having individual power, traps having individual timings, etc.

I'm not sure I follow; a StaticMesh (or other functionally equivalent Collidable) will collide with other objects and act as a proper environment.

Another option I just realized in my sleep-deprived stupor would be to use a kinematic CompoundBody composed of a bunch of BoxShapes. No need for fancy triangulation algorithms and they'll be perfect for unchanging environment geometry. The broad phase will view the compound as a single object and you still get almost all the benefits of the static mesh, without the difficulty of actually constructing a mesh. It would still be wise to only include the exterior boxes to keep the total object count down.

There will be a slight difference in how boundaries are handled. In an optimal static mesh, the inter-triangle boundaries are smoothed out so objects don't 'bump' when going over an edge. When creating a bunch of individual boxes in a compound body, no smoothing occurs. The bumping will still be pretty rare depending on what kind of shapes are being used, but it's something to look out for.

[Bombshell93]

thanks the compound mesh should be perfect

EDIT: *for one thing forgot to post so this isn't really an edit*
I've rigged everything up... I think. the game is updating, bepu is applying gravity. But when the dynamic object PlayerClass hits the kinematic compoundmesh it just passes through.
This is more than likely beginner mistakes, I've created the Space as a static class, set its gravity vector, added the objects to Space, got it updating every frame. But its just not resolving the collision of player to ground.

[Norbo]

It may be that the graphic is not fully aligned with the collision shape. Using the BEPUphysicsDrawer from the main source download will diagnose that quickly.

This page also has some more information: http://bepuphysics.codeplex.com/wikipag ... ecentering

[Bombshell93]

it would need to be off by a long long way. I looked at the positions (with Position update mode set to continuous for the sake of debugging) and the players position is updated to the bounding boxes position each frame.
The floor definitely doesn't move, covering from 0,0,0 to 384,384,0. The player falls vertically from 40,40,40 down z. but Player passes straight through.


EDIT: another edit that isn't an edit,
I found the problem! Boxes didn't seem to be effected by their positions? when the player is at 1.5, 1.5, 1.5 collisions happen.
I'm going to look more into creating compound shapes properly tomorrow, in the mean time my bed is calling me.
EDIT (actual edit)
realized as soon as I posted, the issue was from turning the entity boxes into parts for the compound shape.

Thanks for all the help