Hey,
I noticed that there’s one MAJOR design flaw in the way TerrainGrid works…
It uses world coordinates. This means that the precision of every other rendering related thing is decreasing more and more as the floating point is moving further to the right, causing the decimal to be decreasing in accuracy. This causes z-fighting where it shouldn’t even occur, for example, and causes the jME watermonkey effect to be hideous.
Is there any replacement for this? A fix would be to have a provider for the central tile coordinates and then make that centralized at 0,0,0 world position. I don’t have the jME knowledge to do this, but was wondering if this is done anywhere?
Or alternatively, how would I go about making Bullet translate the entire world instead of the player?
E.g.
if player was at (1, 2, 3)
world would be translated (-1, -2, -3)
player is at origin (0,0,0)
Im fliddling with a similar idea. My solution is a client/server setup with terrain quads for large world tiles. Where the server, which never renders anything to screen, only runs physics using true world coords. The client on the other hand offsets the tiles so the tiles the player is standing on its 0,0 and all the tiles in render range are placed around it. While other tiles out of range are deleted from the clients memory.
As the player moves, if he leaves the tile hes standing on, then the world on the client side is translated to make the tile hes now standing on 0,0. The player on the other hand is translated in relation to position to the 0,0 tile. In other words the clients world is centered on the tile the player is currently on not the player itself.
Atleast thats my idea, I havent gotten fully into imp’ing it into functional code yet.