It works fine in all render pipelines with the correct render pipeline adapter for MicroSplat. Use the support channels for support.

You can allocate a larger buffer to handle larger areas - if you don't increase the buffer size, then you are effectively increasing the size of the pixels of the buffers which changes the size of the objects you can represent in the buffer. (there's a display on the component that shows how large the pixels are based on your world size and buffer size). This is no different than stretching a texture over a larger area, it's just math. If you wanted to, say, do a tracking game, that kept footsteps around across multiple terrains and extreme distances, then allocating more/larger buffers would not be an efficient way to do this. Better would be to have the thing your tracking drop "footstep" assets that persist and are what gets rendered into the trax buffer instead of the actual character- then the buffer/world size can be small, and when you reenter that area those objects would get rendered into the local buffer again. 500k footstep transforms could be stored in the size of a 2k trax buffer, and you could likely double that by storing them in a more efficient manner (no scale, reduced precision). You can't see a footstep from 2 miles away, so why do you want to render them that way? Basically, your complaint is a bit like saying "Hey, I really wish I could just have a giant texture over my whole landscape of insane resolution that didn't take up any more memory or performance - why isn't this tech magic?". But that's not how games work- instead, they use various tricks (splat mapping, virtual textures, detail texturing, etc) to get around not having infinite memory and processing power, designed for your particular edge case.