I’m breaking up the game map into chunks to minimize loading times.
But rather than dealing with many cells across a very large space, I’m just moving things around.
The basic gist of it is, anytime the camera tries to go beyond a certain point, the matrix that holds the data for terrain and objects has to “slide” one step in the direction the camera is going. The camera is then sent back to the opposite side of the map. Err… my english might be failing me in the explanation, so here’s a video of what’s going on.
The world loops around. If I add more cells, then it takes longer to get back to the start.
Good thing is, one could create a massive open world and never see a loading screen beyond the one that initializes the world. Problem, and what I want to ask, is even though it is not so obvious from the video the camera doesn’t smoothly snap back into place after the matrix pulls objects in the corresponding direction.
Where max_distance is a float that denotes how far away from the origin of the grid the camera can go. I oversimplified it here but the formula is rough, though it mostly does what I need it to do.
Point of this thread: Any ideas on how to get the camera smoothly across the other side, so that the transition isn’t quite as obvious?
The question is: what is causing the visible snap? Is it the motion of the camera, or is it perhaps that the texture of the ground plane doesn’t match at those two locations?
Also, unless you’re going for huge worlds, this may not be necessary. A float has 6-7 decimal digits of resolution. This means that at 1km distance from the center of the world, the position of things is still accurate to 1mm. At 10km, it’s accurate to 1cm, 100km it’s accurate to 10cm, etc. The radius of the earth is 6,371km, at which point a single precision floating point is accurate to < 1m.
Turns out it was both. A nap and a day of work got my brain working again.
The camera felt snappy because of slow parent; turning it off, moving the camera and turning it back on again isn’t enough – I have to compensate for the offset and make the jump to a few centimeters back. Not entirely sure how I’ll go about doing that, so I’m dispensing with the slow parent for now.
The texture on the other hand is an easier fix. The plane is cut up into nine equal parts and so are the UVs; necessary for how the material works – reading colors from a single image and replacing those colors with the appropiate texture.
Having the UVs cut this way I ensure that the appropiate cell is always using the correct section of the color mask. So to have the actual textures map correctly, I made a second UV map and had every plane sent back to the center and strectched back to bounds.
So, problem fixed.
Well spreading the world over great distances is a concern, but my reasoning for doing this is I only have to generate a relatively small grid. Because I’m generating terrain and fog of war from images that need to match the size of this square grid in order for each pixel to correspond to one tile, it makes sense to me to keep the dimentions manageable.
