Voxel - a start

Got block moving in 16 units, here is the result:


https://www.youtube.com/watch?v=aUP6iPtCPoU

Now need to place blocks and remove them, next on the list.

Thanks,
Steve

That’s looking really good. You have fog too and text. It’s all coming together. :slight_smile:

Thanks Paul,

I guess placing the blocks now is just by using the position of my wire cube?

Added block placing and removing. Not fully working yet as only works in one chunk area.

How you guys coping with placing a block in a chunk that yet doesn’t exist? For instance, when I create my initial world, it is only one chunk in height, how about if player adds a block above this chunk…or, do we have many chunks that are just ‘air’?..

Link:


https://www.youtube.com/watch?v=sZHl8pnoe0M

Thanks

One way of doing this is to make the chunks above, and have a variable in the chunks such as

Boolean Empty = true;

The chunk would be fully created, but at renderTime

If(!chunk.isEmpty) render chunk

If you place a block in the chunk then Empty = false.

Looking very good btw :slight_smile:

Cheers :slight_smile:

Yes, was thinking of say creating the ‘world’ as say 32x32x32 chunks and like you say, create empty chunks, this would solve the need to check if block we are placing is in a chunk that as of yet doesn’t exist.

As chunks are made up of blocks which have a boolean variable in them to see if there are active or not may not need a boolean empty for chunk?

On a side note, wondering what is a neat way of creating trees and I guess these need to appear where there are no blocks above them?!

I ran into VBO memory issues trying to make larger chunks, so I kept them at 16^3.

Re: trees
I guess you would need a method that searched a cuboid of given space where the tree would go. If all blocks are empty a tree can go there.

Then there is making the tree… You could start by having a random height trunk (within limits) then scatter some leaves around the upper part of it. Once it’s working you can refine the leaf generation.

I think the hardest part is like you are finding…being able to easily switch from chunk to chunk when calculating things. You need some good utility methods that enable you to do that.

Yeah my chunks are 16^3, meant to say landscape to be made up of 32^3 chunks, but should be a lot more. Looking at putting the chunks into an octree, but want get collision working first and these damn trees.

I can now add blocks in any chunk.

I read a blog by a guy doing a voxel type game and draws trees depending on weather conditions, the land type etc, sounds interesting!

Implementing collision in my game. Problem I have is when player jumps on a block, my collision check for blocks in front and behind is telling me there is a collision when the collision is on block under the player…What is best way to implement AABB to make this collision better than just testing what block we are on?

Here is small video of my crappy collision detection:


https://www.youtube.com/watch?v=I5hDmlqiuuc

Thanks

Hi

Because the blocks are fixed on a grid I still do not think you need AABB as such. You would do for enities that are moving off grid. This is the solution I used, and have used in several games. This only works on things that are exactly aligned to a grid, like voxel cubes.

Please forgive my scribbles…

For a close up of the image: http://www.java-gaming.org/user-generated-content/members/167679/notes.jpg

The reason AABB is not needed is that the cubes are always a fixed size, and the position of its edge is always known - by definition of what it is. For many games this would not be true and AABB would be needed.

Because you also know where the bottom of the player is you know which vertical block to test.

Notes: I have made up a hoizontal movment value of 0.15f, it could be higher/lower. Vertical jump speed would depend on current acceleration.

To make movment even better, the player could have horizonatal acceleration too, once you have collision in place.

Thanks for the image and advice :slight_smile:

I take it you need to check when you move forwards, backwards, strafe left / right and jump?

This is my collision code:


private boolean isCollision(int dir)
	{
		Vector3f v = camera.getCameraPosition();
		double cameraPitchInRadians = Math.toRadians(camera.getCameraPitch());  // XROT
		double cameraYawInRadians = Math.toRadians(camera.getCameraYaw());  // YROT
		float f = (float)Math.cos(cameraPitchInRadians);		         
		float newX = dir * f * (float)Math.sin(cameraYawInRadians);
		float newZ = dir * f * (float)Math.cos(cameraYawInRadians);
			
		float tempx = (newX + v.x) / BLOCKWIDTH * BLOCKHEIGHT;
	    int tempX = (int)tempx;
	    
	    float tempz = (newZ -v.z) / BLOCKWIDTH * BLOCKHEIGHT;
	    int tempZ = (int)tempz;

	    float tempy = (v.y) / BLOCKWIDTH * BLOCKHEIGHT;
	    int tempY = (int)tempy;
		
	    int bx = (int)tempX; 
		int by = (int)tempY; 
		int bz = (int)tempZ; 
		
		bx = bx%BLOCKWIDTH;
		bz = bz%BLOCKHEIGHT;
		by = by%BLOCKHEIGHT;
		
		int zchunk = Math.abs(tempZ / Chunk.CHUNK_SIZE) * WORLDWIDTH;  // * 3 is the amount of chunks on Z
		int xchunk = Math.abs(tempX / Chunk.CHUNK_SIZE);// + (blockZ / Chunk.CHUNK_SIZE);
		int chunktoget = zchunk + xchunk;

		Block b = ChunkManager.getInstance().getBlockInChunk(chunktoget,
					Math.abs(bx),
					Math.abs(by+1),
					Math.abs(bz));
		return b.IsActive();
}

