Ok, great. I'll try to make some progress over the weekend

Also, does anyone else hate the smiley's on this forum? The guy looks really uncomfortable

Yeah, they look a bit awkward . Maybe I'll have a look for a better smiley pack. Perhaps one with a better alpha channel to get rid of the white border.

_________________
Matt Williams
Linux/CMake guy

Well, this forum looks like its from 1995.
You really need a completely new theme hah.

Sure, if you can find something that would be great. I'm sure it's not hard I've just never looked into it.

Yeah, we've been talking about a new website, possibly some time in the next six months. And we'll probably avoid white text on a dark background next time - I'm pretty sure nobody uses that any more

Put it orange on yellow!

I'll be sure to keep that in mind

@ker - Ok, I've started looking at this.

First I commited you patch exactly how it was, so that at least should work for you.

Next I fixed some compile errors, particularly with Boost. Actually, I have found that when the load and unload functions are std::function there is no need to use std::bind in order to set them up. I do not know if this is also true with Boost. Maybe you can verify? The code now looks like this:



Lastly, I have reverted some of your commit in order to bring back the concept of volume width, height, and depth. Actually I'm still working on tidying up the interface here, but the idea will be that every volume will be a fixed size, but if you don't specify a size it will default to the maximum size allowed by int32_t (which is pretty close to infinite).

I also reverted the OpenGL example so it uses a fixed size volume again, while the BasicExample is still testing the streaming. I'm trying to keep both these examples working at all times, so any commit I make should continue to work for you. Let me know if I break something in your project...

Nothing ever gets close to infinity

So to make it clear, now we can set size like 1028 and getVoxel(2000) will be invalid again, no matter streaming?

If we ask for getVoxel(500) it will call the streaming functions as discussed before? So kind of combining the two ways?

And if no size is specified, the size is just huge anyway and streaming, again as before?

Wondering as it means I should edit the editor I posted to use region.CropTo to avoid illegal voxels editing.

Well, it's closer than it was before. But I'm pretty sure mathmaticians would disagree with me there

Yes, that's correct. Or do you think that doesn't make sense for some reason?

I think that if you specify a size the streaming will probably be disabled by default, but there'll be a bool parameter to the constructor to override this. So yes, provided you enable streaming it will work as before.

Yep, that's right.

Maybe... but decisions aren't final yet so don't go out of your way to adapt. If you think something doesn't make sense then just say.

I think it all makes sense. Allowing streaming for specific size makes sense, also allowing non streaming makes sense, boolean could do well.

Only thing which might not make sense is the max int as size, though it isn't bad at all considering how big it is, I know I doubt I'd ever need more, after all -62k to 62k is quite a bit. Though some others might want the option for more. I am personally not too concerned.

Oh that brings another question, can we go to negative numbers now? How? We couldn't before, could we? Can you elaborate on that please?

Thank you

P.S. I think have the min-max int for "infinite" volumes is good cause then I know for my own personal use that I can keep the crop region logic which may serve for multi-case volumes, specific size can use it and it won't break functionality in non-specific size terrain. I believe it will allow both users of the different volume types to easily switch from one to the other and not breaking their code horribly, as well as allowing them have just one class to handle both cases in a very simple and easy manner. I say keep it