It will almost certainly use ints. Large meshes are way too common not to directly support. I don't have to worry about supporting old/mobile graphics hardware, so the only real concern is performance. Unlike a rasterization pipeline with a near-passthrough VS, runtime use of indices is usually restricted to collided triangles and every collision requires a lot of work that makes the triangle sample trivial. (And if the memory
capacity required by 4 byte indices is a problem, it is probably an indication that something very strange is going on, and there is probably a better solution than using 2 byte indices.)
Deforming meshes or other use cases where index bandwidth is actually significant in some phases
may benefit from shorts, but that's an extremely rare use case and I am not sure how large the benefit would actually be. Even if it were valuable, I'd probably just create a dedicated short path in addition to the int path.
BTW: Are there any updates regarding BEPU 2.0? I'm really looking forward to it.
I'm currently fiddling with the
solver. In the interest of not sticking my foot into my mouth in the event that I find some terrible bug in the implementation that destroys all my measurements, I won't excitedly blab about the perf numbers yet. But so far, things appear to be exceeding expectations
