What are /r/VoxelGameDev's favorite Products & Services?

From 3.5 billion Reddit comments

Sounds like what you're asking for is picking.

Take the 2D mouse screen coordinates, and unproject them using the projection matrix, at both the front and back clip planes. The resulting 2 points create a line you can use to then test intersections within the scene.

I'm using jMonkey (java), and while it is a bit like using an ion cannon to drill a hole it handles all of the rendering dirty work while still allowing me to output raw geometry, meaning that I can use voxel-specific optimizations and it will then further optimize raw geometry. It also has lots of other game engine features (sound, physics, network, etc) that will be useful for later development.

Another month, and another interesting voxel quest update from /u/gavanw/, detailing some of the technology he's using (hence of interest here). There's also some interesting discussion on Hacker News.

Seven days to die is an example of a voxel game with structural integrity. And yes, buildings do collapse. Buildings collapse in my voxel game too, though it is quite simple since it only collapses floating structures.

Edit: Also, red faction did destruction by connecting many small parts together to make structures. These small parts were programmed to be able to break apart from other parts with enough force, so there is a representative volume, just not a voxel one.

Voxelshop is now open source under the Apache License. It's Java so not my cup of tea, but perhaps others will find the code useful or want to contribute.

Hello fellow voxel game developers! After 9 months break from development of my pet project (joined a new company) I finally launched it on Google Play! I spent 2 weeks of my Christmas staycation and prepared the project for the release. At least something to distract from what is happening around.

Music for the trailer and game was created by my 12 y.o. son using Garage Band, and the head of QA was my 7 y.o. daughter.

The game is written in C++ with my old custom game engine and uses:

​

• a greedy voxel mesh generation algorithm
• dynamic voxel world built from 32x32x32 clusters
• simple AI with state machines
• Minecraft-like pre-calculated ambient lighting
• dynamic water (still glitchy) - water fills connected areas
• real physics with Bullet
• path finding with Recast

​

And it's all runs on 7 years old mobile phones!

​

The game is here: (with a staggering zero downloads, as it was launched today) https://play.google.com/store/apps/details?id=com.yak32_games.iron_cube&hl=en&gl=US

​

That was relatively easy and now I need to do the most terrifying part - promoting the game on Google Play somehow. Any suggestion guys? It's so different now comparing to 2013 when I launched my first game and organically reached 40 thousand downloads without any marketing somehow.

I've been working on one the last few weeks, it's running pretty good using unity. Although on android it's hard to get it up to 60fps with realtime shadows when pushing a lot of triangles.

here's a video of the windows version (don't mind the graphics, it's a wip ;)

Hey, I actually do that in my game! I go through the scene, collecting all the potentially visible voxels in the current frustum, work out levels of detail, then send the resulting list to the GPU and render all the voxels with one instanced rendering call. I try to do this once per frame, but in a pinch every-other-frame is usually just as good.

I don't currently do any occlusion culling, but I'd like to in the future.

Here's a screenshot of how well that can turn out: http://www.indiedb.com/games/scrumbleship/images/expanded

If you'd like to look at the code, give me a PM and I'll hook you up : )

Cheers!

You could check out Roblox though I don't know much about it.... I think it has some voxel stuff built in and you and make your own 'adventures'.

But I don't know of any plug-and-play or graphical systems for making voxel games. Unity is the easiest choice for 3D games, with a voxel plugin from the asset store. You'll still need good programming skills though.

Hi, I have a series called "let's make a voxel engine" which I basically have documented the steps I have used to make my very own voxel game...

https://sites.google.com/site/letsmakeavoxelengine/

My videos are here : http://www.youtube.com/alwaysgeeky

This could be a good start for you if you know C++ and 3d programming.

Good luck :)

If you allow other voxels than cubes you could build dodecahedra or other polyhedra. Starmade does this and it looks pretty sweet.

