[vtkusers] 64bit indexing for vtkStructuredPoints issue

[Jim Geach]

hi david,

thanks for your reply - yes, sorry i didn't articulate that very well.

but basically, yes, my question was whether i need to do any special casting in python to make sure vtk objects interpret python ints as a 64-bit signed int. it sounds like i don't (and vtk was built with VTK_USE_64BIT_IDS on). 

the debugging i've done seems to suggest that is working, so perhaps it is -- as you suggest -- in the rendering. indeed i am doing volume rendering... for the large grids that require 64-bit indexing i can get the volume to render, but it's clear that some parts of the volume are in the wrong place (i.e. the volume looks semi-sensible -- it's not complete garbage). 

might this sort of rendering behaviour be related to the issues you mention (and if so, should we build the bleeding edge version?).

thanks, jim

On 2012-02-21, at 6:55 PM, David Gobbi wrote:

> Hi Jim,
> 
> I'm not sure if I understood most of your email, but here goes.
> 
> In your last paragraph when you talk about indexing using integers...
> you mean when you call the vtkDataArray methods from Python, right?
> Assuming that you are using VTK 5.8 or newer, and compiled with
> VTK_USE_64BIT_IDS, then VTK is using extended-precision integers
> on the Python side and 64-bit signed integers on the C++ side.  If you
> are wondering if you should be doing some sort of casting inside
> python, the answer is no.
> 
> The vtkIdType is a 64-bit signed int (type "long long").  It can't be
> "unsigned long" because longs are only 32 bits on Win64 machines.
> 
> If what you're using VTK's volume rendering, then the 32-bit issues
> might be in the rendering, not with the arrays.  The VTK volume
> rendering in VTK 5.8 was not 64-bit safe.  I committed some patches
> today that might fix this, but the jury is still out.
> 
> - David
> 
> 
> On Tue, Feb 21, 2012 at 10:18 AM, Jim Geach <jimgeach at physics.mcgill.ca> wrote:
>> 
>> dear list,
>> 
>> (note - this is a vtk python related question)
>> 
>> i'm rendering very large grids that require 64bit indexing in the scalar component. due to a bug in the way that numpy hands over large arrays to vtk objects, i've had to come up with an inelegant solution of filling a vtkArray in a sequence of managable chunks and keeping track of the last index.
>> 
>> this works, and tests on smaller data cubes come out looking the way they should. however, once the index exceeds MAX_INT, weird things start happening -- the resulting volume looks jumbled up, like data was placed in the incorrect position. volumes aren't completely garbled, but it's clear where discontinuities are. these effects don't occur for volumes of less than ~1024^3
>> 
>> now, i'm indexing using long integers, but i have a feeling that this is casting is being ignored when i use InsertValue to place a value in the vtk object (i.e. vtk thinks i'm passing a standard int). the first argument to InsertValue should be a vtkIdType, but i am not explicitly casting my index as such (was assuming that vtk was interpreting and casting itself)... could this be the problem?
>> 
>> i guess my question boils down to: how do i cast my index as the correct vtkIdType (presumably a VTK_UNSIGNED_LONG in this case)?
>> 
>> thanks, jim