Skip to main content
GameDev.net gamedev.net
🔒 Locked

A couple of questions...

Started by MattCa Nov 20, 2011 at 11:33 PM 3 replies 1.7k views
Original Post
MattCa
MattCa
Hey guys,

Question 1.

I'm pretty far into the development of a Minecraft clone (it's my first 3D project), and I've decided it's time I rewrite the rendering part of the engine.

At the moment I've got chunkBuilder class that takes in cube data, such as position, texture, brightness, and drawing options (for the removal of redundant faces), and then sends them to the GPU as an interleaved VBO. I get a very good frame rate using this system (as it only has to occur once for each chunk - the world consists of many 16x16x16 chunks), a good 500-800FPS is the norm.

However, I get HUGE FPS drops when it comes to terrain modification. Only for a short second, but it's noticeable. I've been looking into threading the chunkBuilder, but I've done a few tests with threads and I've noticed that its not very feasible (keep in mind that at the launch of the game, it's got to create 16x16x16 threads to buffer the initial chunks). Obviously threading is the way to go, and I've still not lost hope, but I would be extremely grateful if someone who has experience with large-scale voxel rendering could give me some advice as to how I should be setting this threading up, for example, should I create 1 thread per 'column' of chunks, and if possible any tips on speeding up the rendering process in general?

Question 2.
Jumping is a rather annoying feature I'm having trouble implementing, it seems to work fine on the average computer with a good frame rate, but it begins to 'mess up' on computers with lower rendering speeds. I know the cause of the problem - the fact that I'm multiplying the velocity by timeElapsed to smoothen the movement on different computers, but this is causing height differences when jumping. Is there any other way to fix this problem? Or would I be better off just not apply timeElapsed to the y position of the player?

Thats all my questions!!
Thanks for the help,
Matt.

Oh, wait, one last thing! Is it possible to create an indexed, interleaved vbo that doesn't share texture/colour data? I've read that it's a bad idea and I should just stick with your average VBO, but and index buffer would allow me to quickly remove blocks by just setting the indices to 0.
latent
latent
Is everything in a single vertex buffer? Could you instead have a vertex buffer per chunk? Have you profiled your rebuild code? If the issue is transferring the (relatively huge*) updated VBO to the graphics card, then transferring only the smaller, modified VBO may be far more efficient. (* how big is the area you're transferring?)

And out of personal interest, are you computing only the visible chunk surface for your a VBO or does your array include occluded geometry?
MattCa
MattCa

Is everything in a single vertex buffer? Could you instead have a vertex buffer per chunk? Have you profiled your rebuild code? If the issue is transferring the (relatively huge*) updated VBO to the graphics card, then transferring only the smaller, modified VBO may be far more efficient. (* how big is the area you're transferring?)

And out of personal interest, are you computing only the visible chunk surface for your a VBO or does your array include occluded geometry?


No, actually! Each chunk has it's own Vertex Buffer which is generally fast enough (until I have to rebuild the array, then buffer it to the GPU).

I've not actually profiled the code (I've never really profiled code before, this is the first time that I needed to optimise code to a very good level), but the current code (which I haven't actually fully tested - need to implement a few more things) has cut down on a large amount of the buffering code; previously I was looping through each block 3 times to build up a VBO that had ||.

The area I'm transferring is 16x16x16 faces, soooo... about 294,912 vertices altogether (16^3 * 6 * 4 * 3).

Define occluded geometry? If you mean the cubes that are surrounded on all 6 sides by other (solid) cubes, then no, I get rid of those in the buffering process . I do the same for faces as well, so basically only caves and the top layer of the chunk is ever buffered - I'd say around 10-20% of the initial vertices.

Thanks for the reply!
Matt.

P.S. An unrelated question, but how would I calculate a 3D point on a ray? I'm trying to figure out how I could do cube selection, but I can't find any good tutorials that don't use the functions already provided by glu or directx.
latent
latent

P.S. An unrelated question, but how would I calculate a 3D point on a ray? I'm trying to figure out how I could do cube selection, but I can't find any good tutorials that don't use the functions already provided by glu or directx.


You could google for how to find the intersection of a parametric line with a plane, but for your purposes a simpler solution may suffice. Create an offscreen selection buffer, and render the closest (say 3 tiles out) blocks. Then just use the cursor position to get the pixel colour in the selection buffer, and use this as an index into the nearest blocks. The advantage with something like your minecraft clone is you're only ever going to pick the closest geometry so you'll never have to waste time rendering everything to the selection buffer. Some OpenGL references - 1, 2 - though something similar will likely apply to any library.
MattCa
MattCa

[quote name='MattCa' timestamp='1321864117' post='4886138']
P.S. An unrelated question, but how would I calculate a 3D point on a ray? I'm trying to figure out how I could do cube selection, but I can't find any good tutorials that don't use the functions already provided by glu or directx.


You could google for how to find the intersection of a parametric line with a plane, but for your purposes a simpler solution may suffice. Create an offscreen selection buffer, and render the closest (say 3 tiles out) blocks. Then just use the cursor position to get the pixel colour in the selection buffer, and use this as an index into the nearest blocks. The advantage with something like your minecraft clone is you're only ever going to pick the closest geometry so you'll never have to waste time rendering everything to the selection buffer. Some OpenGL references - 1, 2 - though something similar will likely apply to any library.
[/quote]


Hmmm.. good idea! So what I'd do is enable selection mode, create a small vbo and fill it with a grid of 3x3x3 blocks, use glDrawArrays to render them, exit selection mode and then perform the pixel colour selection?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.