structured grid normal reversed

[brussel13]

I written a structured grid to a vtk file using both the vtk python interface and pyevtk. The structuredgrid, when rendered with an contour in paraview appears dark using the file written with pyevtk. The attached image shows the vtk lib output rendering on the left and the pyevtk output on the right.
Is there an easy fix to this?

[somada141]

huh I've no idea why the normals would get reversed with our thing, @renefritze @xylar any ideas?

[brussel13]

All,

The two files can be downloaded here. I would be curious to see if this is different for others using paraview. One is old binary vtk which has been cropped to 1/2 the array size in each dimension by our old viz codes that use vtk. The other is the original data written to xml by pyevtk and is the full array. But the data used to write the files is the same. https://anl.box.com/s/5taccaawo9ktghave6l29hw4605vj9zu

Ross

On Thu, Aug 1, 2019 at 4:59 PM Adamos Kyriakou notifications@github.com<mailto:notifications@github.com> wrote:

huh I've no idea why the normals would get reversed with our thing, @renefritzehttps://github.com/renefritze @xylarhttps://github.com/xylar any ideas?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/pyscience-projects/pyevtk/issues/14?email_source=notifications&email_token=ABZ6SOF5WFXKYE2ABCAV7E3QCNME5A5CNFSM4IIWNI22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3MAIWY#issuecomment-517473371, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABZ6SOAJYXOSPM3FEA7RRATQCNME5ANCNFSM4IIWNI2Q.

[renefritze]

I have no idea why that happens, but not letting paraview compute the normals itself fixes the display for me.

[brussel13]

Yes, I did find that as well, but then you see the polygons, which is not so attractive.

Ross

On Fri, Aug 2, 2019 at 2:14 AM René Fritze notifications@github.com<mailto:notifications@github.com> wrote:

I have no idea why that happens, but not letting paraview compute the normals itself fixes the display for me. [Screenshot_20190802_091058]https://user-images.githubusercontent.com/47802/62351484-f0bea280-b505-11e9-9c44-0667b8fcb32d.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/pyscience-projects/pyevtk/issues/14?email_source=notifications&email_token=ABZ6SOAW3MFIICDICQD7LQ3QCPNGNA5CNFSM4IIWNI22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3M3V5Y#issuecomment-517585655, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABZ6SOFC3CSHZXYYVZQR7XLQCPNGNANCNFSM4IIWNI2Q.

[renefritze]

My guess would be that one lib writes the face id lists clockwise and the other counterclockwise. Could you maybe replicate this setup with a smaller overall data set and using appended/inline:text instead of appended:raw in the output?

[xylar]

I tried to replicate the problem with a simpler script:

#! /usr/bin/env python
from pyevtk.hl import gridToVTK
import numpy as np

# Dimensions
nx, ny, nz = 11, 11, 11

X = np.linspace(-1., 1., nx)
Y = np.linspace(-1., 1., ny)
Z = np.linspace(-1., 1., nz)

x, y, z = np.meshgrid(X, Y, Z, indexing='ij')

r = np.sqrt(x**2 + y**2 + z**2)

gridToVTK('./structured', x, y, z, pointData={'r': r, 'x': x})

r = 1.-np.sqrt(x**2 + y**2 + z**2)

gridToVTK('./structured2', x, y, z, pointData={'r': r, 'x': x})

and the normals look right. (The second test was just to make sure that the problem wasn't the fact that higher values are inside of lower values in @brussel13's example.)

We're going to have a hard time helping to debug this issue without a script used to generate the .vts file and I agree with @renefritze that it would be helpful if a simpler example like the one above could reproduce it.

[brussel13]

All,

Thanks for the simple example. I'll try a few things now and see what I can do. Will let you know.

Ross

On Fri, Aug 2, 2019 at 12:23 PM Xylar Asay-Davis notifications@github.com<mailto:notifications@github.com> wrote:

I tried to replicate the problem with a simpler script:

! /usr/bin/env python

from pyevtk.hl import gridToVTK import numpy as np

Dimensions

nx, ny, nz = 11, 11, 11

X = np.linspace(-1., 1., nx) Y = np.linspace(-1., 1., ny) Z = np.linspace(-1., 1., nz)

x, y, z = np.meshgrid(X, Y, Z, indexing='ij')

r = np.sqrt(x2 + y2 + z**2)

gridToVTK('./structured', x, y, z, pointData={'r': r, 'x': x})

r = 1.-np.sqrt(x2 + y2 + z**2)