An example of it being called - this is in my main update loop:



                        if(!isCollision(0))
                        {
                                camera.down(0.05f);   // move player down as no collision
                        }

			if (Keyboard.isKeyDown(Keyboard.KEY_W))// move forwards
			{
				if(!isCollision(1))
				{
					camera.walkBackwards(movementSpeed * dt);
				}
			}
			
                        if (Keyboard.isKeyDown(Keyboard.KEY_S))// move backwards
			{
				
				if(!isCollision(-1))
				{
					camera.walkForward(movementSpeed * dt);
				}
			}
			if (Keyboard.isKeyDown(Keyboard.KEY_SPACE)) // jump...
			{	
				camera.jump(movementSpeed * dt);
			}


Not done checks for strafe left/right. Works for forwards and backwards but like I said, when jumped onto a block and then I try to move forwards, still thinks there is a collision?!

Cheers,
Steve

I found some odd floating point errors when calculating the players falling…

I found the exact floor of the block, and had to keep updating the players position to be the value of the floor. Otherwise floating point errors would mean that the player ended up trapped in a block just like you mention.

If ground = 3 and player <3. Then player height = 3.

It meant the player couldn’t get to 2.9998874 with errors and get stuck.

Try adding some floats in a loop and you will see what I mean. You won’t get the exact answers you expect. This may or may not be relevant…

It is weird,

When my game starts, player is at 0.5f on the Y, when I jump and land, player is then at 0.99f on the ground? When I land on a block, say block that is one high, my player Y is then 1.99f which seems correct, but then I cannot move forward as like I say, thinks there is a collision even though my collision when moving forward is checking +1 extra on Y coordinate…so, when on a block at position 1.99f and I move forward I check at 2.99f on the Y, this is why I cannot understand that it thinks there still is a collision.

Thanks

Finally got the bug sorted, was a silly mistake but fixed it through outputting debug info to the window. So now I can collide with blocks and jump on and off them. Must admit, it isn’t perfect, I guess you would need AABB for that…

One issue I want to sort out is to allow the player to build a block one unit in front of them, at the moment, it is about 4 units in front, using this to get the Z (how far in screen - hypotenuse of triangle):


Vector3f v = camera.getCameraPosition();
double cameraYawInRadians = Math.toRadians(camera.getCameraYaw());
float f = (float)Math.cos(cameraPitchInRadians);		         
float newZ = 6 * f * (float)Math.cos(cameraYawInRadians);

Or, the players height needs to be more…

To change the distance of placement, rather than have it at a set value you will need to implement 3d picking. Test what block you are looking at, so if you look at a block 1 unit away you can build there, or look at a block 3 units away and build there.

Using sphere to AABB for collision detection, but having issues, this video shows the problem:


https://www.youtube.com/watch?v=bbxRRBDBWRQ

Note, at the moment I’m checking all blocks in the chunk player is in.

So, walk forwards and collision occurs, then turn around say 100 degrees and then move forwards, still got a collision so cannot move forwards - maybe this is because I’m checking all blocks in the chunk and I guess should just check the one in front if moving forwards, one behind if moving backwards etc?

Thanks

Just use the simpler method I described in some other thread (simplified):

  1. Floor positions at (x-xsize, y-ysize, z-zsize) and (x+xsize, y+ysize, z+zsize).
  2. Use for loops to get every block between the two positions.
  3. If there are any blocks, collision is true.
  4. Otherwise, collision is false.

Sphere-AABB is only useful if you want people to be able to ‘roll’ over the edges of blocks instead of just falling once you get to a certain point. And that requires more physics.

Most players won’t care anyway.

Hi,

Thanks for that, but could you clarify what xsize, ysize and zsize are?

If my player is just one unit which the blocks are too, do we just not check the block in front, behind, left or right depending on if moving forwards/backwards etc?

I did use AABB to AABB but got same result as Sphere to AABB - think my issue is not detecting the collision, but what to do once a collision has occurred.

  1. Create a new position that is the same as the old position
  2. When moving, change the new position, not the old one.
  3. Check the new position for collisions. If there is a collision, leave the old position the same.
  4. If there isn’t a collision, set the old position to the new position.

And xsize, ysize and zsize are the (half) size of the player on that axis. (if the player is 1x1x1 then xsize, ysize and zsize are 0.5)

@HeroesGraveDev - thanks, will give it a shot.

So, instead of checking every block, just check the ones you mentioned.