Java is not a great platform for making voxel (or "bloxel", as I've come to call it) games, or any games in general. Java lacking structs and its generic erasure makes it difficult to write nice code and have it be performant at the same time. In the end it depends on the scale you want to go for.

Minetest is an existing engine I know of, written in C++, but you can built your own game on it just using Lua scripting.

I'm afraid I don't have much experience with Blender so I can't help you with this, I was just pointing out that in theory it is possible. But it depends on other factors, such as how MagicaVoxel exports its .obj file. For example, does it export a list of cubes or one big mesh? Does it share vertices between faces and does it do greedy meshing? You'll need to do some experimenting and have experience with Blender to work this out.

Alternatively, I've just remember there is another voxel editor you might want to check out. It's called VoxelShop and I think is already supports textures and/or per-face materials? Again I don't have any real experience with it.

I haven't looked into Qubicle, but while I was working on my voxel project I found MagicaVoxel could do everything I needed it to, and more. It may not stand up to professional grade software, but it's free to use and it was everything I wanted it to be. I'm pretty certain it can output to 2d PNG, but I'm not sure what kind of control you get over it. It may be worth checking out, either way.

Octrees of cubes = no.

Octrees of chunks = maybe.

You probably would store chunks in a sparse 3d grid anyway, therefore you can access every chunk at any moment. Octree as a structure may exist virtually in that case. Just test large areas of chunks against frustum and then if it passes draw chunks from x0,y0,z0 to x1,y1,z1.

16^3 is small for chunks, modern CPUs can easily handle 32^3. And that alone will make your draw call count 8 times less.

Sadly I don't know how unity works, but in OpenGL there are many fancy ways to eliminate draw calls almost completely. In OpenGL 4.2 you can do that 100%, to batch all the chunks together you'll have to generate or upload their relative positions into a shader and use ARB_base_instance to connect batched meshes with its position. In earlier versions you can end up generating a mesh once and uploading it with index/vertex position shift. It's still faster than generating the mesh from scratch. That way you can batch multiple chunks together as well. I do the second, with exception that I actually generate everything from scratch every time, leaving some space for future optimizations. Works quite fast. Given that I have a LODed terrain, LOD switches do not take more than 100ms. For more details: http://www.opengl.org/wiki/Vertex_Rendering. Sorry if it's useless for you, because of unity usage.

However if you can keep the draw call count for map under 1000, I think it'll work without any further optimizations just fine.

I use flat arrays as well, they are quicker than octrees though more memory hungry. That can be mitigated with compression however.

You seem to be doing most things right. However I noticed you are using 3 separate VBOs for normals, positions, and texcoords. Instead you should use interleaved vertex data and store it in a single VBO.

You are right that dynamic allocations can slow it down. Instead of using a vector and push back, I use an array that is large enough to store all possible combinations of vertices. Then I just index into that array and reuse it. So you never have to do any dynamic allocations, and you dont have to make the calls to push_back(), which is more expensive than a simple array assignment.

Linked lists are bad, you are right for not using them :)

I think a main reason your meshing is slow is because you are generating a collision shape from your geometry. If your voxels are cubes, you dont actually need to generate a complex collision shape since each voxel has an implicit bounding box. However if you are doing this to work with a physics engine then it may be the only way.

You should definitely do some benchmarking. Use a precise timer to time the different parts of your meshing algorithm to see what parts are slow. My guess is that the physics collision shape generation is the issue, perhaps you can figure out how to get rid of that or optimize its creation? Or perhaps you can create the collision shape in a separate pass after you remesh the chunk, so that the chunk mesh appears instantly but the collision shape updates a frame or two later?

This article will help you a lot I guess. But to answer quickly I’ m pretty sure they used some tools developed by UE4 but no voxel based program because the game is not in voxel (I might be wrong I’m a beginner too)

Possibly, I honestly don't know. But as far as I can tell it originally came from a demo of Unreal Engine 3, which had different licensing. They might have re-licensed it more liberally since, though.

Thanks I'll go see it, for a year and a half I have developed this game and it is finally finished, you can try the Game if you want

https://play.google.com/store/apps/details?id=com.OpniDevStudio.VoxelTD

It looks bad because you have two triangles per face each peforming barycentric interpolation between tree vertices, instead of one quad and bilinear interpolation between all 4 corners. https://www.slideshare.net/Mark_Kilgard/sigraph-asia-2008-modern-opengl-presentation/74-74Fair_Quadrilateral_Interpolation_glBeginGLQUADS_glColor3fvredglVertex3fvlowerLeft

Looking good so far, dunno how long you have been making it but you have good progress.

Just as a note if you are interested, you might find the tutorials/articles that I wrote on voxel development helpful:

https://sites.google.com/site/letsmakeavoxelengine/

Good luck! :)

i will eventually make a post on my blog about how i used Perlin to generate the terrain, how i calculate temperature, but i won't make that until i implement biomes.

For now i am working on very minor optimizations, and then tree generation.

If you have been thinking of doing something like this, my suggestion is just start, when you find yourself with a couple of hours available and in your pc, just start reading articles and seeing examples of other engines. I found this very helpful: link

Also you’ll want to learn about the graphics pipeline, and how it works. That you can learn later though. For now, just start by setting up a C++ development environment. Visual Studio will be the easiest way to get your first program up and running. Just download the community edition since it’s the most popular and free https://visualstudio.microsoft.com/

