• FEATURED

View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

# Getting Cube You Are Looking At (Voxel Engine).

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

14 replies to this topic

### #1CryoGenesis  Members

Posted 14 August 2012 - 06:09 PM

Hey I need help! (AGAIN...)
I'm writing a voxel engine. You can pick up and place blocks just like minecraft. But, it's just an experience project and it's not going to be a clone at all.
I've written a chunk generator that generates a world, the fps view (loads of trigonometry), all the basic collision and movement physics, and the block renderer.
Now all I have to do is make it so I can place and destroy the cubes. The problem is I don't know how to get the cube the player is looking at.
I have access to both the x and y angles, the player position, and a way to convert 3D space to voxel coordinate so I don't see why you can't use those to work out the block you are looking at.

Any helpful answers or links will get +1 rep and thanks.

Also, I'm using OpenGL.

### #2Postie  Members

Posted 14 August 2012 - 07:15 PM

You need to use a technique called ray casting. From the position of the player's eye (centre of the viewport) and your camera's direction vector you create a ray and then test that against your geometry to determine where it intersects.
Currently working on an open world survival RPG - For info check out my Development blog:

### #3CryoGenesis  Members

Posted 14 August 2012 - 07:25 PM

You need to use a technique called ray casting. From the position of the player's eye (centre of the viewport) and your camera's direction vector you create a ray and then test that against your geometry to determine where it intersects.

I did think of that. But, I was wandering if there is anyway to get the block with some equation?

### #4larspensjo  Members

Posted 14 August 2012 - 11:44 PM

Another solution is to use color picking. You need to code each face of the voxels in different colors. When the player clicks on the screen, you read the color at that pixel. This drawing is only done in the back buffer, so the player doesn't have to see it. (Though it is fun during development to see what it was, nice colors).

Notice that it is the face of a voxel you need to identify. The reason for that is when you add new voxels. That is done to the face of another voxel.

If you have an infinite world, it is difficult to enumerate the faces in the RGBA data, so you need to limit the size of the world that can be selected. A simple encoding is to store the x, y, and z relative distance (from the camera point of view) in r, g, and b. Every voxel have 6 faces, and this number can be stored in the alpha channel.
Current project: Ephenation.
Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/

### #5Waterlimon  Members

Posted 15 August 2012 - 07:11 AM

to raycast start from the block the ray starts from, if its empty find out where it exits the block and which other block it enters and repeat from that new position on the surface of that next block.

I think picking using the results of rendering would be kind of messy and possibly limiting.

o3o

### #6CryoGenesis  Members

Posted 15 August 2012 - 08:54 AM

to raycast start from the block the ray starts from, if its empty find out where it exits the block and which other block it enters and repeat from that new position on the surface of that next block.

I think picking using the results of rendering would be kind of messy and possibly limiting.

Yeah I think I'm going to do raycasting instead just because it would be a lot cleaner and so I don't have to code a lot more.

### #7CryoGenesis  Members

Posted 15 August 2012 - 10:47 AM

Hey thanks guys I got it working.
Do you know how to get the face you are looking at to place blocks?

### #86677  Members

Posted 16 August 2012 - 08:08 AM

By knowing the angle it enters the cube. If you know what angle it came from you know which face it had to pass through to get there, trigonometry will come in here

### #9Waterlimon  Members

Posted 16 August 2012 - 09:44 AM

You dont need trig if you know the position on the surface you hit. Just a few comparisons...

o3o

### #10CryoGenesis  Members

Posted 16 August 2012 - 11:17 AM

Well the ray pass through the box slowly so I'm guessing that I can get away with not using trig.
Even so, I will use it just for accuracy.

### #11CryoGenesis  Members

Posted 16 August 2012 - 11:17 AM

By knowing the angle it enters the cube. If you know what angle it came from you know which face it had to pass through to get there, trigonometry will come in here

Do you have an example of how I could use trig in this way?

### #12powly k  Members

Posted 16 August 2012 - 11:53 AM

Without knowing many relevant things about your engine I'd say picking is pretty ace instead of messy or limiting. You can find all your objects, voxels and gui elements with checking a single value, and your user is guaranteed to pick exactly the pixel he chose. If you do this by rendering to an offline ID framebuffer, you can even do it with practically no performance hit.

The math isn't overwhelmingly hard either, so you can just raycast through the voxels. And it doesn't involve reading back from the GPU, which is a nice feature. Lode's tutorial has a very nice explanation which you should be able to turn into 3D pretty easily.

### #13Waterlimon  Members

Posted 16 August 2012 - 12:38 PM

You can find the surface the ray huts by taking the position of the hit (i assume you dont use some laggy raycast which steps in tiny steps and each time checks what voxel its in...) and checling its distance from each 3 planes pointing along an axis.

Like if the distance of the point from the xz plane is about 0.5 (half voxels), it will be on one of the y axis surfaces depending of the sign (either -y or y surface)

o3o

### #14CryoGenesis  Members

Posted 16 August 2012 - 12:42 PM

Without knowing many relevant things about your engine I'd say picking is pretty ace instead of messy or limiting. You can find all your objects, voxels and gui elements with checking a single value, and your user is guaranteed to pick exactly the pixel he chose. If you do this by rendering to an offline ID framebuffer, you can even do it with practically no performance hit.

The math isn't overwhelmingly hard either, so you can just raycast through the voxels. And it doesn't involve reading back from the GPU, which is a nice feature. Lode's tutorial has a very nice explanation which you should be able to turn into 3D pretty easily.

Well, the way the engine (in its current state) gets the voxel you're looking at is just firing an invisible projectile in 3D space in a for loop. Every loop it checks it gets it's coordinates in voxel space by just dividing its x, y and z values by the voxel size. It then checks if the voxel at it's coordinate is alive or not(rendering) and returns the voxel if it is.
The way it gets the voxel to place is just working back the trajectory to the next block that isn't alive and sets it's alive boolean to true. It isn't a very good way because if you are looking at a corner of a block then the trajectory sometimes goes through the block. You can fix this by dividing the trajectory and increasing the amount of loops but it hinders performance a small amount...

### #15CryoGenesis  Members

Posted 16 August 2012 - 12:44 PM

You can find the surface the ray huts by taking the position of the hit (i assume you dont use some laggy raycast which steps in tiny steps and each time checks what voxel its in...) and checling its distance from each 3 planes pointing along an axis.

Like if the distance of the point from the xz plane is about 0.5 (half voxels), it will be on one of the y axis surfaces depending of the sign (either -y or y surface)

Haha yeah thats the way I do the raycasting. It isn't very laggy though seeing as instead of doing a 3d collision algorithm it just returns a coordinate in voxel 3D space so it doesn't hinder the performance unless I want perfect accuracy.
And thanks for the solution +1.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.