voxel game

[laggyluk]

edit: public repo is here: https://github.com/laggyluk/brick_engine
or engine. or both, anyways i'm working on it. current state is a bunch of cubes that can be edited, saved and loaded. Doesn't look pretty yet, need to add some lighting/shading. made in lazarus and opengl
http://www.youtube.com/watch?v=svjcsXlwQSQ


http://www.youtube.com/watch?v=svjcsXlwQSQ

[User137]

It looks smooth. What kind of optimizations have you used?

[laggyluk]

not many, map is divided into 32x256x32 chunks, each has it's own vbo. then I'm sending only centre of each cube to the gpu instead of all the verts and cube is created in geometry shader. in the alpha channel is encoded info which faces are actually visible and since I'm planning to use deferred rendering then alpha is not much of use anyways. and I do frustum culling on chunks, 'radar' in right bottom corner shows which of them are rendered. runs pretty smooth on my laptop, we'll see if it's still smooth with lighting :P

[laggyluk]

attempt to implement deferred rendering when knowing opengl so little wasn't a smartest move. after few days of struggle I decided to do usual lighting for starters and yay, it works:
1087

[laggyluk]

deferred + ssao

http://www.youtube.com/watch?v=xbgbFSH6Q1s

btw anyone knows if this sort of 'shading' is ssao or some other technique?
1098

[laggyluk]

some better ssao :)
1099

[laggyluk]

Had a little break from the project but it turned out that my distraction can be integrated into the engine.
behold> behaviour tree logic editor connected to the sprite's artificial brain via udp

http://i48.tinypic.com/awydn8.png

[Ñuño Martínez]

Cool. Do you know if it works on Linux? And what's the minimal graphics card needed? I have some ideas about voxeled games...

[laggyluk]

I think it should work on linux after some minor changes to input handling.
runs at 50-60 fps on gt 540m which isn't that great.

now working on a terrain generation:
http://laggyluk.com/wp-content/uploads/2013/04/mineraly.png

[laggyluk]

Added 3d L-system for plant generation
As I continue to learn on the subject, I've begun to see major flaws in my design so I rather make a game than rewrite everything to make it a better engine.
Planet exploration game. Like all those other minecraft-settlers-dwarf-fortress clones that started popping around but in space ;)
http://laggyluk.com/wp-content/uploads/2013/05/l-system.png

[Rodrigo Robles]

Impressive work.

[Jimmy Valavanis]

Cool and promising!

[laggyluk]

thanks guys :)

[laggyluk]

Working on a 'job dispatching' system. Idle workers wonder around and pick up jobs that fit their skill set.
So far they know only how to dig holes ;)

http://www.youtube.com/watch?v=z8z859JTdzg

[Ñuño Martínez]

An idea: voxeled based "lemmings" game. Unfortunatelly it may be too dificult to manage...

[laggyluk]

yeah, like efficient 3d pathfinding ;0 time to figure it out

[Jimmy Valavanis]

As I continue to learn on the subject, I've begun to see major flaws in my design so I rather make a game than rewrite everything to make it a better engine.

Many times making a game instead of making an engine is much more efficient way of learning process, and definitely much more fun :)

[SilverWarior]

yeah, like efficient 3d pathfinding ;0 time to figure it out

I strongly recomend implementing some heuristic pathfinding algorithm.
While plain old A* can be easily implemented for 3D worlds due to it being node based it can become quite slow when number of nodes is large.
But if you do implement it using heuristic approach you can make it a lot faster.
And another suggestion. If you haven't been thinking about multithreading now is the time.
I have seen many games which are being limited due to singlethreaded implementation and not verry eficient pathfinding algorithms.

[laggyluk]

Yeah, I got the a* sort of working in 3d. I've read about jump point search algorithm being major improvement to a* however stuff I've read didn't state if it's also suitable for 3d grids (guess so but not sure).
My game's architecture has a central 'message pump' or sth that is used to separate all the major subsystems so it should work with multithreading. When actor needs a path calculated it adds that 'demand' to the queue rather then call the 'path finder' directly.

[laggyluk]

looks like this

http://www.youtube.com/watch?v=4OCMCr69BYw

[SilverWarior]

Nice!
One question thou:
Do you use increased weight values when units are moving uphil?
If you take a look at first units path you see that somwhere in the middle of the map units path goes upwards on the hill and then even backway a litle.
Now this could be caused by lack of increased weight when going uphil since destination was much higher (heuristic estimate distance of those bocks to goal was actually closer) or some error in pathfinding algorithm implementation (wrong node selected for moving forward).

