okay,
about the int32 testing we could test a volume like 32x32x131072
takes only 128megs if uncompressed

Yes, absolutely, that's the kind of test we can do. Don't know if we can actually visualise the result of the whole things though - might be too much data for the GPU. But it's worth a shot

Cool to hear of the progress Good luck, hope to be able to use it soon! (Sure a lot of other do too)

ookay, i guess I had some issues still not worked out
this was a very good idea (doing it stepwise)

I am now quite confident that int32 coordinates work fine as I have tested all the surface extractors on volumes that have one dimension which is larger than the maximum uint16.
(I strongly advise against repeating those tests on machines with little ram (the volume is fine, it takes like 6 megabytes or so)... extracting the surfaces blew up some assertions you made (number of vertices < 1000000) and blows up ram really quickly.



this spreads everywhere... but I believe the changes I made to be overseeable this time

I also looked through the diff file, no formatting changes in places where I didn't change anything...

I might have forgotten some places where it is now necessary to check whether the coordinates are negative... not sure how much an issue this is, but usually people should know how they intend to use their volume

OpenGl example works, but does not test any 32bit things

about the streaming, we could introduce a half-step there by using the unordered_map but preloading it like compatibility mode function does it with RLE

Great stuff, I'll try to apply these changes tonight (i.e. in the next few hours) and commit them if everything is ok.

Good, I'm glad it has some benefit, rather than just causing frustration

Ok, I have applied your patch to the RLE branch

I had to make a couple of changes:

• Replaced 'std::numeric_limits<uint32_t>::max()' with '(std::numeric_limits<uint32_t>::max)()'. This is an annoying windows issue due to a globaly defined 'max' macro, I believe.
• The AStarPathfinder needed to be updated to int32 as well. You would have missed this because there were no tests for it so the templatised code would never have been compiled. It was picked up instead when testing Thermite.

The only other thing I noticed was that some uint16_t's had been changed to int32_t's when they didn't need to be. For example, getWidth() should always be positive even when positions can be negative. However, I didn't change this because I didn't want to break any of your other work. Besides, the whole concept of width is dubious in an infinite volume anyway... but I'm sure we'll come to that

Anyway, you should be able to update and make sure further patches are against the new latest version.

Oh, one other (important!) thing... I've assumed you agree to your code being released under the zlib license, but it would be great if you could officially state that for the record. I've also added a credits.txt file to the PolyVox root folder in the RLE branch so you are welcome to add your name to that.

Thanks again for the patch!

not even remotely as frustrating as it would have been later on when trying to figure out what went wrong...

yes of course, you may publish it under any license you see fit, as long as it allows me to still use it and thanks for the credits.
So to state for the record: I agree to my code being released under the zlib license.

ok, that is a weird windows issue...

yes I thought it would change too much in other places if I'd keep the width/depth/height parameters unsigned, especially since they'll get dropped soon anyway.

I'll check it out and test it now

I know you like not having any dependencies (or at least very few).
I could actually use standard library equivalents of the boost::bind and boost::function.
or just force the user to use inheritance by creating a virtual function for loading/unloading
what do you think?


also instead of an unordered_map, a simple map or hash_map should be sufficient (and optimizations through other (faster?) techniques can be done once the speed actually becomes a problem).

ugh... I've just noticed something really annoying
imagine you're accessing a voxel in a block that is not loaded yet.
there will be a call to load from inside getUncompressedBlock which is a const function.
load on the other hand tries to call setVoxel... which most definitly is not const.
is it evil in that case to const_cast away the constness of the this pointer of the volume and then pass it to load?

[edit] ok... inheritance is not a good idea
but c++0x allows me to get rid of all boost dependencies.
it doesn't look all too neat, but it does the job.
I'm still testing some things that might be troublesome... but streaming is working already
[/edit]

Yes, it would be good to remove the Boost dependancies (they can still be used by people with no C++0x). If you look in TypeDef.h you'll see there are already some typedef for things loke polyvox_shared_ptr being either boost or std.

I'm actually a bit hazy on bind/function - do you really need bind? I used function in the AStarPathfinder and don't think I used bind. Or is bind just used in the client code, so doesn't actually need to be used inside PolyVox?

I would avoid using inhetance for this problem, but you could also consider the Listener/Observer pattern. But overall I'd just stick with function until we do some kind of profiling.



Yep, pick one that's easy and standard, it should be quite easy to swap it around later.


Yes, this is a little tricky. It's hard to think through the code without actually doing it, but I think I would create a new setVoxel funtion e.g. setVoxelHorribleHack() which is actually const. Because it's const it can be called in the way you need, and it can still modify the data because the relevant data can be declared as mutable.

This should work for now, then later on this new method can be made private. We then create some kind of VolumeModifier/VolumeProxy class which is a friend of the Volume. Because it's a friend it can call the private function, and we pass one of these VolumeProxy objects to the callback functions instead of the actual volume. This also has the advantage that they can ensure the user only modifies the voxels they have been told to in the callback function.

As our final trick, we make the constructor of VolumeProxy private (so users can't create them themselves) and make Volume a friend so that Volume can still create them when need be.

Ok, maybe it can be simpler, or maybe it doesn't work, but it's a starting point. But for your next patch just keep it somple by making the new setVoxelHack() funcion public while we check the streaming works.

ok, I'm getting issues at block borders in the negative range again...
(only with SurfaceExtractor. Cubic is fine)
I'm looking though the code, but I can't figure out how that can happen :/

Apparently only along one axis though - probably the z axis? Are the trianges actually missing, or are they being drawn in black? If they are being drawn in black it's probably an issue with the normals, but I think they are actually missing.

Also, this is leaving aside the streaming? It's just because of negative positions? I think I can probably take a look at this myself - there's a good chance it's a bug in the SurfaceExtractor, or at least an invalid assumption. The SurfaceExtractor code is horrible so it might be better for me to look at this issue. Presumably it will also occur on the version of the code which I have in the branch, if you give me your example code?