[vtkusers] VTK 7.0 vtkXMLPolyDataWriter output version issues

Dan Lipsa dan.lipsa at kitware.com
Mon Feb 13 17:23:17 EST 2017


Paul,
Do you have an example data + script where this is happening? It should not
be a difference in how the binary data is encoded between VTK and ParaView.

Thanks,
Dan


On Fri, Feb 10, 2017 at 11:00 AM, Paul Korir <pkorir at ebi.ac.uk> wrote:

> Hi Dan,
>
> Thanks for your reply. I'm not referring to VTK Ids.
>
> I'm specifically referring to the paragraph that says:
>
> "Binary Blob Header: In front of every binary blob, base64 or raw-binary,
> appended or not, there is an UInt32 length indicator. If you do not have
> this length indicator, you might get error messages like
>
> Cannot read cell offsets from XXXX in piece 0 because the "offsets" array
> is not long enough.
>
> Note that if you are encoding in base64, that length header must be
> encoded separately, so that the end result looks like XXXXXX==XXXX... (note
> the two equals signs indicating the early end of the length header block)."
>
> How do I get that to appear on the data array? It seems like Paraview does
> something internally that VTK programmers should be aware of.
>
> Regards,
>
> Paul
>
>
>
> On 10/02/2017 13:52, Dan Lipsa wrote:
>
>> Paul,
>> Looking closer that the blog it seems that a file with ghosts will have
>> version 2.0. The difference between 1.0 and 0.1 is caused by
>> VTK_USE_64BIT_IDS. Can you check that in your VTK's CMakeList.txt. It seems
>> that your VTK uses 32 bits while ParaView would use 64.
>> So that would explain the difference. Do you need/want to use 32 bits for
>> VTK? Can you recompile your VTK with 64 bit ids and retry.
>>
>> Dan
>>
>
> --
> Paul K. Korir, PhD
> Scientific Programmer
> EMBL-EBI
> 01223494422
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20170213/4a9996df/attachment.html>


More information about the vtkusers mailing list