Yep, it's a little strange. I don't remember why it was like that - most likely I was just being cautious about the ray accidentally going out of the volume. However, I have now implemented your earlier request for the getVoxelAt() function to automatically check the bounds. By default it returns zero if the position is outside the volume.

This means you can actually get rid of the snippet of code which you quoted above. The relevant part of my intersection function is now:



If you want to use this instead then you will need the latest version of PolyVox which has the bounds check. You can get it from SVN (http://sourceforge.net/projects/thermite/develop) or I can make you a zip file. The zip file will have to wait until the weekend though as I want to get some other stuff in.

I working on better smoothing at the moment - I figure you'll need this if you are using PolyVox for the terrain. Rather than smoothing the mesh after it has been generated I am instead blurring the volume data to give it a softer edge. This is done on-the-fly so it should be transparent to your application. I'll let you know how it works out...

Hi! I'm sorry about the very late reply, but I had problem with my Internet Connection.



That is nice, thank you!



Another Zip would be great. So, it's weekend today, would you like to send my an EMail with it attached or so?



Could you make a option whether to smooth it or not? And a function that smoothes a region, so the Artist can decide where to smooth, and where not. Although, a bit of smoothing everywhere is nice, too

I got pretty far with PolyVox in the days I had no Internet (And no school ) here is some progress:



Luckily I had downloaded the GPUGems article about Triplanar texturing (Even if I had some problems with the Cg code) but as you see I got it working. I also implemented the red box which fills a region of voxels.
And last but not least (The most important) I made the Terrain-Editor's toolbar, which pops up when you select the terrain. Maybe you have some ideas for the editor, too? Please let my know about them, if you have some.

[EDIT]: I changed the thread title

Wow, that image is really cool You've got a nice editor coming along there and actually it looks pretty smooth already.

Ok, I've actually had a bit of a change of direction. I had implemented smoothing the mesh by averaging the volume and it does work, but as I was doing these changes it was becoming clear to me that a lot of issues would be solved if I had a 'density' value as well as a 'material' value. When I first wrote PolyVox/Thermite I was more interested in representing buildings rather than terrain so I didn't both with the density aspect, but I think the time has come to change that (for Thermite as well as [W]Tech).

Anyway, I have started making these changes and so far it is going quite well. I can already see the results in the PolyVox demo application. It has involved some significant changes though and is making me think carefully about the design. I haven't yet ported Thermite to the new version of PolyVox (I will have to convert my saved volumes).

I'm going to need a few more days (maybe a week) to get this all working properly, and you might not want to use it straight away as it will involve some changes to your code. It will be worth it though as it will be much better for terrain.

Tomorrow I can still give you the zip with the bounds checking in, and I guess you ned to think about whether you will make your next tech demo with the current version of PolyVox or whether you will wait for the density values...

So, one voxel can be bigger than another voxel? Or I'm wrong, but anyways, when it looks nice it is good. I havn't thought about using PolyVox for buildings though, but as [w]tech (Small w and t )grows I guess I'll implement that, too.



Would you might take a snapshot of it for me, just that I can see the result as it is now? I don't understand the density approach so maybe this will explain it to me a bit more.


I forgot to ask that: How do I save a volume to a file, or better to memory. I need to store it (And the generated poly-mesh, no problem here) into one of my packages.



Take the time you need. It is better to be slower and to think about what you write than writing just a few lines of bad code.



Yes, that would be nice. I don't think about the next tech demo now, we don't make them in a such small rate (The last one was released a week ago?). I will
wait for the newer version

The density approach is actually a little complicated to understand. As you know, PolyVox currently stores a single value between 0-255 which represents the material of the voxel. A value of 0 means it is empty, and any other value means it is solid (the actual value is used to choose the texture). These are the only two options - a voxel is solid or it is empty. When I generate the mesh it is positioned exactly halfway between an empty voxel and a solid one.

In my new approach I store a seperate 'density' for each voxel, as well as the material. The density is also a number between 0-255. It is kind of like having a grey scale image rather than a black-and-white image. The picture below illustrates in 2D.





Perhaps you can imagine that it is easier to generate a smooth outline from the second image?

So in the new system, the density value controls the shape of the surface, while the material value will still control what texture is applied. It is backwards compatible with the old system (not in code, but in terms of capability) because you still have the option of only using two densities (for on and off) if you prefer.



Well, there is some code in Serialisation.h/.cpp, but I haven't really made the format final. Of course, it is quite easy to write your own format because you can access all the voxels through Volume::getVoxelAt().



Yeah, sorry, I just got that impression from one of your earlier posts. But looking back I was just confused.

Ok, I uploaded the version of the code with bounds checking here: http://www.thermite3d.org/temp/PolyVox-Rev1105.zip

Ok, just a heads up that I have commited the first version of the code which supports density values as well as material values for voxels. It is still rough around the edges but seems to work in principle. You do not have to use the density values as it is mostly backwards compatable with the old system, so you should be able to adopt it a bit at a time. However, you will need to make some changes to your souce code and some files have been added/removed so allow a couple of hours for switching over.

Of course, I realise you are probably busy on other parts of your engine so there is no rush to try this. But I just wanted to let you know it is now available. Let me know wen you want it and I can make a zip file for you again.

Oh, and you asked whether I had any ideas for your editor. For my editor (when I write it...) I am planning to have seperate modes for 'geometry editing' vs 'material editing'. Geometry editing mode would be used to actually add or remove voxels whereas material editing mode would just change the value of any existing voxels. Does that make sense?

Cool! I'll just finish the viewports and an issue with the Terrain-Editor-Window today, then I can do more with PolyVox. I have done some heavy changes to the engine, and this took a bit longer than I thought. There are still some problems with the TerrainED-Window. It takes the focus and every keyboard-input causes a *bling* sound from windows. However it still works. Also the mousewheel isn't working. I hope you understand that this must be fixed before.

I hope I finish that soon, working with PolyVox is fun!



Yes, that makes much sense. I plan to make 3 modes in my Editor:
- Normal Voxel placing
- Modifying of the material of the existing voxels (Material!=0)
- Modifying of the material of the voxels which lay on top (Like painting grass on earth)

Also there will be a smoothing brush which smoothes parts the volume.

I will post again here when I'm ready for the Zip

Killed every bug, I am ready for the Zip!

Ok, I have uploaded the zip as http://www.thermite3d.org/temp/PolyVox-Rev1109.zip

There's quite a few changes - some files have been added, some have been removed, and some have switched between being *.cpp and *.inl. Be sure to back up your existing work (and copy of PolyVox) first!

The first task is going to be to restore your existing functionality while using the new version of PolyVox. The main difference is that the old version of PolyVox used uint8_t as the voxel type, and so you would create a volume as Volume<uint8_t>. In the new version of PolyVox you should use the new MaterialDensityPair44 as a voxel types, so you should declare your volumes as Volume<MaterialDensityPair44>. The OpenGL example has bee updated to show this.

In the old version of PolyVox, the uint8_t represented the material of the voxel. The new class has seperate material and density members and allocates 4 bits for each. This means that both your material and your density have a maximum value of 15. You can still set the material to 0 for empty space and 1-15 for any other voxel type, but you must set the density value as well. In order to maintain the previous behaviour, you should set the density to 0 (for empty space) when you set the material to 0, and you should set it to 15 (for completly solid) when you set the material to any other value.

Ok, I suggest you just go and play with it, and come back and ask me if you have any questions. Once you have restored your previous behaviour we can then worry about the smoothing part