• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
CryoGenesis

Getting Cube You Are Looking At (Voxel Engine).

14 posts in this topic

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.
0

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
[quote name='Postie' timestamp='1344993321' post='4969671']
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.
[/quote]
I did think of that. But, I was wandering if there is anyway to get the block with some equation?
0

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
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.
2

Share this post


Link to post
Share on other sites
[quote name='Waterlimon' timestamp='1345036276' post='4969826']
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.
[/quote]
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.
0

Share this post


Link to post
Share on other sites
Hey thanks guys I got it working.
Do you know how to get the face you are looking at to place blocks?
0

Share this post


Link to post
Share on other sites
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
1

Share this post


Link to post
Share on other sites
You dont need trig if you know the position on the surface you hit. Just a few comparisons...
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='6677' timestamp='1345126083' post='4970178']
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
[/quote]

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

Share this post


Link to post
Share on other sites
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. [url="http://lodev.org/cgtutor/raycasting.html"]Lode's tutorial[/url] has a very nice explanation which you should be able to turn into 3D pretty easily.
2

Share this post


Link to post
Share on other sites
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)
1

Share this post


Link to post
Share on other sites
[quote name='powly k' timestamp='1345139594' post='4970270']
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. [url="http://lodev.org/cgtutor/raycasting.html"]Lode's tutorial[/url] has a very nice explanation which you should be able to turn into 3D pretty easily.
[/quote]

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...
0

Share this post


Link to post
Share on other sites
[quote name='Waterlimon' timestamp='1345142321' post='4970286']
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)
[/quote]

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.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0