PolyVox::LargeVolume

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

kklouzal wrote:

Also for whatever reason if I fill the density of a voxel to 255, I cout the density before it goes in, then I get the density of the same voxel it's magically 15.

The MaterialDensityPair44 type only uses 4 bits to store the material and the density, so the maximum values are 15. If you need more range you can try the MaterialDensityPair88 type instead.

kklouzal wrote:

...
Why does this error occur?

I'm not exactly sure but I must admit I have seen some issues here before. There is a warning printed saying "The last accessed block is being erased from the uncompressed cache", and I'm not sure if maybe this should be an error (i.e. perhaps it would catch the problem earlier). This is where the most recent changes in PolyVox have been made so there could be a bug here.

I assume you code snippet is from some kind of custom Pager implementation which stores data to and from a network location? If so I would recommend that you take a look at the FilePager that comes with PolyVox, and notice how it does not iterate over the voxels but instead just loads/saves the compressed data as a single binary blob. It's probably a better approach anyway, and might bypass your problem.

ker · **Posted:** Sat Oct 19, 2013 4:47 pm

David Williams wrote:

kklouzal wrote:

Also for whatever reason if I fill the density of a voxel to 255, I cout the density before it goes in, then I get the density of the same voxel it's magically 15.

The MaterialDensityPair44 type only uses 4 bits to store the material and the density, so the maximum values are 15. If you need more range you can try the MaterialDensityPair88 type instead.

wouldn't it make some sense to add an assertion that prevents invalid densities/materials to be set?
this can easily be removed at compile time by disabling assertions.

kklouzal · **Posted:** Sat Oct 19, 2013 7:55 pm

I'll just tone everything down to use a maximum of 15 and see how it looks, it really shouldn't be a problem, although 9 times out of 10 my program crashes because of this bug, it's nothing to do with my code as far as I can tell, I can run the same version of the program over and over again, it works sometimes, more often than not though it doesn't. :/

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

ker wrote:

wouldn't it make some sense to add an assertion that prevents invalid densities/materials to be set?
this can easily be removed at compile time by disabling assertions.

Yep, done. I'll probably switch it to an exception in the future (I'm trying to move to a model of keeping asserts for bugs in PolyVox, and using exceptions for user errors) but I still want to wrap the exceptions in a set of macros so that they can be compiled out if desired.

kklouzal wrote:

I'll just tone everything down to use a maximum of 15 and see how it looks, it really shouldn't be a problem, although 9 times out of 10 my program crashes because of this bug...

Just to be clear, I don't believe this is the cause of the crash. Please see my previous post about looking at the way FilePager works (by saving the raw data, rather than by iterating over the voxels). We should fix it properly of course, but the approach used in FilePager is probably better anyway and might avoid your issue.

kklouzal · **Posted:** Sun Oct 20, 2013 7:42 am

I had a look see in there and see how you are writing to the file the data from pBlockData.

I have two large volumes, one on the server and one on the client, the server sends chunks of voxels to the client as they are needed, the server works fine so far in this respect.

I just don't see how I could do it any other way aside from constructing pBlockData myself on the client, that being said I can't see a way around iterating over every voxel in the chunk the client needs.

My client works when this bug doesn't pop up, it's quite annoying but I can deal with it until you release a formal fix :]
Which I hope is sooner than later T_T*

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

kklouzal wrote:

I just don't see how I could do it any other way aside from constructing pBlockData myself on the client, that being said I can't see a way around iterating over every voxel in the chunk the client needs.

You might also look at PerlinNoisePager in PagingExample. Note how it creates a temporary block (you'll want to change the size), fills it with data, and then calls the compressor directly (you probably want the MinizCompressor rather than the RLE one?). I agree it's messy though, and needs a cleaner interface.

kklouzal · **Posted:** Mon Oct 21, 2013 9:34 am

Will do! I appreciate all the help

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

David Williams wrote:

Yep, done. I'll probably switch it to an exception in the future (I'm trying to move to a model of keeping asserts for bugs in PolyVox, and using exceptions for user errors) but I still want to wrap the exceptions in a set of macros so that they can be compiled out if desired.

Just a quick note that I've actually reverted the addition of these asserts - they were causing warnings on the build machine and I don't have time to fix them properly at the moment.

David Williams · **Joined:** Sun May 04, 2008 6:35 pm **Posts:** 1827

Just a note that I've made a couple of commits which tidy the code and simplify the way things are done with regard to block paging/compression. We had some crashes in Cubiquity and these are gone now, so it might be worth updating to the latest version of the code in 'develop'.

kklouzal · **Posted:** Fri Nov 22, 2013 12:04 pm

Thank you for the update, I just downloaded and compiled the latest version from develop branch, the program runs fine executing it through vs2012, but executing it on my own this happens:

PolyVox::LargeVolume

Who is online