11–20 of 86 posts
Earlier quoted context omitted.
This is beautiful stuff. Are you looking for contributors? I'd love to work on this with you.
Agreed, the visuals are just fantastic. Kind of clashes with my memories of the last Voxel game I played, one of these terribad Delta Force games.
Earlier quoted context omitted.
Why is it isometric when you are using voxels? I see the lighting is accurate, so why the limitation?
It is a style choice mostly. :) I am fan of old isometric games like Ultima (which was really diametric), and Fallout. Also, simplest to store tilesets when there is no perspective projection - this means they can be rendered once to a larger bitmap for better performance, and that can be scrolled around on its own (versus redrawing thousands of chunks every frame)
What makes voxels better or worse than polygons for this kind of game and art style?
With voxels, positions are inherently stored, and guaranteed to have some cache locality if they are uncompressed. Thus, GPUs are really good a chugging through large amounts of bitmaps, which is what I am doing (only rendering to bitmaps). With teraflops of compute power now, you can do trillions of flops every second, and in my case I can render about 1-2 billion voxels per second.
Additionally, doing procedural generation with polygonal surfaces is much more complex (I've done it, I know). Implementing stuff like voronoi patterns (used for the rocks) is trivial with voxels. Not the case with polygons, unless you are just wrapping voxelized data. Its the difference between evaluating a graph at every point, and calculating the graph at only the needed points. Voxels are implicit, polygons are explicit.
Really, you can think of VQ like a really fancy graphing calculator (in fact, all of the structures are just an extension of superellipsoids) (http://en.wikipedia.org/wiki/Superellipsoid)
Earlier quoted context omitted.
It is a style choice mostly. :) I am fan of old isometric games like Ultima (which was really diametric), and Fallout. Also, simplest to store tilesets when there is no perspective projection - this means they can be rendered once to a larger bitmap for better performance, and that can be scrolled around on its own (versus redrawing thousands of chunks every frame)
Got it. So you couldn't do a view where you could see the horizon or anything due to the performance fixes. The scrolling wouldn't quite work out. It's interesting, I never thought to do it that way. I suppose you could do like spherical deformation postprocessing if you wanted to make this like tiny planets, but then the problem is that the sides wouldn't correctly show perspective. Anyway, it looks great.
So, assuming that's what's happening, why not pre-render/pre-generate a larger area than the visible area so that this faulting in process isn't as visible for a typical viewport pan.
Also, if you were to reduce the resolution, would that make the faulting/rendering faster? Seems like that would be a good compromise, as many of the demos now feel like the terrain isn't generated fast enough to make a playable game.
Oh, can you also demo destructibility in a future video?
Are you going to be releasing the engine and a game? Or just one? I may have missed that. But it looks truly amazing.
Both - initially the engine source will be put out to help boost the community and mods around the game - a game is being built so that relevant features are added to the engine. Kind of dogfooding my own engine I guess. :)
When I view your videos, all I can think is "oooh, he's using some kind of page-fault type engine to pull in and dynamically generate cubical subdivisions of space" So, assuming that's what's happening, why not pre-render/pre-generate a larger area than the visible area so that this faulting in process isn't as visible for a typical viewport pan. Also, if you were to reduce the resolution, would that make the faultin…
You can make it go a lot faster by lowering the resolution, as I point out a bit down the page in the article. Every reduction of 2 in resolution ups performance and memory usage by 4-8 times, based on if the process is 2D (post process) or 3D related (chunk rendering). I'm continuing to add more optimizations to make things faster as I go along.
I am also going to add in better support for caching and prerendering - right now it all happens exclusively in GPU memory - I can easily expand the view even further with system memory and hard disk usage.
Are you going to be releasing the engine and a game? Or just one? I may have missed that. But it looks truly amazing.
Both - initially the engine source will be put out to help boost the community and mods around the game - a game is being built so that relevant features are added to the engine. Kind of dogfooding my own engine I guess. :)