If your getting into game Dev I suggest you check out Godot and just go straight in with their python like 'GDscript'

Everything happens right in the engine and it doubles as an editor. The whole thing is a single EXE that's like 32 mb or something.

You can even load it from a flash drive if you have some time over lunch. 😄

Give it a shot you won't be disappointed. https://godotengine.org

Nice - these remind me of quasiperiodic Faraday wave patterns from my research days.

One interesting aspect is that if you take two equal grids with one rotated by Pi/4 (45deg) you get a quasi periodic lattice because sin(Pi/4) = 1/sqrt(2) which is irrational.

This paper has some info on embedding geometry into leaf octree nodes:
https://www.semanticscholar.org/paper/Efficient-Sparse-Voxel-Octrees-%E2%80%93-Analysis%2C-and-Laine-Karras/5ca07a56725f8ae6c74778a86a4736ebaab6add6

>I really like the sphere look - while it is just an illusion, how do you handle the seams, for example, when the player runs around that planet (if that is supposed to work) - do you have something in place to merge the borders (because a flat surface will just not wrap around a sphere)

The illusion is managed in the same way as in the logic of reality, you cannot see at your level of size and distance, that the earth is round, it could logically be flat. Here, it's the same thing, the terrain is flat, but by bending, you can give the impression that it's a sphere. Despite the distance, you will have the impression that the terrain is round.

​

Example if you are directly on it, you will not be able to see beyond a certain distance, and therefore you will be able to believe that it is a planet. If you are high up, you will see a planetary aspect, but only because you will see because of the curvature, a limited vision of the terrain and which will rotate like a planet if you move. The illusion of a planet is created by choosing an appropriate percentage of curvature, if you take a percentage too high or too low, then the illusion no longer works.

​

If curve and distance management is poorly managed, then the illusion may no longer work. We must therefore seek a good compromise to create a fairly good illusion.

​

However, the lower your height with the terrain, the shorter your long-distance view.

​

Translated with www.DeepL.com/Translator

Not my work but I thought it looked pretty cool! There's an article/interview here: https://www.hackster.io/news/nick-matthijssen-s-open-source-fpga-craft-puts-a-minecraft-clone-on-your-lattice-ice40-fpga-345a9d41865d

Don't forget that tools like zbrush are very popular these days. Editing voxel terrain could be a much better solution for art workflows, even if it ends up as polygon soup. That also means storing your assets as voxel data is in some cases better than just polygons. Think about voxels as an improved version of height-based terrains. But when it comes to buildings and such, it's questionable.

Also take a look at sauerbraten: http://sauerbraten.org

Yes, it's not a big game, but it uses voxel-like structures and doesn't feature destruction. As a result of voxel-like structure level editing is fun in this game.

In my opinion the worst problems in all LOD algorithms comes from a fact that you can't really avoid dependencies between chunks.

The first obvious observation is that geometry on the borderline between two chunks requires a bunch of voxels from both chunks, which actually leads us to the fact that at a point in time we need to know something about 27 neighbour chunks (3x3x3). We can shrink that number down to 8 (2x2x2), if we build the geometry with a sensible offset. That's what I do, my algorithm runs on 2x2x2 blocks of chunks, there is a special fast case when their LOD level matches.

The second observation comes after vertices and triangles were generated. We need smooth normals on the terrain. Which means we need to have info about neighbour vertices as well. Even if the geometry itself can be generated without looking at the neighbour chunks (which is never true in my opinion), you still need info about vertices in neighbour chunks, because of the normals.

Not to mention that algorithms like naive surface nets generate non-manifold and if you want to clean that up as a post processing step, well, you need to see neighbour voxels there as well.

