Closed brussel13 closed 4 years ago
huh I've no idea why the normals would get reversed with our thing, @renefritze @xylar any ideas?
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.
I have no idea why that happens, but not letting paraview compute the normals itself fixes the display for me.
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.
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?
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.
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:
from pyevtk.hl import gridToVTK import numpy as np
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.
I workaround would be to use the calculator to set Normals
to -Normals
. This worked for me with the pyevtkout.vts
example.
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.
from pyevtk.hl import gridToVTK
import numpy as np
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:
from pyevtk.hl import gridToVTK import numpy as np
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.
@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.
@brussel13, to back up the idea that this is a ParaView, not a pyevtk issue, please do the following:
-coordsX*iHat + coordsY*jHat + coordsZ*kHat
and with Coordinate Result
checkedThe 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.
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.
Please re-open if there's new information pointing to this being a pyevtk issue.
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?