Demo video showing what I have so far!

https://www.youtube.com/watch?v=dFRNZXxTaTA

Very cool stuff! polyvox is a really neat library!

Edit: Does polyvox use a specific coordinate system? There seems to be a lot of differences between different libraries and file formats...

Edit2: How it the performance of the ambient occlusion calculator? I read some old forum posts that said it was inefficient.

Edit3: I just noticed that the data created by the ambient occlusion calculator gives the result in some sort of texel/3d texture format. I haven't been able to find an Irrlicht function that can directly handle this. Is there a way to convert to a texture that Irrlicht can use? Or should I just switch to Ogre or something.

Edit4: Is there a trick to get decent looking lighting? As you can see in the video from 4 seconds to 9 seconds and 17 seconds to 24 seconds, the shading on the blocks is pretty terrible. This is just a single light. It seems like just "dropping in a sun" won't work too well. Especially in caves.

Looks good!



No, PolyVox doesn't define anything here. A volume is just a 3D grid of data, and it's up to you to define which way is 'up' when you load data into it. You also need to match this up with your chosen graphics API.



I don't know if it's inefficient but it can certainly be slow. I think there probably is a lot of room for optimisation in there. We were going to use it for Voxeliens but actually it was too slow when editing the terrain.

In the future I would like to try some new approaches to faking ambient occlusion as these should be a lot faster (the calculator does real raycasting to get a physically accurate result... at least to some degree) but I haven't got to that yet.



Indeed, the idea is that you load the resulting data onto the GPU as a 3D texture and then sample it from your pixel shader when rendering. Note that this means you are quite limited for with the maximum size of the ambient occlusion texture, though it would typically be at a lower resolution than the volume data anyway.

If your engine doesn't support 3D textures then in theory you can treat it as a 2D texture atlas instead, though you wouuld need to implement your own texture interpolation between slices. Hmmm, could be complicated.

Overall I would say that we hoped to use the AO but it was too slow for us, and so it hasn't really been used much. We do intend to come back to it in the future.



Rather than having an AO calculator which builds a 3D texture you could have one which bakes the lighting directly into the vertex data. This will probably be faster and work on more hardware, and it's something we may look at in the future. However, with this approach it would be harder for voxel geometry to 'cast' occlusion onto non-voxel objects.

In terms of general lighting techniques, well I can't really help here. In theory PolyVox meshes are just regular geometry so you need to find general tutorials about lighting, shadowing, AO, GI, colour bleeding, etc.

That said, I wonder whether the new Voxel Cone Tracing is easier when applied to geometry which came from voxels in the first place...

i tested how to get cool shadows and atm i think a good solution for irrlicht is to use the xeffects from BlindSide, they work with this iscenenodes and polyvox. And additionally they are easy to use and you get blur and realistic water etc( but seems that xeffecs for irrlicht1.8 is in work, works with 1.7.2):
http://irrlicht.sourceforge.net/forum/viewtopic.php?f=6&t=30631

Some new screenshots:

With fog: http://i.imgur.com/mZyzsZO.png

Without fog: http://i.imgur.com/hhr4OJ0.png

Currently I can show the entire map at a pretty crappy frame rate. Hopefully the frame rate will improve drastically once I implement chunks...

Also the maps that I'm working have an upper limit of about 500,000 surface voxels (note that the number of faces will be less). I'm hoping that the ambient occlusion calculator will be fast enough to do a per-vertex calculation.

How many rays should I shoot out from each vertex? I'm guessing that you need a minimum of 3. Will 5 be enough?

As for the location of the rays, this is my plan for the location to shoot the rays from each face.

http://i.imgur.com/07OeoXA.png

The circles indicate where the rays will shoot out of.

Do you have any screenshots? For some reason Irrlicht's SMesh won't cast shadows on itself.

I was looking at http://codeflow.org/entries/2010/dec/09/minecraft-like-rendering-experiments-in-opengl-4/ and it seems like everything he implemented is baked directly into the vertices. I haven't really been able to find a resource on how to implement "spherical harmonics" however. Ideally, I want to stay compatible with older hardware.

