Hello!

After some messing around with the sourcecode (And with a lot with directX *sigh*), I was able to get some little sample application running. I think your interface is quite nice, and easy to use (Except using std::vector/smart_ptrs/... everywhere, I'm a raw guy ). Here is how it looks like now:


It's just a tiny sine wave, but that turned up some questions:

- It's pretty slow in debug mode. Can I turn on the optimization, just for PolyVox somehow (Using MSVC++ 2010 express)?

- How can I modify it in realtime? Is there another way as getting always the whole mesh, because I don't know which vertices were there before. I would like to have a painting mode for the terrain in my engine.

- How do I do that awesome UV map creation? (There was nothing about this in the ogl sample)

Thats all for now (There comes more, seriously!!) And also I have some feature suggestions for you, but first of all, I would like to get the basic stuff running.

EDIT: Ahh... I forgot one: How can I make this thing smoother?

Wow, I'm impressed you got that up and running so fast! I'm also glad because it means the interface isn't too complicated (although there is still stuff I want to improve).



Agreed, debug is really slow. I haven't checked why, but one possibility is the large number of 'assert()' tests. You could do a search and comment them out to see if it makes a difference, but then you lose the extra saftey they provide...

I don't think there's an easy way to just turn on optimisation for PolyVox. Many of the classes (such as the Volume class) only exist in header files, and so they are compiled with the same release/debug settings as the rest of your application.

Probably best just to use smaller volumes for debugging purposes



The trick is not to generate a single mesh for the whole volume. Instead, you should divide the volume into regions and have a seperate mesh for each region. Because you will usually only change a small part of the volume at a time (for example, if an explosion destroys part of it) you only need to regenerate the meshes for the regions which have changed.

For example, if you have a volume which is 256x256x256 voxels then you could have regions which are 32x32x32, and you would need 8x8x8=512 of them. Some might be empty of course, so no need to generate meshes for those. This is also better for the GPU because it lets you cull away the regions which are not currently visible to the camera.

PolyVox has a 'Region' class, and you can pass one of these to the extractSurfaceForRegion() function to control which part of the mesh you wish to extract the surface for. Apart from that, it is basically up to your application to decide when to regenerate the meshes. In the example above, you could use the Array class to create an 8x8x8 array of flags which would indicate whether the mesh is currently up to date. When you modify a voxel you could set the flag for the corresponding region, and when you regenerate the mesh you could then clear that flag. Also you can look at the VolumeChangeTracker for a class which handles some of this for you, but I think this class might need some work on the interface.

Of course, this is all dependant on you just modyfying part of the volume at a time (which is what Thermite allows). If you wanted to modify the whole volume at once (e.g. to animate your sine wave) then you can't really do that.



This is actually handled by Thermite as PolyVox doesn't deal with UV coordinates at all. In general, there is not good way to properly wrap a 2D texture around a voxel object. Instead Thermite uses an approach called 'triplanar texturing', which basically projects the texture along each of the three main axes and then blends between them according to the normal (and PolyVox does give you the normal).

For more information I would recommend reading this article: http://http.developer.nvidia.com/GPUGem ... _ch01.html

Hope that helps, do let me know if you have any more questions

Thank you for the answer!

I've got one more question:

In my picture, you can see that the sine wave has some ugly stairs. Can I smooth them out somehow? Maybe there is something like a bias, to force the polygons to wrap around the voxels not that closely? Or do I have to smooth the generated polygons myself? (No problem, but it's still work )

I was expecting you to ask this question at some point At the moment the mesh generated by the surface extractor will always have those kind of staircase artefacts. As you are aware, there are various mesh smoothing algorithms available which can be used to smooth the generated mesh. For example, I have already written some code as SurfaceMesh::smoothPositions() so you should have a look at that. It's what I have used so far.

But a problem occurs when you break the volume down into regions as suggested previously. When you smooth each of these regions individually you will find that cracks appear between the regions. So basically I need to improve the smoothing algorithm.

The highest quality and most flexible option will be to extend the data stored for each voxel so that it is not just a material ID, but also a density value. This would basically mean that each voxel is no longer just a binary on/off value but is instead continuous. Actually, this capability has already been added to a very old fork of PolyVox by the Forever War project.

In the short term you should use the mesh smoothing algorithm or implement something similar yourself. I can improve it and fix the cracks at some point over the next few weeks as I don't mind prioritising features that people want to use. Longer term I'll probably implement the density values but that might not be for a while.

Hello again!

I am implementing PolyVox into my Engine at the moment, and I have one important question. I also need to be sure, so that I don't get bugs later.

Which size has the generated mesh? Is it, as I think, at the same size as the volume it was extracted from? I need to bring it into 0..1 space, so does this the job?


VoxelVolumeSizeX, Y and Z are all 32 (Resolution of the volume)

I get wired results, and if this is right, another thing must be wrong...

Never mind, I fixed it.
Here is a shot of the current progress: (Some cube art )


Looks a bit strange, but hey, it works

EDIT: I encountered a strange thing: When I smooth the mesh with your function, my selector only works with triangles very near to the pivot. Does the smooth function change something at the vertex positions, except smoothing them?

Great, I'm glad you got it working. I don't have the source code in front of me, but as I recall an extracted mesh will always start at (0,0,0) and finish at the size of the region. For example, if the minimum of the region is (128, 128, 128) and the maximum is (192,192,192), then the extracted mesh will go from (0,0,0) to (64,64,64). There might also be a scaling factor of two somewhere but I think I took this out.

The remaining offset is stored somewhere in the SurfaceMsh I think (in the exampl above this would be (128, 128, 128). The reason it is done this way is I imagined the SurfaceMesh data would be placed into a node in a scenegraph, and that the offset would be used as the node's translation. I might think about this again though, maybe it is just confusing.



I'm sorry, I don't know what you mean by the 'pivot'... I'm guessing you mean the origin (0,0,0)? I don't think the smoothing function changes anything else but I'll have to check the code later on.

Anyway, I'm curious about where you got your data from? It looks funky Is it procedurally generated?

Hi!

It didn't took me very long to get there. Your library isn't very hard to understand. Fill a volume, extract a mesh, give the vertices/etc to DX and render everything. Just one thing I noticed:

The Volume::setVoxel (Or so, can't see my code yet) function could check, if the Voxels location is smaller than 0 or bigger than the volume size. Otherwise it crashes. And it is very uncomfortable to write that code, just every time I want to place a Voxel. It's just a small suggestion.



For now I was extracting the data just from 0,0,0 to X,X,X. So they always where at the origin (Or pivot <- I read this somewhere). Would be great if you could look that thing with the scaling up



Yes, I'd like to handle this myself. The origin with the editor-widget would be somewhere else then, and this is not good. Whats with a bool-property in the extract-function? You could set the standard to what it was before, and no old code would break.



The only thing I know, is that it makes my intersect-function working wrong. The more I smooth, the smaller the region I can select gets. Is there any function (Except the sumNormals function) that simply recalculates the normals? This could might help. Otherwise, what code do you use to intersect your meshes? When it works fine there, could you give it to me?



Its a 64^3 volume with a start plane at the bottom of it. I implemented a function which makes a cube pop up where you clicked. I just had some fun!

Yes, I think I can handle that either by modifying the function or with a new 'setVoxelSafe()' function which will just do nothing if the value is out of range.



Maybe... actually I'm not too worried about backwards compatibility. As far as I know only you and I are currently using the library. I'd rather make sure I get the interface right At any rate I will look at this.




Ok, I looked at the code and I don't think anything bad is happening in smoothPositions(). The thing is, if the resulting mesh was incorrect in some way then you should see it in the rendering. But if I understand you correctly then the rendering is actualy fine? Is it possible you are using the unsmoothed mesh for intersect testing, and then the smoothed one for rendering? Something like that?



Yes, there are two things:

1) 'generateAveragedFaceNormals()' will generate normals for each vertex by computing a normal for each face and then averaging these together to generate a normal for the vertex.

2) 'computeNormalsForVertices()' will conpute normals directly from the volume data. This ensures that neighbouring regions will have matching normals.



Actually I don't have any mesh intersection code. Instead, I perform intersection tests directly against the volume. When the mouse is clicked I set up a ray (with a position and direction - you probably have this already) and then move along the ray a little bit at a time. For each position along the ray I call Volume::getVoxelAt() to determine whether I have hit anything. Let me know of that is not clear.

I'm not going to get a chance to work on PolyVox for the next week, but after that I'll address some of these issues.

I found the first one before, and with this it seemed to work (Where is number 2?). I don't think that the problem lays at the smoothing anymore, but at "my" stupid intersector.
Well, when I ported my engine from DX10 to DX11, the useful intersect-function of D3DX10 was gone (Microsoft, damn!) and I wanted to get everything running again. So I just copied it out of a SDK sample. And what can I say? That function is *really* stupid. I could have wrote the code myself, so often I needed to change something on it. It is only a piece of ... . And I really need to change it. My artist complaint about this, too. When you are inside something, it doesn't selects anything. I'll implement the voxel.method for the terrain. Everything should be better than that what I currently have.


I'm going to set up a newspage at ModDB (http://www.moddb.com/engines/wtech) about the new PolyVox terrain soon. Maybe I need some deeper information about PolyVox then. And, since I want to add the DX11 port to it (Wohoo new DX! <- Gamers will say) I expect a high click-count. Would be a nice advertising for PolyVox, I think