All this complexity made me rethink the way I will arrange the gameplay. No terrain modification will be allowed as part of the gameplay, even though I will feature editing mode of some sort, that works over a network. But also I'll add another layer of voxels for human structures, it'll based on the concept used in the sauerbraten engine (http://sauerbraten.org).

As game devs we can't really spend too much time in research, we need to evolve the game into the field of having the actual gameplay.

Btw, there is a video which shows early prototype of LOD switching, sadly it doesn't show terrain modification capabilities. As I mentioned earler somewhere I'm busy with render rewrite. I'm pretty sure I'll make more video this summer (or earlier, who knows).

The video: https://vimeo.com/83150040

Minetest, an open source voxel game engine, already has this as a tool called mcimport. The tool is also open source

I did a quick adaption to bytes where 0 == air, hopefully cross-checking against it should be enough to figure out what's amiss.

The generation here is just a sine on x and a cosine on z (Y-up axis) where everything below 32.0f is a solid (1) and above is air (0).

https://hastebin.com/omotayoqah.cpp

Image of results (which are about what I expected on/off terracing): http://imgur.com/a/aXwec

This doesn't answer your question, but as you don't have any responses I thought I would point out that MagicaVoxel supports animation and is free. But I think only in the older 0.98 version.

VoxelShop also supports skeletal animation, if that is useful to you?

MagicaVoxel details the VOX Format. Maybe it would work for you. I personally found it worthwhile to reuse code from my voxel project and create a custom editor.

I was looking into this at one point, but I was trying to figure out how to do it real time.

Here's a folder of bookmarks I was growing for it. I didn't get very far though, so idk if it will be a ton of help.

https://www.one-tab.com/page/gK9IsoN9Rk6mCepA4rDqQA

Please let me know if you find anything good though! I'm still interested in making this a thing.

You're going to want to re-generate the entire chunk's geometry when voxels change so that you can optimize it for rendering using greedy meshing. You don't want to be drawing a chunk with 2 triangles per voxel when a bunch of their faces are co-planar. You can store the chunk as a 32^3 in memory but you can still break up the meshes into 16^3, so that each chunk has 8 meshes associated with it. You could go even smaller with 8^3 voxel meshes and have 64 meshes to a chunk. It's a balance though.

You should allow the user to adjust the dimensions of the chunks and their sub-meshes - or have your engine dynamically figure which sizes to use depending on system performance, automatically.

Also, storing an offset into a buffer is virtually the same thing as a pointer. "Pointerless" doesn't mean you're not using actual variable pointers in the code, it means that the location of the data is inherently known without storing it anywhere. The simplest example of this that I can think of is a binary heap, where a flat array represents a binary tree. (https://www.section.io/engineering-education/understanding-min-heap-vs-max-heap/)

Also if you know java or anyone else looking at this and wants to give it a try, I created simple voxel starter kit using java, take a look here:

http://jmonkeyengine.org/groups/free-announcements/forum/topic/simple-voxel-engine-starter-kit/?topic_page=1&num=15

its easy to understand, read the thread and check out the sourcecode...

You're welcome, glad to know you solved your issue. Btw, I didn't mean to write anyone off, there are plenty of people far more knowledgeable than myself lurking around this subreddit.

Also, I have to recommend picking up something better than a text editor, for your own sanity :P Ever heard of Sublime Text? http://www.sublimetext.com/

The new Vox v0.16 update has been released on Desura and IndieDB:

http://www.desura.com/games/Vox

http://www.indiedb.com/games/vox

This update includes many new features and updates (most notable are monsters in the world and the quest system) and also many bug fixes.

A lot of people were asking for stuff to do in the pre-alpha, since the initial creation aspects of the game needed some gameplay compliments, so I have integrated some basic monsters and AI behaviors for people to play around with.

Still adding new stuff daily and continuing to add new features and requests that people are suggesting. Would be really interested in hearing any feedback you guys have. :)

This video is mainly showing the update to the intro and character creation. I have a v0.16 gameplay video that I will be uploading to YouTube tonight.

Thanks!

I do something similar, my chunks are 6x6x3 tiles and a tile is 24x24x48 so I can update multiple tiles really quick and then recombine tile meshes to a single chunk mesh to keep draw calls low.

Here's a little tech demo of it in action (unity webplayer)

Hi! This is my game called Coaster Tap. I made all of the voxel art with Magicavoxel. For the game engine I used Unity with the Universal Render Pipeline. I've grown to like voxel art a lot and my favorite voxel model I made so far has been the flying pigs.

I released the game for free today to the App Store and on Google Play. If anyone has any feedback I would appreciate it a lot!

App store link:https://apps.apple.com/us/app/coaster-tap/id1533461889

Google Play link: https://play.google.com/store/apps/details?id=com.HappyAdmission.HoppyCoaster

Thanks for reading!

Hi Voxellers this is my new game on Android https://play.google.com/store/apps/details?id=com.ZuluOneZero.EndlessElevator. A voxel style rework of an arcade classic into a relaxed endless shoot-em up with a unique 2.5D floor climbing vertical play space and a timeless spy themed soundtrack. Play as the LawMan. A deadly spy working to save top secret plans from the bad guys. You are stuck in the Worlds Tallest Building in the villains’ secret oasis and the bad guys are literally everywhere! Your job is to find the secret messages hidden in the building and to climb as high as you can. The higher you climb the more messages you collect. Shoot-em Up! Endless Elevator