Wow, those gorgeous screenshots that you went to the trouble to include, it's almost as if you're tempting people to take you up on continuing your open source work.
I took a stab at importing this into git. I've only got the voxelquest files, and not the others in there right now. I haven't looked it over too well but it was all done in zsh, so I might have made a mistake somewhere.
and yet again, it looks like i didn't have all the archives when i did this. only some of them. I'm going to attempt to do this again with all the files from the torrent but i suspect github won't take such a large archive.
So once I have all the archives, it ends up 2.4gb. Github won't take that without contacting them or paying for it, so for now I've uploaded it onto my own server. I'll make a gpg signature if anyone cares.
Awesome, thanks. If you need any money to support the server, let me know. I can also buy you the required github plan if the price isnt outrageous. :)
Adding on: if anyone feels the need to hoard all 11GB of the archives like I do I've made a torrent to soften the download a bit. magnet:?xt=urn:btih:e52b16bdf2eda8b678d5104517dba6ba05fb6089&dn=vqfiles
Important update, looks like Google drive limits file size to 20MB for public files. I will get a workaround up in a second.... (edit, fixed, drop box link is now on the site and appears to be serving larger files, although many are still in the process of uploading)
Yes, at some point, and looks like some others are already doing this. This is more of a short term patch between now and then, as I already feel I have been sitting on the source for too long.
Dwarf Fortress + Voxel Quest would only run on supercomputer clusters deep inside university research centers. But those 1-2 brave souls to get it working would surely experience the ultimate of pleasures.
I've been wanting a voxel quest DF client since I first saw voxel quest on HN. Does the voxel rendering really add that much overhead? I assumed that the majority of the rendering would be offloaded to the GPU, allowing the CPU to continue choking on how many well crafted tables the dorfs have seen today vs. the condition of their socks.
Most of the versions rely more heavily on the GPU. The fluid simulation runs on the CPU and is actually quite intensive (no surprise there). The most recent version uses the CPU to generate voxels, although it is also the least "stable" version and most people probably won't use it, but it is also the most flexible version (no GPU shader instruction limit, easier to run offline, etc).
Very interesting. Do you have resources you could recommend about working with/programming with voxels? Or how using voxels differs from using polygons in practice?
Voxels are ideal for representing volumetric objects and perform better in some edge cases for alternative rendering methods. Polygons are faster in most cases and tend to perform better for dynamic objects (i.e. a mesh with skeletal animation). Many claim that voxels have a more "pure" or timeless aesthetic, in the same way pixel art does over vector art, but that is subjective of course.
My recommendation is to dive in and code the simplest thing you can think of. When I first started this, I built a software voxel renderer, isometric, using just a pixel buffer (the original intention was to be able to dynamically create isometric pixel art).
I later ported it to the GPU (much harder, and much much faster).
I am mostly "self taught" but would be lying if I said the wealth of information on the web did not help (particularly when hitting obscure bugs). Anyhow, the point is the best part of the journey, in my opinion, is discovering things for yourself, even if you are reinventing the wheel. :)
Your isometric screenshots like this one [1] give me the idea of a 3D Lemmings-like game. Throngs of little critters walking stupidly through the environment, turning at right angles, sometimes building little cubical stairs, sometimes blowing themselves up to create spherical holes in everything. I wonder if that's the right gameplay idea for voxels.
Cool! I'll definitely have to try it out when I get some free time. And hey, there's nothing wrong with reinventing the wheel when you're just trying to have some fun!
Maybe allow others to contribute on a private repo. I love this project and I also am having a hard time with my personal projects but when I do I would love to contribute to this, as I am sure many other skilled developers would be. Just a thought. Open source would be great but even private election could get you to a release and fit your business model sooner.
Aside from the sprites, which are 2D pixel art I bought from a third party, everything is generated algorithmically. You can find many examples of people doing this kind of algorithmic generation, sometimes to great effect, on shader toy (i.e. https://www.youtube.com/watch?v=yMpG6qEb8js) and other places. I went down the path of procedural generation simply because I am not a great artist, and generating these assets by hand would have been pretty much impossible (given that they are volumentric and contain millions of unique voxels).
For technical people, I find this method of generating art to be quite empowering. If you can describe things in logical/mathematical terms, you can generate whatever your mind can think up. It generally is not going to win over a skilled artist for most applications, but even traditional pipelines often employ many procedural techniques.
I hope the linked post gets updated with an official repository once one is so deemed. Something about being a programmer would make me inordinately pleased with such bookkeeping.
Slightly OT... this is amazing and a generous contribution. I'm wondering though how come no version control from the start? For me this is the very first thing, just before setting up some sort of CI build... for any project at work or home. I kinda thought that this was universal. is it games that don't do this...or is there a wider population that manage versioning by daily or weekly zip files?
I have using version control since about 2006, but am only recently becoming a better git user. In retrospect, if I knew what I know now about git, I would have of course done it in a heartbeat. For a one man project I was hesitant to use other methods due to large, non-text files (which of course you can work around, with a little hassle)
@gavanwoolery - is there a chance you could also upload a single file with all the smaller ones (snapshots) inside? GDrive is taking forever for me on "Preparing download - Zipping" message... Also, I don't seem to see any 70MB files on the list?...
How unique is @gavanwoolery? Would something like 'reverse kickstarter' be viable for building an engine and small game out of this? I for one would happily donate for any programmer building this towards an OSS-engine and demo game. If we 'instruct' the programmer to build MVP-api's could something like that work? Then others could pick that up and build from there. I know I am massively underestimating the thousands of hours put in and to be put in, but somebody any ballpark on hours etc?
I once downloaded and tried a version, did not seem to render correctly. Maybe my ati 6870 is a little slow, I don't know. I'm still excited about this, gpu voxels sound powerful.
The reason for this (at least as I understand it, which could very well be incomplete and/or wrong, as I have little background in dealing with shaders) is that the version on itch.io (which is compiled from source code on github at https://github.com/gavanw/voxelquestiso or https://github.com/gavanw/vqisosmall ) has a bug in (at least) one of the shaders, compiled from /src/glsl/GenerateVolume.c:
The bug (or how I understand it, which, again, could be wrong) is that that specific shader is mixing sampler2D and sampler3D uniforms, which is forbidden by the Opengl 3.3 shader spec.
The reason it works at all on NVidia cards is that apparently NVidia's shader compiler plays fast and loose with that part of the shader specification and allows mixing sampler2D and sampler3D elements, while ATI/AMD and Intel's shader compilers will fail to compile that shader.
Failure to compile the shader results in voxel quest only rendering the 'ocean' tiles, tree tiles (without lighting), and building tiles (again, without lighting), and everything else as background/sky gradient.
Someone committed a "fix" to one of the github trees which more or less patches out that shader or the offending part of it, but this just means it renders the wrong way on ALL cards, including NVidia ones.
Hopefully it will eventually be fixed properly in an opengl shader spec compliant way.
Yep agreed - I found that someone's fix broke it, and then I got employed and did not have time to go in and fix it, but you can look at older commits in the repository. AMD drivers may encounter fewer bugs in newer versions of the code, but I am not certain. I will try to clean up these things over time, when I get it :)
Do these run in any usable form for those of us who wish to have a look? i.e. is there merit in someone providing an .exe (or is it worth non-game-devs figuring out how to build the thing)?
They do run, but I will have to provide instructions regardless as it is a bit confusing without knowing all the controls (i.e. how to drop entities into the world, take control of them, toggle debug commands, etc).
Awesome, thanks! Also, after getting back into heavy git usage these days, I appreciate its value much more. Wish I had started a private repository from the beginning, but too late now of course.
Very hard! Most modern hardware will already struggle to keep up to speed, and not dropping frames is super important for VR. But if you lower detail settings appropriately, it is definitely "doable" - additionally you will have to work around any screenspace effects like SSAO.
I haven't looked, so I have no idea whether I agree or disagree, but I don't actually care - it's low value comments like these that discourage people from sharing their work with the world. I would much rather live in a world where sharing was easier rather than harder.
I am looking forward to it. Don't get me wrong, I think the stuff you did there is impressive and I can't imaging where it gets when you have a proper source code with people contributing.
I would start with putting header guards in the files and remove the f_xxxx_ from your file (e.g. advanced-renamer can do that for you). Another suggestion would be to put everything the .exe needs into the "bin"-folder, currently your .exe loads some shader from your "src"-folder (or I did something wrong). I would also make a "third-party" folder in "src" and put all third-party stuff in there (also the LodePNG, zlib and bullet stuff in your main.cpp).
