Forum Discussion
Voxel Games and Loading Lag
Hi Guys,
I'm coming up with some ideas on a voxel-based Minecraft-like game, built ground-up for VR, and one thing that I'm thinking may be a big issue for games like these is the momentary lag spikes or stuttering that happens when new 'chunks' are loaded or generated. I'll be writing the game in C# for Unity, I've already done some stuff with voxel chunk generation in the past with good results.
My main issue is how to get around lag spikes/stuttering with smooth headtracking, I don't want my game to induce Nausea. I'm fairly new to things like threading but would it be possible to technically prioritize headtracking above everything else? So that it may take longer to load that chunk (rather than instantly in one frame), so long as headtracking does not have a slight freeze when it happens..
A good example of this would be Minecraft, when running on a powerful PC on a multiplayer server, any chunk loading lag is entirely server-side, on the client you will have silky smooth chunk loading but possibly some delay in the results appearing on-screen. However when playing singleplayer, you will have very minimal freezes instead of loading delays.
Essentially, everything else could freeze except for the headtracking (and possibly hand tracking), so you could continue to look around while frozen.
I'd just like to know if anyone has some thoughts on this and how feasible it may be. This idea is entirely conceptual at the moment but I'd like to make sure it works comfortably in VR.
-Ben
I'm coming up with some ideas on a voxel-based Minecraft-like game, built ground-up for VR, and one thing that I'm thinking may be a big issue for games like these is the momentary lag spikes or stuttering that happens when new 'chunks' are loaded or generated. I'll be writing the game in C# for Unity, I've already done some stuff with voxel chunk generation in the past with good results.
My main issue is how to get around lag spikes/stuttering with smooth headtracking, I don't want my game to induce Nausea. I'm fairly new to things like threading but would it be possible to technically prioritize headtracking above everything else? So that it may take longer to load that chunk (rather than instantly in one frame), so long as headtracking does not have a slight freeze when it happens..
A good example of this would be Minecraft, when running on a powerful PC on a multiplayer server, any chunk loading lag is entirely server-side, on the client you will have silky smooth chunk loading but possibly some delay in the results appearing on-screen. However when playing singleplayer, you will have very minimal freezes instead of loading delays.
Essentially, everything else could freeze except for the headtracking (and possibly hand tracking), so you could continue to look around while frozen.
I'd just like to know if anyone has some thoughts on this and how feasible it may be. This idea is entirely conceptual at the moment but I'd like to make sure it works comfortably in VR.
-Ben
3 Replies
- If the loading is just CPU and disk I/O, I do not see, why this should be a problem. Launch a second thread, which does the work and which leaves a note for the main thread to pick up the results, when it's finished.
I am currently working on a randomly generated roller coaster, where the track has to be planed ahead and the algorithm tries to pick the best of multiple possible tracks (no collisions, wide turns, driving close to objects to make it exciting, etc.). This takes a few milliseconds or sometimes even more than 20 milliseconds, which would mean skipping two frames. But instead I do it in a second thread, which leaves a pointer to the result when it's done, so the main thread just has to load some meshes to the GPU once in a while, which it can do in no-time. "DiCon" wrote:
If the loading is just CPU and disk I/O, I do not see, why this should be a problem. Launch a second thread, which does the work and which leaves a note for the main thread to pick up the results, when it's finished.
I am currently working on a randomly generated roller coaster, where the track has to be planed ahead and the algorithm tries to pick the best of multiple possible tracks (no collisions, wide turns, driving close to objects to make it exciting, etc.). This takes a few milliseconds or sometimes even more than 20 milliseconds, which would mean skipping two frames. But instead I do it in a second thread, which leaves a pointer to the result when it's done, so the main thread just has to load some meshes to the GPU once in a while, which it can do in no-time.
Ah yeah, this sounds like kind of what I'm looking for, I'll need to look into using a second thread as it's something I've barely touched on in the past. So long as the thread that the VR stuff is running on does not carry the heavy load then I'd assume that this would work fine.
And that randomly generated roller coaster sounds like it'll be awesome!- I agree, multitheading seems like it would be the answer.
