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 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?
There is some destructibility in this video, but I'll go over it more in the future. :)
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.
At the risk of having you compete with a project I would not even start, ;) you should dynamically reduce the resolution so that it runs in WebGL and create a backend in Akka or Erlang. You could get real funding with what you have here.
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?