Dynamically changing the colour of a VBO

Newbie & Debugging Questions
#1

Hey:)

So, I’ve got a voxel engine, which is a 3D array of ints, each number representing a different ID.
At the very start of the game, I bind a new VBO and calculate which vertices to send to it as a FloatBuffer. I combine some blocks’ faces to make it faster to render - this process can take some time, with large numbers of cubes.

My question, is that when I change the lighting, or remove/add a block to the chunk, I have to recalculate this every time!
It’s incredibly slow, and for a small chunk it can take about 1 second.

I’ve considered multithreading it (for lighting changes). This would work, and I’m pretty sure this is how minecraft does it for the sun’s lighting - if you change the light using commands, you can see each chunk slowly updates.

However, this wouldn’t work for destroying blocks…

I’ve also considered caching (Did i spell that right?) the VBOs faces which combine together, then when I want to update it I do it quickly and dirtily (Without optimising the amount of faces displayed). Then, in another thread, I can slowly work on the optimisation and switch it out when it’s finished.

Problem with this is it’d use way too much memory, I already get memory errors if I set the chunk size too large.

Any suggestions?

#2

You must be doing something incredibly wrong if calculating mesh for 1 little chunk takes 1 whole second. Whats the size of a small chunk?

#3

200200 widthheight ways - actually, this could be quite large, but the scale of the game makes it look small. Maybe that’s the problem? Or maybe it’s the way i’m meshing it together?

the height depends on the noise generation, but it’s between 1 and 57 blocks high.

#4

You need to scale down your chunk size… Minecraft has chunks of 1616 (widthheight).

Your chunks are almost 16 times larger.

#5

Also, what about only updating a small area, like the immediate area around where the block was changed?
And calculating the lighting for only things that the light can see?

It seems managing the large amounts data is the biggest issue in a voxel engine.
Although same could be said for your standard engine, it seems more prevalent in a voxel engine.

#6

Mm, thanks trollwarrior. I should have realised that before I posted this, that was a rather dumb mistake:P

Bogie, what you suggested is basically chunks:) You can’t just calculate an area around where the block changed - the VBO is stored a 1 big buffer, containing loads of data - the only way to selectively edit stuff is to have loads of different VBOs. To many will reduce performance though, I think it’s mainly to do with choosing the right numbers - as I obviously haven’t done;)

EDIT:
Yes, scaling down the chunk to 16x16 works great. Thanks.:slight_smile:

#7

I was thinking more locally than the entire chunk though.
Like if you had a quad tree set up, where a chunk consists of 4 smaller chunks or something, but like you said too many VBOs will reduce performance.