[laggyluk]

work in progress :P currently they are following the path in x,z axes and float over the block beneath. nothing stops unit from climbing vertical walls or plotting path in which it wouldn't fit. yet

[laggyluk]

fun with lazers

http://www.dailymotion.com/video/x1098u9_planet-blox-blasters-test

[Darkhog]

Reminds me about Vox (http://www.vox-game.com/).

[laggyluk]

added water & atmosphere simulation

http://www.youtube.com/watch?v=4Sr48HzYS_Q (http://www.youtube.com/watch?v=4Sr48HzYS_Q)

[phibermon]

Lovely Jubbley! You're definitely onto a winner thinking game rather than engine, fast progress!

[laggyluk]

thanks :) I spent most of free time on it

[Darkhog]

Will you release this engine? We lack good voxel engines that are free to use, especially for Pascal. Anyway, will you do marching cubes rendering (variant of the algorithm that support sharp edges)? I think it would look cool then, especially for water voxels. Also, could test, if your engine could support world of current size but with voxels that are 1/4 of current voxels in size?

[paul_nicholls]

That looks really good mate! Can't wait to try it :)

[laggyluk]

Will you release this engine? We lack good voxel engines that are free to use, especially for Pascal. Anyway, will you do marching cubes rendering (variant of the algorithm that support sharp edges)? I think it would look cool then, especially for water voxels. Also, could test, if your engine could support world of current size but with voxels that are 1/4 of current voxels in size?
For same reason I wanted to make a voxel engine to make games in but at some point I realized that I can either spent few years making it abstract, universal and optimized or just make a game right away, probalbly in less time than that :p so not's gonna be an engine. No marching cubes, for now no animated models, just flat sprites. And current cube size is pretty well thought for what I need

[Darkhog]

Well, second best thing would be releasing source code of game unless it is intended for sale. Like I'm doing with Super Heli Land even as we speak (https://github.com/darkhog/SuperHeliLand).

[laggyluk]

possible but sometime after game is released. if id Software can do it so can I ;)

[laggyluk]

If any one cares here's a test binary.
http://speedy.sh/VCEsw/test-0.2.rar
before running either of .exes 'ChessType' font from main folder should be installed.
Sole purpose of this test would be checking if it can run on your system :P nothing to do in game yet and editor is not that intuitive.
I've made some placeholder menus and kind of like their 'ascii' style but it can also be a shot in the foot. What do you guys think?

http://laggyluk.com/wp-content/uploads/2013/07/ui-ascii.png

[SilverWarior]

Nice font. The only problem is that highlighted characters are extremly hard to see. Maybe if you make that the character highlight bracket is full and doesn't have vertical black lines it would be better.

[Darkhog]

Laggyluk, can't you load TTF directly from your game's directory, so we won't have to install it? Too many fonts clogs up system.

[laggyluk]

Font does that invert thing instead of displaying capitals. I'll have to change it anyways, it's licensed. No i can't load it.

[laggyluk]

No i can't load it. actually I can with LazFreeType

[laggyluk]

some updates to gui and ai

http://www.youtube.com/watch?v=6JdbIk6NnR4

[WILL]

That's pretty neat looking. Very stylish too. :)

Looks like a combination of Minecraft and Darwinia. Maybe a little Microsoft Office thrown in there too. ;)

[laggyluk]

thanks, I'd say Prison Architect rather than Minecraft :P

[WILL]

thanks, I'd say Prison Architect rather than Minecraft :P

Ironically I have not see too much of Introversion's latest game other than a handful of screenshots and a small article on it. I have read tons of tweets about it though. (I follow them on Twitter.) I plan to check out that game sometime. Don't worry take away all the cubes, digging and creating and it's nothing like Minecraft. :)

I do notice that you didn't refute my claims about a possible in-game Microsoft Office cloning. ;)

Seriously though it's a pretty neat looking concept. I'd love to see more of it once you have it further developed.

So is there a "game" developing out of all of this or are you aiming to leave most of the features unanchored so that it can be easily adapted like a game engine? Seems very sandbox-y. Which isn't such a bad thing. It's worked out rather well for Markus Person.

