Add support for 64 bit integers

[voodooattack]

Hi, I'm trying to use Field3D to store indices into a hash table, which maps voxels to my own structure. Adding signed/unsigned 64 bit integer support to the library seems quite straightforward, but I have to use hacks (raw pointer casting to and from double) to achieve this at the moment and I'm worried about portability.

Could someone please implement this?

[magnusw]

Hi,

I'll get this added as an issue.

One question - do you need to write these to disk? If not, you're free to
use whatever template argument you like with with the various Field3D
classes. For example, I often use DenseField<int64_t>, and even
DenseFieldstd::vector for some raytracing acceleration structures.

Magnus

On Sun, Dec 22, 2013 at 11:35 AM, Abdullah A. Hassan <
[email protected]> wrote:

Hi, I'm trying to use Field3D to store indices into a hash table, which
maps voxels to my own structure. Adding signed/unsigned 64 bit integer
support to the library seems quite straightforward, but I have to use hacks
(raw pointer casting to and from double) to achieve this at the moment and
I'm worried about portability.

Could someone please implement this?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/77
.

[voodooattack]

Thank you; and yes, I'm using the library as a subsystem to store voxel data for my procedural terrain generator and I've implemented a "file paging system" where each chunk is loaded and saved as needed in the background. It works like SparseFileManager, but allows me to write the data dynamically as well as read it.

The performance is amazing until it reaches the point where the paging manager has to unload a chunk, then I get this exception:
terminate called after throwing an instance of 'Field3D::v1_4::Exc::WriteLayerException' what(): DenseFieldIO does not support the given DenseField template parameter

[magnusw]

I see. It should be easy to add, we just never got around to it in the past. I should be able to get to it once I'm back to work in the new year.

(Merged into #78)