Perhaps this illustrates the problem better?

The spots where the normal/faces are missing are backfaces created by picking from the opposite direction.

That is they are created when picking a voxel (density 0) then connecting sections of voxels. it seems like it's creating new meshes for every disconnected set of empty voxels.

also I was unable to find the examples you're describing in git. The only picking example I've found was only visible with an older development version of the repo. In the python example.

I've tested this enough to know the problem is in the normals/indices. But I've even added code to clear the vectors out. So it's not on my end, it's what polyvox is sending and/or how irrlicht renders that information.

The only thing I can think is that polyvox doesn't calculate the normals after a change in voxel density, which is what you mean by saying I must calculate them myself. Is this correct?

I've now got to tear apart polyvox to understand exactly what it's doing. But I won't be fixing it, I'll write my own voxel engine to handle my meager needs atm. The voxel engine doesn't seem all that complex at first glance.

So once you send your vertex/indices to the fragment shader are you then calculating normals for faces? I'm very confused about how this is meant to work now. I was thinking that indices were the normals I guess. but on second thought I realise that's normals.

My one solution for figuring out the normals would be to have each voxel (using volData) which is just a cubic volume. To test each voxel for neighbors and compute the correct faces that way. But it seems like that'd be slow or wrong somehow. And words on that perhaps?

You can see the picking test here. But it's not visual and doesn't modify the volume - it just checks where the ray hits:
https://bitbucket.org/volumesoffun/poly ... at=develop



Perhaps we can completely take rendering out of the equation? For example, what if you generate a sphere, extract the mesh, and print the number of vertices. Then modify a voxel (perhaps without picking), extract the mesh again, and print the number of vertices again. Has this changed as expected?



I mean that meshes generated by the CubiSurfaceExtractor do not contain valid normals, ever (though we might add something in the future). Therefore, the latest version of the BasicExample uses GLSL shader code to compute them on the GPU. Here you can see some GLSL code embedded in the .cpp file: https://bitbucket.org/volumesoffun/poly ... elop#cl-76



To be honest this might be worthwhile. PolyVox assumes an advanced knowledge of voxel engines and shader programming, and at the moment you seem to be going in circles a bit. Writing a basic engine first might help you better understand some of the underlying concepts.



If you are writing you own voxel engine then you can do something like this. Most voxel engines probably take a similar approach. PolyVox does not, because we have explicitly decided we do not want normals in our cubic mesh vertex data. We do this to save space, and because they can be computed in GLSL code.

Actually you may be able to do a different but related experiment. Your main concern is that when you delete voxel data and re-extract the mesh you are still seeing the old data existing (right?). Now, on the previous page you showed this:



So, we know you can write to the volume data, extract the mesh, and render it. What if you now iterate over all the voxels again and set the top half to be empty (in response to pressing spacebar or something). Extract the mesh again and render it. Do you see the top half disappear? If you print out the size of the vertex list then is it only half as long? This kind of test should help you narrow down the problem, and note how it doesn't rely on the picking (we can come to that once rendering and updating is working).

For debugging purposes you probably should have two-sided rendering on, so that you see polygons even if they are facing away from you.

Also, have to read the description of how polygons are generated in the CubicSurfaceExtractor? It a little out of date perhaps but the principle still applies, and it explains how the edges of regions are often not extracted (under 'Working with Regions'). See here: http://www.volumesoffun.com/polyvox/doc ... actor.html

Turning backfaces on would make this even more confusing. They are off for debugging atm if that makes sense. I'm not confused by this.

I have read the information yes, I'm pretty sure I've read what you're describing.

I wrote something else at first, but it sort of helped me understand some of the problem.
I'll explain, The volume data is the only thing being reused. When I render the above picture it's making the voxels as large as the volume and only 60 high where the volume is 64 cubed.

When I initially render it that way it works fine, I haven't tried adding a height field aspect to this besides picking. Maybe the problem isn't irrlicht, perhaps it's the volume data that isn't fixing. I have rendered flat surfaces with empty volume data like the top of the volume cube.

I'll test some more like you suggested just to be sure the picking isn't the problem. but the picking works fine now that I can see wiremesh. All it does is set a voxel density to 0. a button and coordinate will undoubtedly have the same effects.

Am I supposed to be using a volume resampler?

Exactly how is this supposed to work?

1. create volume
2. extract volume
3. get vertex/index data and send to graphics engine
4. create a mesh using that data in gfx engine
5. set empty voxels
6. repeat step 2-4

Am I missing steps here? Should I be resampling the volume before extraction or what?

[update]
I've tried using spacebar to remove a voxel, same thing. Also tried picking some empty voxels above the 30 block floor I've made, doesn't work at all, but that's because the picker only works on non-zero density voxels.

[another update]
I'm displaying index/vertex counts. It's being called twice. Why on earth would my function run twice??

ok so what I'm learning is that the volume data isn't calculating correctly.

