{"id":83,"date":"2014-11-04T09:51:33","date_gmt":"2014-11-04T14:51:33","guid":{"rendered":"https:\/\/blogs.mathworks.com\/graphics\/?p=83"},"modified":"2016-06-29T14:19:51","modified_gmt":"2016-06-29T18:19:51","slug":"sortmethod","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/graphics\/2014\/11\/04\/sortmethod\/","title":{"rendered":"SortMethod"},"content":{"rendered":"

SortMethod<\/h3>

Today we're going to talk about the SortMethod property which was added to the Axes object in R2014b. It's actually been around for a long time, but it wasn't supported by all renderers, and it had the confusing name 'DrawMode'. We renamed it because it's a very important property and we want to make sure that everyone understands what it is for.<\/p>

First we'll create a very simple scene. This is just 3 patch objects. I've set they're DisplayName properties so that we'll recognize them when we see them at the command line.<\/p>

Also note that they are coplanar. In other words, they all have the same Z coordinates. That's going to be important later.<\/p>

figure\r\npatch([1 3 3 1],[1 1 3 3],[0 0 0 0],'r'<\/span>, 'DisplayName'<\/span>,'red'<\/span>)\r\npatch([2 4 4 2],[2 2 4 4],[0 0 0 0],'g'<\/span>, 'DisplayName'<\/span>,'green'<\/span>)\r\npatch([3 5 5 3],[3 3 5 5],[0 0 0 0],'b'<\/span>, 'DisplayName'<\/span>,'blue'<\/span>)\r\n<\/pre>\"\" 
As we can see here, the last patch we created is the first one in the Children list of the Axes.<\/p>
ax = gca;\r\nax.Children\r\n<\/pre>
\r\nans = \r\n\r\n  3x1 Patch array:\r\n\r\n  Patch    (blue)\r\n  Patch    (green)\r\n  Patch    (red)\r\n\r\n<\/pre>
The last patch added is also the one we see in the areas where they overlap. The blue patch covers the green one, and the green patch covers the red one.<\/p>
That's because the SortMethod property of the axes is set to 'childorder'.<\/p>
ax.SortMethod\r\n<\/pre>
\r\nans =\r\n\r\nchildorder\r\n\r\n<\/pre>
I can change the order of the children by setting the Children property to a permutation of it's current value. Notice what happens to the picture.<\/p>
ax.Children = ax.Children([2 3 1]);\r\nax.Children\r\n<\/pre>
\r\nans = \r\n\r\n  3x1 Patch array:\r\n\r\n  Patch    (green)\r\n  Patch    (red)\r\n  Patch    (blue)\r\n\r\n<\/pre>\"\" 
Now the green patch is first, so it covers both the red one and the blue one. The rule with childorder is pretty simple. An object which is near the beginning of the Children list always covers an object which is later in the Children list.<\/p>
So what happens if we set SortMethod to the other option?<\/p>
ax.SortMethod = 'depth'<\/span>;\r\n<\/pre>\"\" 
Eww! That's a mess, isn't it? Why would we ever want that? To answer that question, we'll have to take a trip to \"the third dimension\" (I don't know the markup for adding scifi echo sound effects to that last phrase).<\/p>
So let's start over. We'll create a new figure so we can come back to that example later.<\/p>
Next we'll create a simple 3D scene out of patches. In this case the Z coordinates are not the same. Instead of being coplanar, these patches are arranged around the outside of a cube.<\/p>
figure(2)\r\npatch([1 2 2 1],[1 1 2 2],[1 1 1 1],'r'<\/span>, 'DisplayName'<\/span>,'red'<\/span>)\r\npatch([2 2 2 2],[1 1 2 2],[1 2 2 1],'g'<\/span>, 'DisplayName'<\/span>,'green'<\/span>)\r\npatch([2 1 1 2],[1 1 2 2],[2 2 2 2],'b'<\/span>, 'DisplayName'<\/span>,'blue'<\/span>)\r\npatch([1 1 1 1],[1 1 2 2],[2 1 1 2],'c'<\/span>, 'DisplayName'<\/span>,'cyan'<\/span>)\r\nview(3)\r\nax = gca;\r\nax.Children\r\n<\/pre>
\r\nans = \r\n\r\n  4x1 Patch array:\r\n\r\n  Patch    (cyan)\r\n  Patch    (blue)\r\n  Patch    (green)\r\n  Patch    (red)\r\n\r\n<\/pre>\"\" 
At first it looks like the same rules apply here. The cyan patch is first, and it covers the red one. Same with the blue and green patches.<\/p>
But if we permute the children in this case, the picture doesn't change.<\/p>
ax.Children = ax.Children([4 1 3 2]);\r\nax.Children\r\n<\/pre>
\r\nans = \r\n\r\n  4x1 Patch array:\r\n\r\n  Patch    (red)\r\n  Patch    (cyan)\r\n  Patch    (green)\r\n  Patch    (blue)\r\n\r\n<\/pre>\"\" 
That's because the SortMethod property has changed.<\/p>
ax.SortMethod\r\n<\/pre>
\r\nans =\r\n\r\ndepth\r\n\r\n<\/pre>
The axes has noticed that we have a 3D scene and it has chosen depth instead of childorder. In most cases the axes will choose the correct value and we won't have to worry about our SortMethod. But the property allows us to override the choice that axes makes.<\/p>
So lets try setting it to childorder for this scene.<\/p>
ax.SortMethod = 'childorder'<\/span>;\r\n<\/pre>\"\" 
Wow, it turned inside out! Now permuting the children does change the picture.<\/p>
ax.Children = ax.Children([3 2 1 4]);\r\nax.Children\r\n<\/pre>
\r\nans = \r\n\r\n  4x1 Patch array:\r\n\r\n  Patch    (green)\r\n  Patch    (cyan)\r\n  Patch    (red)\r\n  Patch    (blue)\r\n\r\n<\/pre>\"\" 
What's happening is that when we use 'depth' for the SortMethod, the graphics system sorts all of the objects in \"depth\" order. This means that it ensures that the objects which are closer to the viewer cover the objects which are farther from the viewer.<\/p>
ax.SortMethod = 'depth'<\/span>;\r\n<\/pre>\"\" 
But that still doesn't explain this picture, does it?<\/p>
figure(1)\r\nax = gca;\r\nax.SortMethod = 'depth'<\/span>;\r\n<\/pre>\"\" 
What's going on here is that the technique that the graphics system uses to sort the objects struggles when it encounters coplanar objects. When it finds coplanar objects, it tries to draw them in child order, but it has a number of limitations. Most notably, the default renderer (OpenGL) tends to let lines win over faces in coplanar situations. It does this to make sure that you can always see the edges of a patch, even when that patch is drawn at a funny angle. It actually works pretty well in most cases, but here it is making the edges of the red and blue patches poke through the green patch.<\/p>
Depth sorting techniques is one of oldest and richest corners of computer graphics programming. Many different techniques have been developed over the years. They all have different combinations of strengths and weaknesses, and they all have different performance characteristics.<\/p>
Different graphics cards can actually get different results in these coplanar cases. And different renderers can too. The painters renderer, which is used for generating vector file formats like PDF, uses a different sorting technique which has different limitations in this coplanar case.<\/p>
set(1,'Renderer'<\/span>,'painters'<\/span>);\r\n<\/pre>\"\" 
But the depth sort that the painters renderer uses works fine on our scene that doesn't have coplanar patches.<\/p>
figure(2)\r\nset(2,'Renderer'<\/span>,'painters'<\/span>);\r\n<\/pre>\"\" 
I hope that you've learned a little more about an important, but underappreciated axes property.<\/p>