Closed BenWibking closed 4 days ago
Thanks for this report, I an reproduce the black render both on macOS and Linux, so it's not macOS specific.
VTK-9 may be the source of the rendering difference.
I can see the field if I elevate with zero height, but that won't be a workable solution.
I can't reproduce the rotation issue, can you describe that a bit more?
I can't reproduce the rotation issue, can you describe that a bit more?
It's a bit hard to describe, so here is a screen recording. I restored the session, and then moved my cursor in and around the main viewer window. It behaves as if I immediately click the left mouse button as soon as my cursor enters the viewer window (which I am not doing). This means that whenever the pan/zoom tool is activated, I can't move the cursor across the viewer window without causing a camera rotation. The same is true of the zoom tool and the pick tool: if I activate either of these as I did in the screen recording, it then acts as if I pressed the left mouse button as soon as the cursor enters the viewer.
https://github.com/visit-dav/visit/assets/1781919/64352c4d-7c15-4a79-bfd9-c98f5bfb4304
@BenWibking The spatial extents are very large. As a workaround until we can sort out the internal problem with very large extents there is a workaround: Apply the Transform operator with the Scale option. 1e-10 worked well for me for both x and y.
@BenWibking The spatial extents are very large. As a workaround until we can sort out the internal problem with very large extents there is a workaround: Apply the Transform operator with the Scale option. 1e-10 worked well for me for both x and y.
That fixes the scaling issue, but VisIt is still unusable due to the camera rotation bug:
https://github.com/visit-dav/visit/assets/1781919/264e4226-f814-47b2-b3d0-d9183866a030
As you can see above, on my internal laptop display, there also appears to be an issue with font sizes. That issue goes away when I use an external display (used for the previous screen recording).
@BenWibking The spatial extents are very large. As a workaround until we can sort out the internal problem with very large extents there is a workaround: Apply the Transform operator with the Scale option. 1e-10 worked well for me for both x and y.
The black window seen when rendering data with large spatial extents can be duplicated with a very simple VTK dataset. I created VTK issue 18467 a couple of years ago.
My viewer window bug appears to be the same as this issue: https://github.com/visit-dav/visit/issues/19506, although I don't have an external USB-C mouse to test immediately on my Mac to confirm.
My cursor issue is fixed by using an external mouse.
Re: large extents issue, following the comments on the VTK issue 18467, VisIt could work around the problem by always supplying Normals. It would require modifying the Normals filter used by avtPlot to use vtkGeometryFilter if the input isn't polydata or a structured grid.
Or we could add a patch to bv_vtk that duplicates the patch being considered in VTK MR 11234 until such a time as we are using the VTK version with this applied.
Describe the bug
My AMReX datasets fail to render with VisIt 3.4.1 and instead render as black surfaces. They worked with 3.3.3.
Also, the GUI in the main viewer window does not allow the user to stop the camera rotation, so once the user clicks inside the viewer window, the camera rotation cannot be unselected. This does not happen with 3.3.3.
Helpful additional information
To Reproduce
Steps to reproduce the behavior. For example:
3.4.1 screenshot (incorrect):![Screenshot 2024-05-01 at 3 08 48 PM](https://github.com/visit-dav/visit/assets/1781919/46cadcd6-e5dd-44cc-a928-1afc23467791)
Expected behavior
The rendering should look like this:![Screenshot 2024-05-01 at 3 10 38 PM](https://github.com/visit-dav/visit/assets/1781919/888cb90a-4241-4054-bcad-a8948de82112)
Attachments
Zipped sessionfile and dataset: visit_341_reproducer.tar.gz
Desktop
Additional context
The incorrect rendering may be related to: https://github.com/visit-dav/visit/issues/17602. However, this issue happens even without volume rendering, which is a regression from 3.3.3.