LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

3d surface plot, 1:1 display of 2d array elements

Solved!
Go to solution

I thought i would be overly clever to use a 3d-surface plot to display my 2d data, because it has inputs for the x and y arrays beside the intensity data.

The intensity graph does not have these inputs. It uses the row/col array index as x/y coordinates.

I configured the 3d-surface plot to look from the top onto the x-y-plane, wired the 1d x/y arrays and the 2d intensity array and was impressed how wrong it looked...

At this point i wrote a small LV2013 test program whose screenshots are shown here.

test_3d_surface_birdview.PNG

test_3d_surface_birdview_BD.PNG

The test program lets you setup the 2d intensity array and the two 1d x/y arrays. For test purposes i set all these values as increasing natural numbers. However, in my real application (which should plot a height map) the x/y arrays contain real dimension data and not natural numbers. After running the test vi it just passes these data to the 3d-plot helper and for comparison to an intensity graph.

With the intensity graph i can get the correct display (beside up/down mirroring) when choosing the option to transform the array.

However when i manually transform the 2d intensity array before passing it to the 3d plot helper, the result is completely different from what the intensity graph displays.

 

This is what i get, when i omit the manual transform or exchange the x/y arrays and transform, too:

test_3d_surface_birdview_noTransform.PNG

This is what i get, when i exchange the x/y

 arrays without transform:

test_3d_surface_birdview_xyexchange.PNG

 

As you see, i tested all four possibilities but all result in a wrong display of the original data.

 

Do you have an idea what could be the solution?

 Thank you!

 

 

 

 

 

 

 

 

0 Kudos
Message 1 of 6
(3,509 Views)

These are different display approaches, they will not match.

3D surface displays surface, based on supplied values in vertices. It can try to match color of the surface in vertice, so it will change within rectangle (interpolate mode), or display an average of values in vertices. But for a 2x2 matrix it will display only one rectangle - shaded or not. 

Intensity graph draws a rectangle for each vertice (matrix element). For a 2x2 matrix it displays 4 rectangles. X and Y should be spaced evenly, but you can change scale: set X scale-> Range -> Offset and Multiplier (with property node or in properties).

 

0 Kudos
Message 2 of 6
(3,471 Views)

I will try it with a larger matrix. However the problem arised when wanting to plot a height data map with 640x480 map points and havent been able to get the correct orientation and size. My test program probably oversimplified things and therefore introduced additional artefacts.  Be back, soon.

 

0 Kudos
Message 3 of 6
(3,456 Views)

The test program now displays a 10x12 array(matrix) of an arrow with an additional bar and a pixel so that the orientation is unambigously determinable.

I found out that the x/y arrays should be wired as is and the 2d array should be transposed to get the same orientation as in the intensity graph. This is in agreement with the selected transpose option in the intensity graph context menu.

However, looking closer it is striking that the 3d plot misses the two rightmost columns of the input array. Then i measured the display window sizes in pixels and the arrow size in pixels. I scaled the intensity graph so that it's display window has exactly the same size as the display window of the 3d surface plot. It was 276x300 pixels.

For the intensity graph, the arrow size was the same as the display window. 276x300 piexels. This results in an aspect of 0,92. In contrast the arrow size of the 3d surface plot was 222x275 pixels despite the same size of the display window.

The aspect of 0,81 severely mismatches the aspect from the intensity graph.

 

In my opinion there is something wrong with the vertex routine.

 

I understand that the vertices must not coincide with the dimensions of the x/y grid determined from the x/y input arrays resulting in some anti aliasing like artefacts. This is not what i want to stress. I want to stress that there is data missing in the output and the output is non proportional scaled.

  

Following requirements would make sense in my opinion, because they catch what one would intuitively expect:

1.) The vertices should span the whole range of the x/y input arrays

2.) If one array element is not accounted to one vertex it should be accounted to a neighboring one

3.) The aspect of the rendered surface should be the same like in the intensity graph.

 

Opposed one is forced to stumble over completely contraintuitive output.

 

The Frontpanel with the new test matrix:

Arrow_3dSurface_FP.png

 

The arrow within it's Display window as displayed in the 3d plot

Arrow_3dSurface_DisplayWindow.png

 

The arrow as displayed in the 3d surface plot

Arrow_3dSurface.png

 

The arrow as displayed in the intensity graph

Arrow_IntensityGraph.png

 

 

 

0 Kudos
Message 4 of 6
(3,453 Views)
Solution
Accepted by topic author Labuser16383

1) Vertices do span the whole range of x and y on 3D graph. You said leftmost vertice at x=1, it is at x=1. You said rightmost vertice at 9, it is at 9.

Squares do not represent vertices, they are an interpolation of 4 vertices. 

2) For every array element there is a vertice. 

3) Why do you expect 2 different graphs to look the same and work the same?

0 Kudos
Message 5 of 6
(3,446 Views)

1) I assumed these x/y arrays somehow define the division of the surface (rectangular grid)

2) Ok i see, caused by the interpolation the No blocks per direction is No vertices-1

3) For the sake of consistency within one development environment. It's just a deep intuitive feeling that there should be as much correspondence as possible between the array elements textual display and the graphical view of them.

0 Kudos
Message 6 of 6
(3,433 Views)