It really depends on too many factors. But as an example consider Ogre. This popular 3D graphics engine has been used in numerous commercial applications and took the (exceptionally talented) lead programmer about 10 years to get to it's current state. Tha's working part time though, so perhaps 3 years is more reasonable.
Ogre is a large engine - a smaller engine such as Horde probably represents maybe one year of full time work. But in both these cases it's just the engine - if you want tools for importing assets etc this will cost you extra.
If you have more specific requirements then you can possibly get it down to months, but at this point your trading off features and possibly flexibility.
Last year I published an article in Game Engine Gems about rendering volumetric landscapes, and I recently discovered that it has been made available on Google Books. I believe it's fairly easy to read, you can have a look at it here:
If your scene and lights are static then you won't find a better solution than baked lighting. If you need moving characters or something then it's more complicated (but you can still bake some of the lighting). Try searching for 'lightmapping' for more information. The lightmap is simply a precomputed texture which contains the lighting information and which you apply to your scene.
Be aware that ESMs do have problem though - in particular when a caster is very near to a receiver. If you have a character standing on the ground then his feet can have a much fainter shadow than his body. On the plus side this immediatly solves the shadow acne problem for self shadowing objects.
All shadow mapping approaches have problems - if there was one perfect solution everyone would be using it. The best you can do is understand the limitations of the different approaches and pick the one which has the least drawbacks for your particular scenario.
Also, you still haven't said whether your lights/geometry are dynamic. If they are static then baked lighting is your best option.
Original post by Lloydg But look around there seems to be a fair bit of information on web about voxel terrain.
There is, but be aware that much of it is completly different from the approach used by myself, Crysis, and C4. During the 90's games such as Commance, Delta Force, and Outcast made use of what they called 'voxel terrain'. It was basically a regular heightmap rendered with raycasting, and has nothing in common with what I do.
Original post by Lloydg Just to understand. each voxel will only be one material type, or 2? if it is half one half air, or half dirt half rock. But it cannot have more then 2?
Or is it only 1. From what i have read it seems like only one, or its part empty. But your screen shot looks like you have half dirt half rock, or half dirt half grass.)
In my particular implementation each voxel is a single material. That is, it's a single number (0-255) where 0 is empty space and other values are solid (e.g. 1=rock, 2=earth, etc). What you see in the screenshot is a few layers of rock voxels with a few layers of earth voxels on top, and then a couple of layers of grass voxels on top of that.
Original post by Lloydg Thank you PolyVox. This is extremely helpful and looks like what I will use for my engine :) I have started reading your article on Game Engine Gems, Very good.
Great! The library is still under a lot of development but it is quite usable. It's currently C++ only though as I haven't implemented bindings to other languages.
When reading the article you'll notice that I don't use a 'density value' at each voxel, and this is what causes the 'ring' artifacts visible on the grey sphere in the screenshot above. For terrain rendering you will actually want this density value as it gives a much smoother mesh - but fortunatly I'm implementing it at the moment and should be done this weekend.
Original post by Lloydg I realize the physics will be really hard to implement, so I will properly leave it out at first, and do it at a later time. But try and keep it in mind as i code so i dont have to rewrite everything when i try to implement it ;)
Making floating islands fall away should not be too difficult (Ken Silverman handles this in his Voxlap engine) but the cave-ins will be very tricky.
This question seems to come up fairly oftern so I've half-started compiling a page of resources on voxel terrain, but I have a lot to do on it yet (PM me if you want a preview). I use the concept of voxel terrain in my own engine (here) and provide a library for integration into other engine. The concept is also used commercially by the C4 and Crysis engines. The result is something like this:
If you want to implement this yourself then I have written an article for the book Game Engine Gems and there is also an article in GPU Pro. I haven't read the GPU Pro artcile though, so I don't know how much implementation detail is there.
So, in priciple it is possible. However, I have yet to implement any physical aspects such as your cave-ins or floating rocks falling away, and in general these are going to be difficult.
It's implemented as an extension to the Ogre3D graphics rendering engine. My approach uses a volumetric representation of the world and then uses the marching cubes algorithm to generate the polygon mesh so that it can be rendered quickly.
It's in very early stages but let me know what you think :-D And if there might be a job done the road then I'm definatly interested... I believe this technology has a lot of potential. Especially when you start considering physiscs, which I believe has a lot of advantages in a voxel environment because the collision detection becomes much easier.