http://i225.photobucket.com/albums/dd202/highwingx3/poop-2.png The white cube represents the voxel/game world/enviroment which consists of millions of voxels and the player is a small dot inside that box. The blue rectangle is water. As the player/box moves over the water, the water tells the voxels inside the cube that it touches, to have the water property which makes the voxels behave as water/fluids. :o :P The green rectangle represents grass/dirt, every voxel that comes in contact with the green volume/area will be transformed into green grass voxels that have different properties than the water voxels! :o :P
There are few voxels in the Voxlap tech demo and the voxels are too big. Also, the map is too small, but if the map/volume had been, say, 10 times larger, the framerate would drop.. But if the Voxel volume/enviroment moves with the player, the voxel number would be the same at any given time and the map size could easily be hundred times higher! :o
Edited by apegomp at
0xC0DE at
Re: Layman's voxel engine idea
okay, from a technical point of view this seems pretty brute force to do something. You really don't want to move your enviroment instead of the camera, really.
I don't know anything about the voxlap engine. But let's take a 2D game as example (easier to explain). What you could do is move the 'data'. Let's say that your screen is the volume/enviroment. then you can loop through the 2D data (might be a tiled map, or even just a bitmap) with an offset.
Here's some pseudo code, in which camera_x/y is the offset.
Ken might correct me on this one, but I really don't think it's possible within voxlap to do stuff like that.
Edited by Hugo Smits at
apegomp at
Thanks for the reply :)
OK, so if we move a 2D heightmap into the static/stationary voxel volume/enviroment in the Voxlap demo, we could easily generate a large landscape that will look something like this: http://www.jasondoucette.com/games/voxel4s.png, except that the water is not flat because YouTube user tonyAmbles has implemented fluid physics in Voxlap! :o :P
Also, we could add a new "map layer" onto the heightmap, that defines the material properties (eg, blue areas have the water property, gray areas have a solid rock property) and then we could add another 2D layer on top of that, a "skymap" that puts clouds (cloud voxels have smoke/fluid properties ;) ) into the voxel volume/world/enviroment :o :P
The Voxlap community demands volumetric voxel smoke in Voxlap! >:( :P http://graphics.stanford.edu/~fedkiw/images/vortex_particles_smoke.jpg Why hasn't anyone implemented a fluid physics algorithm in a real-time voxel engine, already? :( YouTube user tonyAmbles said it is not very hard to make a 3D fluid simulation, but I don't think he has time, at the moment..
There is an Nvidia smoke tech demo, it's awesome: http://youtube.com/watch?v=1C6LrDzjfRw Are they using voxels? The fastest way to render fluids is to use voxels, right? ;D I think voxel engines have a big advantage when it comes to rendering lots of dense smoke..
I want something like this in Voxlap: http://youtube.com/watch?v=jhgITHR-NCk
I just made a new video in order to (hopefully) explain the idea better: http://youtube.com/watch?v=CQWv8J1LzsQ Enjoy! :o :P
I really want a fun voxel platformer/racing/fps game, but noone wants to use Ken's engine :'( People should give voxel engines a second chance >:(
Edited by apegomp at
Spacerat at
apegomp said at
I just made a new video in order to (hopefully) explain the idea better: http://youtube.com/watch?v=CQWv8J1LzsQ Enjoy! :o :P
Actually I already programmed exactly what you described ^^ It has already been 4 years ago, but if you like you can play around with it. I doesnt generate a heightmap - it generates procedural voxel data on the fly.
My next project targets on rendering large volume data - its the other thread here http://www.jonof.id.au/forum/index.php?topic=1381.0
It renders a 40k x 40k x 1k voxel volume with dynamic lighting at 30 fps on a GF8800.
apegomp at
Spacerat said at
My next project targets on rendering large volume data - its the other thread here http://www.jonof.id.au/forum/index.php?topic=1381.0
It renders a 40k x 40k x 1k voxel volume with dynamic lighting at 30 fps on a GF8800.
Awesome ;D Overdraw mode looks much more realistic :) It's like being in a black-and-white horror movie :P and the map is infinitely large! ;D
Everything that's inside a voxel volume is easy to manipulate. Fluid physics, raycasting, newtonian physics on a small scale, everything is possible in a voxel engine ;D Bullets can ricochette off rocks and penetrate deformable voxel flesh :) More and more emphasis is being put on physics and interactivity in today's games (eg. Crysis where you can destroy trees :P). Only a voxel engine can deliver flawless physics! ;D Voxels for the win! :P
Hazard at
One basic problem of the "voxel volume shifting" idea is that you'll lose information about destroyed terrain when the area is discarded to load new data on the other side. apart from this your idea is very doable. my voxel engine (which converts the voxel volume via marching cubes to polygons) is already made up of smaller volumes (32x32x32 voxels each) to keep the processing time low when terrain is modified and needs to be recalculated. you could easily unload one row of those blocks and add a new row as you move forward. however, recalculating a full row of those blocks would be still quite slow when using MC.