I use a Ray Picking library that I created for convenience, source can be found at: https://github.com/zFollette/RayPicker(If you want to use it, go ahead, but be aware that it is set up for 1x1x1 cubes.)

Interesting, however there's no need to specify that you're not making a Minecraft clone. But do as you wish.

A tip: if you're not already doing this create the terrain as 1 big mesh eg, make all the block objects, iterate over all the blocks in the chunk or level and for each block face, if there are no adjacent blocks, add a quad to the mesh. Improves performance drastically.

Add in SSAO once you have the basics down, it just makes a voxel game look so much better.

What is hypoctritical about it? It is not a mine craft clone, but It isolates the CREATION aspect of mine CRAFT. All I did was mix the names. Just because it has 'craft' in it, does not make it a mine craft clone.

Interesting, however there's no need to specify that you're not making a Minecraft clone. But do as you wish.

A tip: if you're not already doing this create the terrain as 1 big mesh eg, make all the block objects, iterate over all the blocks in the chunk or level and for each block face, if there are no adjacent blocks, add a quad to the mesh. Improves performance drastically.

Add in SSAO once you have the basics down, it just makes a voxel game look so much better.

Why would I make all of the blocks objects? That seems like a waste of new instances. Though, since my block adding method uses a a form of normal vectors to add blocks adjacent to the selected face, I can definitely do that, I just don't know how to add multiple textures to a face. But I think I can figure it out.

Statically create one instance of every block type and re-use that one. You're correct, a new instance for every block would be entirely way too wasteful.

Also, Swordsminer maybe you could be less offensive? Does it matter that much? Let the man make what kind of game he wants, he doesn't need that kind of useless criticism.

Ahh, every block type, I though he meant every block. I do create a static instance of every block type, maybe not in the way you'd think (a block object) I just make an array of floats indicating the x value of each texture (all 6 faces) and the y value of where the textures are located.

That's called greedy meshing (if you didn't know!) and it's useful in some cases, but not all. Do you plan on doing lighting or having attributes for different blocks? Greedy meshing only works with blocks that are exactly the same, or else things become buggy. It's still worth it though!

I really recommend removing faces that don't touch air at least. Frustum culling is another huge performance boost, and have a view distance limiter where only chunks within a certain area are loaded, other wise keep the chunks on the disk.

There are a lot more optimizations, those are just some big ones I know of!

That's called greedy meshing (if you didn't know!) and it's useful in some cases, but not all. Do you plan on doing lighting or having attributes for different blocks? Greedy meshing only works with blocks that are exactly the same, or else things become buggy. It's still worth it though!

I really recommend removing faces that don't touch air at least. Frustum culling is another huge performance boost, and have a view distance limiter where only chunks within a certain area are loaded, other wise keep the chunks on the disk.

There are a lot more optimizations, those are just some big ones I know of!

I may hold on the 'greedy meshing' for now, as it would screw with my Ray Picking. I have a view distance limiter. What is frustrum culling? And I will look into the air thing.

Frustum culling. The frustum is (in the most basic sense) what the player can "see". Everything that is on your screen being rendered is in the frustum. It's much more technical than that, but Google loves being asked questions!

Frustum culling is the act of not rendering "something" that isn't in the frustum. In your case, you wouldn't render chunks that aren't visible in the frustum. It helps immensely with performance, mainly because the engine isn't rendering so many vertices when the late cant even see them.

For instance, in an old voxel engine I could have thousands of chunks loaded at once because the renderer was only ever rendering at max less than a hundred. If I didn't have frustum culling, the engine would have to render all the chunks, which obviously would never happen.

I was thinking about my game, my bad. For my puzzle game built with blocks I have to haev a seperate instance of each block. I'm fully aware that what I said was wasteful I just was thinking in my game at the time. So yes, create one instance of each block.

How is this constructive at all? Maybe you think your game is more original - uh, wait, it's based off a tv show. And normally I would be fine with that, but now you're calling other people hypocrites...

I assume that all the plane equation/picking questions were related to this. This is a prime example of the importance of asking questions about the problem you want to solve rather than how you think you want to solve it.

I assume that all the plane equation/picking questions were related to this. This is a prime example of the importance of asking questions about the problem you want to solve rather than how you think you want to solve it.

I don't really follow your question, but yes, my picking equation questions were for this. But I understand them now, and am able to solve them 9/10 times with pencil and paper. I for one like to understand what I am implementing.

How is this constructive at all? Maybe you think your game is more original - uh, wait, it's based off a tv show. And normally I would be fine with that, but now you're calling other people hypocrites...

I don't really follow your question, but yes, my picking equation questions were for this. But I understand them now, and am able to solve them 9/10 times with pencil and paper. I for one like to understand what I am implementing.

There was no question. I was making a statement. And I'm not picking on you. A very high percentage of questions people ask are how they think they want to solve a problem and not the problem itself. Wanting to understand what you're implementing is a very good trait. Another is reducing what functionality you need into minimal form to meet your requirements...assuming you need/desire to implement that functionality at all (vs already have a solution and/or can find one within a reasonable time)

Most problems of the form "I need to intersect a ray with a plane" are problem misstatements. In this case you needed two functions. The first to find the starting point and direction of the ray for the pick. And a second to examine the world with the ray. For this second problem you don't need planes at all...a 3D DDA is much easier to write and (should be) much faster. Of course picking is of no performance concern, but this function can be used for all ray vs. world checks.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org