Sorry your browser is not supported!

I've been brainstorming the last few days on how I can cull parts of my terrain and city efficiently and have come up with the following. I actually think someone has used this before on these forums, but it's been so long I can't remember. I'm also wondering what some your solutions are, and if anyone knows what the practice is in the industry for those of you who have some professional experience.

If you think of sections of my city as 50 meter x 50 meter blocks, with 20x20 blocks, then you get a pretty decent size town. Since the player won't be scaling rooftops or over looking the city freely (they'll be a few pre-rendered or cg scenes), I can cull things pretty close to the chest around the player. I'll probably only need the nearest 2 blocks in any direction (so 25 out of 400). If I need to go higher, I could.

The terrain will, for the most part, be pretty level inside the city. I'll be using the lowest resolution map I can, but keeping in mind the following idea will need a higher res map.

Heightmaps use grayscale values calculated from using the RGB values in the image, but I could also tack on the alpha channel to my image and store another layer of information there, like rotation and position.

For example: My player is in block 13 of a 5 x 5 grid (dead center of the culling radius) with everything else having been culled away around that 5x5 grid. A pixel on the alpha channel of the 512 x 512 heightmap for block 13 is located at 32, 303. My game cross references the block number and the coordinates and sees that a building is suppose to be there. Not only that, but it see's how red the pixel is and rotates the building according (rotations would have to be out of 254 degrees instead of 360).

Blocks on the outside of the view distance would be loaded in but not displayed probably.

It just seems like a really packaged way to cull what I don't immediately need around me, and even contains all the position data I need to boot!

Some of the concerns I have is file size. Height maps take up a bit of room after a while with all the environments I could have. I suppose one solution would be to get everything I want in my block set up and positioned inside of a custom level editor and then export the height, position and rotation values out to a custom file type that could be read in later. I'm not sure, but I'm guessing that would take up less space, and probably even save on processing time as well.

Another concern I have is that I can't stack objections should I need to. I'm not sure this would be a problem though.

What are everyone's thoughts on this?

Sounds like a great idea .


You could even just use, say, the R channel for height and have the B, G, and A channels for other stuff.


You could use some of the other channels above to get at least one extra level, right? Heck, if you need more information per pixel than 4 bytes will give you, you don't have to actually use an image. You can get the same fast, easy culling by making your own format with, say, 10 bytes per "pixel" and you can read it almost exactly the same way with memblocks.


Record the angles from 0 to 180 and multiply by two when reading them - this will allow you to cover all 360 degrees by "skipping" every other degree.

My random thoughts ^

Not sure why I said objections there... meant objects. I was very tired when I wrote that lol.

Nice idea about the angle thing, I'll be sure to do that.

Oh wow, I didn't even catch that channel thing. I was sort of wondering about that, but I figured that because black to white requires all channels I just disregarded it. However, a heightmap uses whatever color you want it to. If I just use the red channel for height, that leaves me with 3 other channels to do stuff in, as you said. This is great!

Does anyone know which would be faster though and be of less file size? The images or the text files?

They're both the same size, as they both hold the same information . They're just converted to a memblock differently.
make memblock from image
make memblock from file

Well, a heightmap is nice and all, but it's starting to sound like a normal custom file to me. I always thought that the easy thing about a heightmap was that you could open a painting program, and sculpt the terrain just by using the brushes. Now you're assigning pixels to object rotation, which makes it very hard to actually 'paint' on them as you have to draw pixel-per-pixel (which is why people use editors). The concept of describing a city with a heightmap instead of a terrain is bugging me a bit.

Cheers!
Sven B

I think the idea here is that with an image file, when you need to load new data because the player has moved somewhere, you don't have to check through every single entity to see if it needs to be placed now. You just check the pixels right around the player.

Oki! I guess I was taking the image thing to literally. I didn't know that he only wanted to order his data in a fashion that makes culling easier. I guess I should read more carefully .

Cheers!
Sven B

Exactly. It's just a matter of checking to see if that whole block is in view or not. If it isn't, cull the buildings, the plants and the terrain.

A custom editor is already in the works for this

I think the file size thing is still up for grabs. They both save the same info, true, but there might be some behind the scenes things happening in a gif that makes it bulker. No clue. I guess I'll export to both in my editor and see.