I think if you go the sandbox routine you'll have to offer a lot of "creative distance" and/or plenty of rewards for the players to achieve over the course of play.

I guess that's what makes me think of Minecraft the most.

[laggyluk]

It's gonna be a game, not an engine. Prison Architect concept is strongly based on Dwarf Fortress, only simpler. Mine is something in between.
Unlike in Dwarf Fortress there will be a goal - terraforming the planet, divided in to missions. Terrain will differ between games, also missions will be randomized to some extent.

[WILL]

Well it sounds cool. :)

[User137]

I've recently been more and more excited about voxel games, as you can see from some of my creations in starmade
https://www.dropbox.com/s/bs4cj7x1vz98cmf/station1.png


1191


But i also know lots of ways to make game features that don't yet exist. Not going into details about those, but one thing is the "infinite world". Does your voxel engine support that? Or would it run dry on memory after exploring a while. It is difficult to find optimization tips for the subject. Some things i can assume:
- Do not save chunks on disk if no modifications are done to them. They can be regenerated on request.
- Very big octtree and frustum culling should be used. Details on the octtree behavior regards to infinite world might not be simple though. By "infinite" we would mean limit of signed 32-bit integer for single block coordinates, and looping endlessly if possible.
- Generation from noise is the trivial part, although could also be used as optimization. For example 1 noise-map that is on whole chunk level, being quick lookup for knowing whether that chunk will have any blocks at all. For example, if
BlockHasAir:=ChunkNoise+DetailNoise*0.2>-0.3
it was calculated like that, then we could say that BlockHasAir is always false when ChunkNoise < -0.3-0.2.

And actually i'm propably not considering surface-like world at all, but 3D noise that makes unique floating islands and continents in 3 infinite dimensions.

[laggyluk]

infinite world would be nice but I don't actually need that in my game so after some thinking I dropped the idea. I'm a newbie to opengl and 3d in general so making 'perfect' game world would take me forever.

There are lot's of consequences for infinite world approach, besides saving the generated terrain. Ideally space should be divided to chunks with equal side length to not limit the max height of the world. I did go for fixed height (ie. 32x256x32 but can vary across maps) which results in world being sort of 2d grid. Also I don't stream chunks from disk but load them in one go and store generated mesh in separate vbo's. In my 'simulation' game it would take some more effort to update all the stuff like water, atmospehere and ai across that infinite world. So not this time :P

Btw what I really love about voxels is that it's not that much 'explored' as 'poly' world :P I mean there's a lot stuff to invent rather than use solutions that have been around for years

there's nice article about voxel world generation: http://accidentalnoise.sourceforge.net/minecraftworlds.html
I don't use that library but it gives some ideas

[phibermon]

I've recently been more and more excited about voxel games, as you can see from some of my creations in starmade
https://www.dropbox.com/s/bs4cj7x1vz98cmf/station1.png


1191


But i also know lots of ways to make game features that don't yet exist. Not going into details about those, but one thing is the "infinite world". Does your voxel engine support that? Or would it run dry on memory after exploring a while. It is difficult to find optimization tips for the subject. Some things i can assume:
- Do not save chunks on disk if no modifications are done to them. They can be regenerated on request.
- Very big octtree and frustum culling should be used. Details on the octtree behavior regards to infinite world might not be simple though. By "infinite" we would mean limit of signed 32-bit integer for single block coordinates, and looping endlessly if possible.
- Generation from noise is the trivial part, although could also be used as optimization. For example 1 noise-map that is on whole chunk level, being quick lookup for knowing whether that chunk will have any blocks at all. For example, if
BlockHasAir:=ChunkNoise+DetailNoise*0.2>-0.3
it was calculated like that, then we could say that BlockHasAir is always false when ChunkNoise < -0.3-0.2.

And actually i'm propably not considering surface-like world at all, but 3D noise that makes unique floating islands and continents in 3 infinite dimensions.

With the right techniques your limits are beyond that. Available memory as the limit should always be possible. A voxel game using an oct-tree is easy in this respect although you wouldn't use an oct-tree for the entire world, rather just a local frame of reference. Same for rendering say a whole solar system, you wouldn't actually calculate or pass floating values on the outer limits of precision as you'll have a terrible time calculating things for rendering, normals etc Instead you'd translate them all towards precision and perhaps split your rendering into layers, lowering the scale as you get closer to the camera

[laggyluk]

