FOV

Building and navigating through voxels is already a thing in my project. But now, we're running into more QoL  issues. While I was putting together a cool dirt house, I noticed that when I slapped on the roof, the player's vision vanished. This was something I thought about a month ago during the planning phase, and finally, I can test out if my past idea holds up.

The fix is simple: whenever the player hops to a new voxel, we'll check all the voxels above their head until we hit one with a block on it. That's our signal that there's a roof over the player. Then, we'll use a sneaky recursive function to gather up all the adjacent voxels with blocks, including ones above and below, but not going lower than the player's height. This way, we snag all the voxels making up the building, except for the walls the player's stuck against.

Remember to slap a cap on that recursive function to dodge any stack overflows!

After we've bagged all the blocks, we'll use the Tile.StopRender() function to turn off rendering for the assigned block, and stash all those turned-off blocks in a list. When there's no roof detected, we'll flick the rendering back on for those blocks and tidy up the list.

Yep, this fix seems to do the job just fine. It's pretty sweet to see that my month-old idea wasn't totally off. While I was testing to make sure everything's running smooth, I got hit with a cool feature I'd like to add. You know in Project Zomboid, when you peek through a window and see the building's inside? I thought of a neat way to pull that off without much fuss.

So, there's this CeilingRemover class that nixes roofs, originally tagged onto the player. But if I assign it to an empty object in front of the player instead, it can check out the tile in front and one level up, acting like the player's "eyes." Picture this: you stand in front of a window, and this empty object slips into the empty space, doing its thing. But, gotta remember, now we need to make sure the player turns as they move. That's a bit of coding we'll need to tackle.

Before I dive deeper into this method, I'm gonna sniff around for another solution. One that might be better with the game map.

I'm toying with the idea of chucking out a bunch of "raycasts," letting them wander around and paint every tile they stumble upon until they hit a block. So, I began tinkering with how Tiles are displayed. I've divided them into three categories: explored, spoted, and occluded. When you boot up the game, all the blocks start off in uncharted territory. That means they're active but flying under the radar. When the player gives a tile the once-over, it gets tagged as explored and marked as spoted. If it's not being watched, it gets a faded look, but if it's on the radar, it shows up like usual.

To figure out which tiles the player's peeping at, I set up this "Voxelized Raycast" system. I pick an angle and sling out a bunch of rays evenly. The starting tile is where the player's at, and the end is a point shooting off in the ray's direction. As it inches towards the target, I keep tabs on which tile it's in and grab all the tiles above and below, with a height limit.

As it shuffles along, if it smacks into a block, it stops dead. That's how I can mimic barriers or walls that make the player loop around to see what's behind 'em. But, gotta admit, this setup's causing some funky glitches.

Lastly, throwing out heaps of rays was bogging down performance, but flinging a few led to wonky results. So, I had this brainwave: instead of letting all the rays loose at once, I'll activate them one by one. Every frame, I send out about eight or ten rays, giving us a small but meaty chunk to evaluate. After each round, when the first ray kicks back in, I check which tiles were watched this time versus last time. Any that don't show up in the new list are forgotten and drop off the watchlist. That's how we end up with what you'll see in the next clip.