Edit: one benefit (maybe) of the fact that the SMesh doesn't cast its own shadows is that cave areas remain lit just as if they were outside... you might as well bake everything into the vertices though...

I like your second data set, did you import it from Minecraft or something?

Anyway, I think it is worth investigaing a new ambient occlusion calculator which can bake lighting into the vertex data, and it's something we will probably have to look into for Cubiquity as well. But there are some potential problems. The most important is that if you bake AO into vertices then it will limit or remove your ability to perform mesh simplification on the cubic mesh. It will not be possible to merge vertices if they have different AO values and this will happen a lot. I only skimmed over the OpenGL 4 Minecraft rendering article but I don't think he addresses this?

You should also think whether the per-vertex AO values should correspond to the position of that vertex is space or to the voxel which generated it. I think the first approach will be easier.

If you want to persue this you should probably first write a function which can compute an AO value for any point inside a volume. You will need to cast quite a number of rays (tens or even hundreds... I'm not sure exactly). Then you can generate a mesh with simplification turned off, and pass the position of each vertex to your new functions and then store the result back into the vertex data.

That's the idea... but I'm probably missing some things and there will definitely be some research involved here



I don't know anything about Irrlicht but in general self-shadowing is a tricky problem, so maybe it is not supported.

@dynasty, the pics look nice you are on a good way

the irrlicht-standard-stencilshadow you know from irrlicht-specialfx-tutorial only works with scene::IAnimatedMeshSceneNode atm. But anyway, like i already told the xeffects work and look better than the stencilshadows, heres a pic (a red moon rises and sends a red spotlight on a polyvoxsphereinvolume floating above a plane and casting perfect realtime shadows on the sphere and the shadow of the sphere to the plane, blur/bloom are also activated,polyvox 0.2, irrlicht 1.7.2, xeffects 1.3):

That picture looks pretty good. I'll see if I can integrate AO first before I try out the shadow stuff. I'll start a new thread once I have something.

Crazy idea of the day: AO is baked directly into the map files. Since my game will be completely multiplayer, whenever a change in the map is made, the clients will send in what they computed for AO. This way, any new players joining will instantly have AO, at the expense of bandwidth. Then the only bottleneck is seeing if AO can be updated in real time when changes are made to the map.

Also, the maps that I'm using are in the Ace of Spades .VXL format. There are a ton of good .VXL maps out there. The file specs are here: http://silverspaceship.com/aosmap/aos_file_format.html. Note that I was told there is a bug in the sample C++ code on the page, so you probably shouldn't use that. I can post my loading code if you want (although you should probably try to understand the file format yourself. It is not a tricky format by any means).

Edit: also most of the AoS maps that I've seen don't have many large areas of uniform color.

Also here are some download links for VXL files:
https://code.google.com/p/pysnip/source/browse/feature_server/maps/?r=49a04f1d7c0560fa36d30afcce7a4ef2f9d60dad
http://aos.minit.nu/maps/

Very interesting, thanks for those AoS maps. I'm definitely tempted to try importing some into Cubiquity to play around with. But at 512x512x64 the maps are smaller than I imagined, and I think you could render such maps on a modern GPU witout worrying too much about the simplification (which would then let you bake the AO).



Be careful here - in order to compute the AO colours you need the original colours and the amount of occlusion. So you can load the map from disk, compute the AO factors, and then multiply them by the original colours and bake the results back into the map. But when the map is modified you need to recompute the AO, but you no longer have the original colours available as you replaced them with (now invalid) baked AO values.



Sure, I'd be interested to see your loading code. I've been thinking recently about creating some kind of repository of volume data to be used by voxel researchers. It's still a little way off but a couple of AoS maps would make nice game-related additions (I'm also thinking of having fractals, converted meshes, etc).

Unfortunately there isn't really a central repository for AoS maps. A few people have tried to make some, but they always end up abandoning the project partway or don't really have the programming skills to pull it off.

Here is my loading code:



Here is a link to an isometric .VXL renderer that I wrote in javascript/canvas a while ago: https://www.box.com/s/0b9e408228a433fd5c7b

Edit: aloha probably has the most complete AoS repository: http://aloha.pk/files/aos/maps/

If you can't get it to work in one browser, try another. Firefox seems to work for me.