added ambient occlusion :D and some gameplay but nothing worth showing yet.
window on the left has only AO enabled and right and bottom also SSAO

http://laggyluk.com/wp-content/uploads/2013/08/ao-ssao-1024x575.png

http://laggyluk.com/wp-content/uploads/2013/08/ambient-occlusion-1024x470.png

[hwnd]

How you can render so many cubes with such fps? What culling stuff you use? Using octrees also?
Also i assume you have great new and fast hardware?

[laggyluk]

actually it's running on my 2 years old laptop with 2 video cards, screenshots taken on integrated intel hd3000. what you see is a mesh made of visible cube faces rather than whole cubes. In full screen it gets choopy with ssao enabled but on gf540m it's still ok. and no octrees

[SilverWarior]

http://www.youtube.com/watch?v=6JdbIk6NnR4

What component do you use for representing logics graph in your video?

[laggyluk]

firemonkey ::) logic editor was made for a client of mine as part of mmo bot and I reused it here. logic is saved to xml and it's on the game/bot/whatever how it's gonna be handled so it's sort of project independent

[laggyluk]

Finally had some time to work on this again :D added direct actor control, 'system' for animating variables and undo/redo + workflow improvements in the editor. I think this is gonna end up as a action game after all..
http://laggyluk.com/wp-content/uploads/2013/12/Untitled.png

[pitfiend]

looks really cool!!! (hope you release something playable like a tech demo or something soon)

[de_jean_7777]

This looks awesome.

[Ñuño Martínez]

Yes, looks really cool.

A personal wish: Is it possible to make it looks more "pixelated"? Actually I have some old ideas about games involving voxel, and I like the old-school pixelated looking. Look at Ken Silverman's Voxlap engine (http://www.advsys.net/ken/voxlap/voxlap05.htm) for reference.

[laggyluk]

thanks guys. @Ñuño (http://www.pascalgamedevelopment.com/member.php?854-%D1u%F1o-Mart%EDnez) My voxels are not really voxels (same goes for almost all 'voxel' games, including minecraft) but a 3d grid of cubes. To get more pixelated look it would either require using lower resolution or scaling cubes down. can't really do the latter, I'm getting choppy fps with not so big map in view already.

[phibermon]

It's looking great man! :)

Sorry to be an arsehole - but Voxels are a concept - a 3D pixel. Which can't actually exist without some form of truly free floating 3D, digital display. They can be represented on a 2D screen with a 3D projection of say, a cube or just a filled square/rect like the older voxel engines used to do (or spheres even as is the metaball like future of voxel engines).

Your voxels are not voxels no, but they're as voxel as any other voxel that has so far yet existed.

Anyway, my OCD for correct semantics dealt with - fantastic work! loving it :)

[Ñuño Martínez]

I think I didn't explain correctly. I was asking about if your "non-voxels" can look more like actual voxels instead of "small boxes". Ken Silverman's Voxlap achieves it by "deactivating" shadows on the cubes, so they look "flat", making it more "pixelated".

Actually Voxlap does it because it's faster (it uses a sofware renderer) but I like the feel it gives to scenes, specially if voxels are small.

[laggyluk]

stilll his voxels are really small compared to mine :P
funny thing though, if I run it in 320x240 it deosn't loose as much detail as 'normal' 3D game
http://laggyluk.com/wp-content/uploads/2013/12/320.png

[SilverWarior]

I forgot where I read it but some newer graphic cards suposingly have hardware support for single color voxel rendering.
On those graphics cards it is posible to have whole scenes made from tiny voxels and still achive high FPS, while achieveing similar by rendering lots of smal cubes wouldn't give same performance.

[Cybermonkey]

Sorry, my two cents (being off-topic): best voxel based game ever was Outcast.

[laggyluk]

update :) lately I was mostly working on multiplayer, taking a short break I've finally added bitmap fonts and console log in game window

http://laggyluk.com/wp-content/uploads/2014/03/logJest.png

[Ñuño Martínez]

looks pretty good.

Does it have support for 3D models? I have a few ideas for voxel based games.

[laggyluk]

looks pretty good.
Does it have support for 3D models? I have a few ideas for voxel based games.
no support for 3d models, maybe later. if there's later. unreal engine 4 release made me wonder if it makes any sense to work further on this..

[Ñuño Martínez]

(...) unreal engine 4 release made me wonder if it makes any sense to work further on this.. Aren't you doing it just for fun?

