is the “N samples” button in the slice renderer described in the VAPOR documentation?
I am having issues when creating a slice renderer for a python-defined variable: the spatial resolution of the slice is very bad, even when the N samples slider is raised to the maximum (which is automatically set to 2000 by VAPOR in the present case).
Yes, it’s documented here.
It’s surprising to hear that the resolution isn’t what you’d expect. The slice samples along the X and Y axes of a given plane, and the N Samples controls the sampling rate along both axes. 2000 samples should be sufficient unless the slice is larger than 2000x2000 pixels on your screen, at which point the slice would be under-sampling.
If you like, I can take a look at one of your files to see if I can pinpoint what’s going on.
thank you Scott
In the meantime, I have tested a few things, with somewhat puzzling results (now on vapor 3.5.0, since 3.6.0 was giving me problems with the canvas being 2x2 = 4 times the expected size – this sounds like an issue Viggo Hansteen was raising some months ago).
(a)
→ I have created vdc datasets directly for log T (to compare with the previous case, in which I was calculating log T through python scripts in the session). This behaves all right. When ‘fidelity’ is set to ‘high’, I get a ‘level of detail’ of 3 (1:1) and the refinement level is 3 (512x512x563). The (vapor-determined) N samples value is 563.
→ when I, instead, use the log T calculated via a python script in the session, I am getting the same problem I was reporting earlier today. In this case, when ‘fidelity’ is set to ‘high’, I get a ‘level of detail’ of 0 (1:1), and no possibility of modifying it (why “0”?). Still, the “refinement level” is 3 (512x512x563). The N samples value is 563, like in the previous case.
(b) on your point:
2000 samples should be sufficient unless the slice is larger than 2000x2000 pixels on your screen, at which point the slice would be under-sampling.
in fact, the number of pixels in the screen maybe a problem too. When I wrote the report hours ago, I was working in my office with a 27-inch monitor with (5120 × 2880) pixels (the new Apple monitor). Now I am working remotely from home and the monitor here is a more modest 32-inch (2560 × 1440) monitor.
thanks!
Fernando
I am encountering the same problem concerning low/high fidelity with the flow renderer: when using python-calculated variables, the calculation of the streamlines is carried out in low resolution no matter what. Setting the ‘fidelity’ button under variable to ‘high’ does not help: The ‘level of detail’ remains in low fidelity (‘0’) and the streamlines are visibly calculated in low resolution. This is a problem!
I tested the rendering of python variables on Vapor 3.6 on macOS (intel) and I am getting quite inconsistent results as well.
I was using a relatively small dataset with 180 x 128 x 128 pixels. To test the python variable, I just used one of the existing variables bz and defined a new python variable bb = bz. In principle, the slice renderer should have given the exact results from both bb and bz.
In the attached images, you can see that while the original variable (top image) is properly rendered, the python variable (middle image) is showing poor fidelity. I also attach an image of the python settings panel for reference.
Thanks for the info avijeet. There’s definitely something at play with what you and Fernando are seeing. Can you provide a sample of the data you’ve demonstrated in your screenshots? I’ve done some cursory tests with WRF data and cannot reproduce this, so I suspect this problem is dataset dependent.
PS - What data format is this?
in my case, it is vdc datasets
Hi,
In may case also, the dataset was vdc.
I am attaching the download link to the dataset here for your testing.
Thanks Avijeet. I see artifacts similar to what you describe in Vapor 3.6 but not on our weekly installer. The artifacts in your screenshot are more severe than what I’m seeing, and I suspect it’s because the first screenshot is using high fidelity and the second screenshot is on low.
Either way, I believe the weekly installer will fix your problem, unless your running on an M1 processor. @Fernando_M_Insertis has pointed out that the installer is crashing on his system, which is currently being investigated.
Screenshots of bz2=bz on Vapor’s weekly build:
1 Like
I have installed the weekly build 3.6.1 in an old Mac machine running on Big Sur. The problem with the python variables is gone ! (I have checked both the slice and flow renderers).
On the other hand, I have double-checked the problem with the M1 Mac machines: I have now tried two different machines with the M1 processor (a laptop, additionally to the desktop I was using a few days ago) and the crashes continue.
1 Like