I have basic terrain information moving quickly between client and server extending from the CGE network client/server examples using the Indy library. It is just sending arrays of singles now, and is using my ‘water grid’ mesh instead of tcastleterrain for simplicity.
It might be cool to build the geometry in the server and send the vertices and indexes directly instead of having the client build that. Each tile is 100x100 vertices (but need to become 101x101 to cover the seams).
1 Like
Not as smooth as I wanted… I kept getting random crashes in the client. It turns out it was crashing due to the check the server connection to update the fps message. I turned that off and my troubles went away. Somewhere in the indy code it does a read of 0 len to test the connection and that seems to interfere with the buffers that are being read in, randomly. I didn’t realize how much a performance cost came from applying the TCastleTerrainNoise to build the tiles. This is done on the server. Subsequent requests are given the already built data… and woah, it is fast, It loads 101x101 grid of 100x100 tiles almost instantly.
2 Likes
Here is 101x101 tile of 100x100 cells, still with the seams so the grid pattern you see is between the tiles. This is using LOD which is highest full 100x100 at the center where the light is. The light is 1000 unit radius. Then as the tiles get further from the center their resolution drops to 20x20. This is far larger area than I could load in my game. But starts to get unwieldy with this many tiles. And takes forever to build the full resolution tiles in the server with TCastleTerrainNoise. But once built this 101x101 tiles went across tcp and build in my fast ‘watergrid’ tcastlescene in the client in under a second. This works out to 50.5km square at the scale my game uses. (5m per world unit).
Here is view down closer to the ground from the full resolution middle. The lit circle is about as far as you can see anyways.