Anyway, I didn't like those last generation game engines out there. I think a game must look like a game, not like reality. I know, I can use a modern engine and make it look like a game, but then I should drop off a lot of the engine.

[laggyluk]

Aren't you doing it just for fun?

Anyway, I didn't like those last generation game engines out there. I think a game must look like a game, not like reality. I know, I can use a modern engine and make it look like a game, but then I should drop off a lot of the engine.
yeah but after so much work I only have a half assed engine, I could make a game in this time instead. at least now I know how 3d works.
anyways, I'm making the source public. if anyone is interested can take a look:
https://bitbucket.org/laggyluk/planet-blox.git

[Super Vegeta]

Shame to see the project dropped, cool to have to source. I'll give it a closer look once my exam session is over. :)

[Ñuño Martínez]

I should take a look too. May be we can do something with it.

[laggyluk]

in current state it makes more sense just to use it as an voxel levels editor I guess

[farcodev]

I'm in complete awe with this work o.O

I hope this will not fade away, the tiny Pascal community that we are, need this sort of tool. And these so called "next gen" engine mustn't prevent us to create our own tools, especially since they don't support Delphi and FreePascal/Lazarus. UE4 is for C++, so no thanks, added with the fact that "realistic" 3d require professional level skills out of range of most of the indie and open source worlds. Too much art for so little gameplay content these years...

Btw thanks to make the source public! ;)

[Ñuño Martínez]

in current state it makes more sense just to use it as an voxel levels editor I guess

Then, I should look at the file format.

[Thyandyr]

Source located here:

https://github.com/laggyluk/brick_engine

I dont know why the forum/browser forces this to be a link and with %uFEFF suffix. Copy by hand to browser.

[SilverWarior]

I dont know why the forum/browser forces this to be a link and with %uFEFF suffix. Copy by hand to browser.

I fixed the link. It should work now.

[Ñuño Martínez]

Source located here:

https://github.com/laggyluk/brick_engine

I dont know why the forum/browser forces this to be a link and with %uFEFF suffix. Copy by hand to browser.

Thanks for sharing!

I see you included Windows DLL files. I can't test it now, do you know if it works on Linux?

[Thyandyr]

Thanks for sharing!

I see you included Windows DLL files. I can't test it now, do you know if it works on Linux?

The code relies on few other libraries, that are outdated now and impossible to get in the state they are referred in the code, so it does not compile. Other than that I do not know if it is Linux compatible.

[laggyluk]

Project relies on lnet and dcpcrypt which I might remove if I find the time, they shouldn't be needed for core functionality if I recall correctly.
For time being I've updated the repo and you can find their source in src/tools folders. I suppose this might break their licensing or sth, will try to clean this up.
Project now compiles but I get sigserv on opengl context initialization, tried updating dgl header with same result. It worked before and I didn't change my video card so it must be updated drivers causing this.

As for linux compatibility, I've made code arrangements for that in the early stage but didn't test it later so probably it won't compile as it is now.

[Thyandyr]

It does now compile (game and brickui, not server tho) with little work, but both just say 'Execution stopped'.

My skill with lazarus IDE is non-existent so I have no clue what to do. The source is useful in any case.

[laggyluk]

Tested brickUI on my old laptop and it works with both integrated intel and nvidia cards, fails on my desktop ati

[SilverWarior]

Tested brickUI on my old laptop and it works with both integrated intel and nvidia cards, fails on my desktop ati

Can you provide a small testing example or at least provide instruction for making one myself since I don't have any experience with your voxel engine?
I have three computers with ATI based graphics card (one desktop and two laptops) so I could do some testing and try tracking the problem of why your BrickUI is not running on your ATI based graphics card.

[laggyluk]

Well, I can live with it not working anymore, project is long time abandoned and I just wanted working example for Thyandyr.
If you still want to try it you'd need to download the source, install lnet and dcpCrypt components and then run the brickUI project. It crashes on the line with rendering context creation in my case.

[Thyandyr]

... then I'm sending only centre of each cube to the gpu instead of all the verts and cube is created in geometry shader. ...

Would you still take this same approach? (or use Tessellation shader) From what I can find online is very conflicting if this is smart or not.

Of course I would love to use CPU for other things, but then again the results can be buffered and only redone when the map info changes.

[SilverWarior]

If you still want to try it you'd need to download the source, install lnet and dcpCrypt components and then run the brickUI project. It crashes on the line with rendering context creation in my case.