It's not because the function is very strangely running twice. If anything that would help since it clears the buffers and everything several times. highly unlikely.

it's the volume data. either I'm using the wrong type of volume, not doing this correctly, or it's not updating the volume data properly after changing densities.

So are you telling me that the way you've done this works? I doubt that. I imagine in your code you're reiterating the volume each time, or at least a region of the volume.

I understand code and all the concepts involved that have been explained. But you haven't talked about what you know isn't working or the proper way to do this at all. I'm not stupid, I know the concepts here.

the only way I know this will work is to recreate the volume. it knows which voxels are zero density and I can build a new volume from that. but that's definately not how this should work. AFAIC picking isn't high level. it should be built into the engine or your engine doesn't amount to much more than a very complex stl vector.

I've learned that Irrlicht does have some limited shader support and I'm going to look into that. The new code you're writing for the surface extractor doesn't even return a mesh so I don't see how one could even construct a mesh from that anymore. I must be missing something there. It seems like you're forcing everyone to use openGL shaders to compute the faces/normals. which you can't get from the extractor....SIGH

the code isn't user friendly or intuitive at all, and you guys have done very little in terms of documenting this thing. I mean where is "how to use this" even written??

I don't understand your method of programming. It seems like there should be functions.

like this.

createVolume()
extractMesh()

not 300 lines of code just to get what the engine is supposed to be doing for me.

I'm a little agitated from this right now but I believe I'm making valid points here. Please don't take this the wrong way.

Now I want to smack myself in the face.

You said "iterate the voxels".

And then I clicked your other link, about the "picking test" and I'm looking at the code and it dawns on me.. you're iterating the voldata and creating a new one.

Total Vertices before picking 15876
Total Indices bp 23814

pick?add? a block

Total 15892
Total 23838

Difference it V +16 I +24

And it prints twice... what in the ..... I mean really?

At this point the code is all moved around into different functions. I've changed convert to a buffer rather than mesh. nothing is working, so now I'll mess with the volume data. but if I were to do that by region I'd end up with even more strange mesh problems.

It looks to me the test simply creates a SimpleVolume, and sets for each voxel the density to 0 or 100, where 100 is solid and 0 is empty/air. The volume is created once and filled once. No "new volume" is created. Or have I misunderstood your message?


So it prints twice, 16 vertices are added, and 24 indices are added. Seems like two voxels are added, as drawing a full cube requires 8 vertices and 12 indices. How are you picking the block? Buffered/unbuffered input? Maybe it picks a block as long as the key is pressed for each frame.

I'm sorry for you on-going frustration here. There are indeed some issues surrounding PolyVox such as the lack of (or outdated) documentation, seemingly strange design decisions, or incoming changes which break existing code. But you have to remember that it is primarily being used by us as a basis for Cubiquity and so some of these other tasks take lower priority because we already know how it works.

It is currently undergoing a significant overhaul (see the 'incoming changes' thread), but this only started a couple of weeks ago and you can expect more disruption in the coming weeks. I do think it will get easier and more robust to use but it's never going to be a drop-in voxel solution - it's just a container for volume data and set of algorithms which can be used for processing such data.

But fundamentally it does work. Regarding your problem with extracting a mesh, modifying the data, and then extracting the mesh again, the followng code (a modified BasicExample) works as expected:



There is only one volume here. We create it, write some data into it (the sphere), and then extract the mesh. Then we write some more data (setting half the voxels to zero) and extract again.

The output is:


You can see that after setting half the volume to empty there are roughly half as many vertices, and if I now draw the mesh I do see half a sphere. You already have the sphere working, so perhaps you can try dropping in the above code?



No, you have no use for the VolumeResampler (also ignore the SmoothLOD example for now, just look at BasicExample).

Perhaps.

So I gave up on this last night and was programming my engine/framework and ran into a little bug involving an if statement and a return... very dumb on my part but things like that do happen.

And the nature of this bug got me thinking about how it's printing vertex info twice. to make a long story short I'll squash that bug as soon as possible.

So yeah like I said before.. extraction works fine on a new volume, or on an existing one.. the problem isn't that but the volData not updating the correct vertex.

I made an attempt to use newer source for this, but I think that smashes my covert function to little bits. so, I'll continue testing with this and see if I can match your results.

Total Vertices before picking 15876
Total Indices bp 23814

and after

vertex 15624
index 23436

diff

v 252
I 378

I think what's happening is a problem with my function (or whoever originally wrote it).

I assume having a meshbuffer function that takes a surfacemesh as argument is causing a duplication somewhere. It's consistent with the problems where a single call to number of vertex displays twice. is that because "meshpoly" is both a buffer and surfacemesh? Probably.

It'd also duplicate the mesh that way I'd imagine. This is what I'm going with at the moment.

So I'm attempting to decouple the function. Find a different way to convert the surface mesh into a mesh buffer. for now the syntax eludes me.