gridToVTK('./structured2', x, y, z, pointData={'r': r, 'x': x})

and the normals look right. (The second test was just to make sure that the problem wasn't the fact that higher values are inside of lower values in @brussel13https://github.com/brussel13's example.)

We're going to have a hard time helping to debug this issue without a script used to generate the .vts file and I agree with @renefritzehttps://github.com/renefritze that it would be helpful if a simpler example like the one above could reproduce it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/pyscience-projects/pyevtk/issues/14?email_source=notifications&email_token=ABZ6SOBCRGF6JE52MC4LI3TQCRUPLA5CNFSM4IIWNI22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OLQ4Y#issuecomment-517781619, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABZ6SOGCCM47TRVBTLT7JHDQCRUPLANCNFSM4IIWNI2Q.

[xylar]

I workaround would be to use the calculator to set Normals to -Normals. This worked for me with the pyevtkout.vts example.

[brussel13]

All,

I modified the simple example sent by Xylar. It represents what I need in my implementation, with the X axis coordinates running in the reverse direction. This inverts the normals as attached.

! /usr/bin/env python

from pyevtk.hl import gridToVTK

import numpy as np

Dimensions

nx, ny, nz = 11, 11, 11

X = np.linspace(1., -1., nx) . #inverted +/- here

Y = np.linspace(-1., 1., ny)

Z = np.linspace(-1., 1., nz)

x, y, z = np.meshgrid(X, Y, Z, indexing='ij')

r = np.sqrt(x2 + y2 + z**2)

gridToVTK('./structured', x, y, z, pointData={'r': r, 'x': x})

r = 1.-np.sqrt(x2 + y2 + z**2)

gridToVTK('./structured2', x, y, z, pointData={'r': r, 'x': x})

On Fri, Aug 2, 2019 at 12:26 PM Ross Harder rharder@anl.gov<mailto:rharder@anl.gov> wrote: All,

Thanks for the simple example. I'll try a few things now and see what I can do. Will let you know.

Ross

On Fri, Aug 2, 2019 at 12:23 PM Xylar Asay-Davis notifications@github.com<mailto:notifications@github.com> wrote:

I tried to replicate the problem with a simpler script:

! /usr/bin/env python

from pyevtk.hl import gridToVTK import numpy as np

Dimensions

nx, ny, nz = 11, 11, 11

X = np.linspace(-1., 1., nx) Y = np.linspace(-1., 1., ny) Z = np.linspace(-1., 1., nz)

x, y, z = np.meshgrid(X, Y, Z, indexing='ij')

r = np.sqrt(x2 + y2 + z**2)

gridToVTK('./structured', x, y, z, pointData={'r': r, 'x': x})

r = 1.-np.sqrt(x2 + y2 + z**2)

gridToVTK('./structured2', x, y, z, pointData={'r': r, 'x': x})

and the normals look right. (The second test was just to make sure that the problem wasn't the fact that higher values are inside of lower values in @brussel13https://github.com/brussel13's example.)

We're going to have a hard time helping to debug this issue without a script used to generate the .vts file and I agree with @renefritzehttps://github.com/renefritze that it would be helpful if a simpler example like the one above could reproduce it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/pyscience-projects/pyevtk/issues/14?email_source=notifications&email_token=ABZ6SOBCRGF6JE52MC4LI3TQCRUPLA5CNFSM4IIWNI22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3OLQ4Y#issuecomment-517781619, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABZ6SOGCCM47TRVBTLT7JHDQCRUPLANCNFSM4IIWNI2Q.

[xylar]

@brussel13, thanks for the example. I can reproduce the problem. Do you have any reason to think this is an issue with pyevtk, as opposed to how ParaView is handling .vts files differently from .vtk? That would be my first suspicion.

[xylar]

@brussel13, to back up the idea that this is a ParaView, not a pyevtk issue, please do the following:

• Add a sphere in ParaView
• Apply the calculator filter with the following: -coordsX*iHat + coordsY*jHat + coordsZ*kHat and with Coordinate Result checked

The result also has the "wrong" normals, appearing darker than before the calculator filter, just as in your example. I believe reversing the normals manually is likely the best solution. Or this should be raised as an issue with Kitware. If you agree, please close the issue.

[renefritze]

To further what @xylar said, I've checked section 3.1.5 of the ParaView Guide and it mentions no assumptions on the coordinates array other than it being flat and strided indexed.

[renefritze]

Please re-open if there's new information pointing to this being a pyevtk issue.