For now I just removed "Inet" and "cdpCrypt" from Required packages and try to compile "brickUI.lpr" and I end up with bunch of "Duplicate identifier" errors. It seems that all of them are withing conditional define blocks like


{$IFDEF CPU64}
int = int64;
Long = uint64;
{$ENDIF CPU64}
{$IFDEF CPU32}
int = integer;
Long = longword;
{$ENDIF CPU32}


Now I have very little experience with Lazarus especially with conditional defines so I would be grateful if someone can explain how can I get rid of these errors properly.

[Thyandyr]

For now I just removed "Inet" and "cdpCrypt" from Required packages and try to compile "brickUI.lpr" and I end up with bunch of "Duplicate identifier" errors. It seems that all of them are withing conditional define blocks like


{$IFDEF CPU64}
int = int64;
Long = uint64;
{$ENDIF CPU64}
{$IFDEF CPU32}
int = integer;
Long = longword;
{$ENDIF CPU32}


Now I have very little experience with Lazarus especially with conditional defines so I would be grateful if someone can explain how can I get rid of these errors properly.

I tried to $DEFINE CPU64 and $UNDEFINE CPU32 but that didn't help, so I just manually removed all CPU32 parts. That helped.

[Thyandyr]

Would you still take this same approach? (or use Tessellation shader) From what I can find online is very conflicting if this is smart or not. What I do have in mind I will need my CPU for other things than tessellating, so I might take this same approach.

I see from the project code that you dropped the idea of voxelifying/tessellating in the geometry shader. Any post mortem comments?

[phibermon]

Benchmarking is your friend. This task is exactly the kind of thing geometry shaders were intended for - IE input a point, spit out a cube - but I'd personally benchmark generating the cubes in a geometry shader vs instancing cubes vs a hybrid instancing approach that can render identical groups of voxels.

The implementation of such a hybrid approach would likely be a balance between identifying groups of voxels to collapse into a single, instanceable data set and marking sets at generation time - modifying generation to implicitly generate known identical groups (the simplest being a completely filled cube of say 16x16x16 voxels) - these groups can be flagged and split into their individual voxels as and when they are altered - lowering the number of draw calls / instances for large continuous areas in many cases.

Tessellation would not be a good match for this problem - you define patches that are tessellated by feeding them into a control shader (which are then evaluated in the evaluation shader - basically a vertex shader that's patch aware).

The simplest possible patch being a triangle and the simplest possible group of patches to construct an enclosed volume would be a triangular pyramid - these are ill suited for tessellation into cubes - so the simplest possible geometry would be a cube - which is what you want anyway - ergo tessellation is not going to allow you to benefit when it comes to just throwing individual voxels at the GPU.

*but* if you go for the hybrid approach above - you could use tessellation on any continuous cube of voxels (say 16x16x16) *if* you needed the actual individual voxel's surface geometry on the surface of that amalgamated cube - for example per vertex lighting which you may be using with SSAO for a more pixellated feel.

This would mean you could have a single draw call / instance for a group of 16x16x16 voxels input as a single cube - but still be dealing (at least on the surface of that cube) with the geometry and positions of the individual voxels by the time you reach the evaluation and pixel shader stages.

You could further optimise this by having vertex data instances that represented 16x16x16, 8x8x8, 4x4x4 etc groups of voxels - then instead of splitting the entire group into voxels when it gets altered - you could just split it like an oct-tree. (really you'd just use a cube patch at different sizes + tesselation levels on the GPU and only treat it like an unbalanced oct-tree on the CPU)

The scheme you use will be heavily influenced by visibility / culling - I expect there's a sub-division level where just throwing individual voxels at the GPU is faster than feeding in a dynamic oct-tree like set of data and acting on it conditionally (actually I know there is at least on the hardware I have because I've already done all this)

Of course there's still the issue of colours/textures that could differ across voxels in a group - there's many ways you could handle this but in the scheme I propose it's rather tricky without using a ton of memory - you will hit memory bandwidth vs shader performance trade-offs pretty quickly with large 'worlds'.

Hope that provides some insight - have fun! :)

[laggyluk]

I see from the project code that you dropped the idea of voxelifying/tessellating in the geometry shader. Any post mortem comments?
Yeah, I've tried generating cubes from single point in geometry shader and performace was awful, way worse than using separate verts for each.