Voxel - a start

WIP games, tools & toy projects Cube World Projects
#21

Plus, only render cubes that are in your line of sight and your “rendering distance”

#22

Hi Agro,

So, was I correct in what I was saying?

And what do you mean about rendering distance?

Thanks

#23

Like, the world can go on forever and forever, miles and miles of blocks. You shouldn’t render any of the blocks you can’t see. If you do, its plain useless since you can’t see it or interact with it.

Minecraft adds an option to set your render distance. Tiny only renders a few blocks around you, then short, then normal then far.

#24

Yes, that is ok, not up to that bit of the code yet though, i.e. optimisation - still need to put my cubes / geometry into VB’s! At the mo still in display list.

Was just asking the question that am I correct in saying that the value you get from the height map you use to draw y amount of cubes?

#25

Yes, that is the Y value (or amount of cubes) that will be in that height.

But notice that if you use 2D simplex or perlin noise, you cannot achieve caves or things that areas that have depth within other areas.

#26

Yes, will need to use something else for caves, anyone any suggestions??

Also, anybody know how to draw the voxels using one glTranslate? As you can see
from my code snippet in my posts, I make three glTranslate calls for x, y and z.

#27

Yeah, for caves, just use 3D simplex or perlin noise.

#28

Will need to look at that when get the basic landscape up.

Any clues on using less glTranslates?..

#29

How about that?


private void renderTheWorld()
   {
      for (int x = 0; x < xAmount; x++) {
         for (int y = 0; y < yAmount; y++) {
            for (int z = 0; z < zAmount; z++) {
               glTranslatef(x*2,y*2,z*2);
               glCallList(voxelList);  // display list   
               glTranslatef(x*-2,y*-2,z*-2);
            }
         }
      }
   }

I don’t have time to test it, but it should work.

  • Longor1996

PS: This is the most easy approach to render voxels, but it is also the most memory/calculationpower consuming approach.

#30

Hey thanks for that - works fine.

I’m taking it also, we need to store the height in some array for each of the chunks and then when rendering the voxels in the update loop, use the heights we have stored in this array? Chunks being 16x16x16.

int heights[] = new int[16*16]; // will hold the height we generate from SimplexNoise or whatever

Thanks again,
Steve

#31

I still think there is a way of doing just one glTranslatef, something like:


for(int x = 0; x < xAmount; x++)
{
    for(int y = 0; y < yAmount; y++)
    {
        for(int z = 0; z < zAmount; z++)
        {
            glTranslatef(x, y, z);
            glCallList(voxelList);
        }
    }
}

But obviously that won’t work.

I guess if we store the blocks x,y,z in a 3d array, the above could work?!

int blocks[][][] = new int[16][16][16];

and use the index as the block position…

#32

Sorry, I don’t think I understand, why would you multiply x by 2? Wouldn’t there then be a gap between the cubes? I use the for loops and then call

glTranslatef(x, y, z)

and it works fine (offsets are better than

glTranslatef()

though, its far cheaper).

#33

Hi, the * 2 is the ‘stride’ or the width, height, depth of my cube (-0.5 to 0.5)

Still unsure how you can do this with just one glTranslatef…

So you just have the three loops and one glTranslatef?

Thanks,
Steve

#34 

int x0=0, y0=0, z0=0;

for(int x = 0; x < xAmount; x++)
{
    for(int y = 0; y < yAmount; y++)
    {
        for(int z = 0; z < zAmount; z++)
        {
            glTranslatef(x-x0, y-y0, z-z0);
            glCallList(voxelList);
            x0=x; y0=y; z0=z;
        }
    }
}

There, one translate-call. Needless to say that this is a horrible way to interact with drivers. Just fill VBOs already!

#35

Hi,

Hey, thanks for that, obvious now when look at it!

Guess next step then is to look at using VBO’s?

Cheers

#36

Yeah, they take up less calculations and rendering time because i think VBOs are stored in video memory. Am I right?

#37

I think you are correct in saying that.

So basically create the ‘world’ out of chunks, store in VBO’s and render…

Of course, there are other optimisations that will need to be made, but, hey, I need to walk before
I can run!

At the moment, I’ve got a camera in place, a skybox and blocks being drawn using display lists, using simple random seed for height. So, need to implement:

  1. Chunk rendering using display lists
  2. Get rid of display lists and place chunks into VBO’s
  3. 2d/3d Perlin noise - 3d better if wanting caves etc…

Help! Lol

#38

Added latest screen show of 16x16x16 voxel, using simple random value for height and…still using display lists :frowning:

I guess this would be regarded a chunk of the whole world and would be sent to the gpu in one blast using a VBO? Also need some perlin/simplex noise for the heights, as mentioned just using a simple random number for them.

Thanks

#39

Don’t be scared of display lists. I’m running my game with displaylists in State of Fortune and it performs quite well. It even outperformed VBO’s for drawing on my gfx card thanks to some driver optimization magic. It is a lot slower to update them though (factor 10 or so for my 66x66 chunks). VBO’s are very useful when doing things like particle engines and dynamic animations, but other than that it isn’t all too bad to use display lists.

Mike

#40

So just to clarify, VBOs really aren’t all that useful and don’t offer much performance over Display Lists when used in static geometry?