# How to turn off depth sorting of 3D curves for Manipulate? [closed]

Is there a way to turn off the default depth sorting of curves in a 3D output of several complicated curves ? Currently, I suspect that depth sorting has a very strong impact on performances on my Manipulate box, and would like to turn it off, to see if there's an improvement (I'm sure it will !).

Here's a cheap MWE to work with :

curve1[t_] := ParametricPlot3D[
{Sin[3 Pi s], Cos[5 Pi s^2], Cos[3 Pi s] Sin[3 Pi s]},
{s, 0.001, t},PlotStyle -> Directive[Thickness[0.02], Red]]

curve2[t_] := ParametricPlot3D[
{1.3 Sin[7 Pi s], 0.5 Cos[2 Pi s], 0.4 Sin[6 Pi s^2]},
{s, 0.001, t},PlotStyle -> Directive[Thickness[0.02], Blue]]

Manipulate[Show[
{curve1[t], curve2[t]},
PlotRange -> {{-1.5, 1.5}, {-1.5, 1.5}, {-1.5, 1.5}},
Boxed -> True, Axes -> True, AxesOrigin -> {0, 0, 0},
SphericalRegion -> True,
Method -> {"RotationControl" -> "Globe"},
ImageSize -> 600
], {{t, 1, "t"}, 0, 12, 1}]


EDIT 1 : Depth sorting is the ordering of elements in 3D space. One in front of the other, as seen by the observer. This is a standard concept in 3D modeling, games, etc... Mathematica clearly do it too (by default), if you watch closely its 3D output of thick curves. Depth sorting is necessary when there are surfaces.

In my special case, I have no surfaces, just a single complicated thin curve. I don't need depth sorting in its case. Turning off depth sorting of that curve elements should improve a lot performances.

EDIT 2 : Here's an example of apparent no depth sorting in Mathematica, from Silvia :

Plot3D[x+y,{x,-1,1},{y,-1,1},AxesOrigin->{0,0,0},Mesh->None,Boxed->False]


While moving around that plane, you'll notice that the axis, ticks and labels are always shown "on front". They don't display any "depth sorting" of their elements. This is what I would like to achieve for curves.

There's also a strong advantage in getting no depth sorting of curves : when exporting a Mathematica 3D curve to a PDF file, and open the file with another vectorial application, you'll get the curve made of lots of small bits. The whole curve is then very hard to edit in a proper way. Without depth sorting of the curve, the curve would be of a single piece. This is highly desirable for exportation to another vectorial app.

EDIT 3 : Compare the output from the code above, with the output from the same code with the default thickness of curves (code below). The depth sorting is still there, but it is useless since it is not visible from this output :

curve1[t_] := ParametricPlot3D[
{Sin[3 Pi s], Cos[5 Pi s^2], Cos[3 Pi s] Sin[3 Pi s]},
{s, 0.001, t},PlotStyle -> Red]

curve2[t_] := ParametricPlot3D[
{1.3 Sin[7 Pi s], 0.5 Cos[2 Pi s], 0.4 Sin[6 Pi s^2]},
{s, 0.001, t},PlotStyle -> Blue]

Manipulate[
Show[
{curve1[t], curve2[t]},
PlotRange -> {{-1.5, 1.5}, {-1.5, 1.5}, {-1.5, 1.5}},
Boxed -> True, Axes -> True, AxesOrigin -> {0, 0, 0},
SphericalRegion -> True,
Method -> {"RotationControl" -> "Globe"},
ImageSize -> 600
], {{t, 1, "t"}, 0, 12, 1}]


Just to emphasize it : Depth sorting is not visible on thin curves and is thus useless. If a curve is very complicated, depth sorting may have a significant impact on some hardware, and it is desirable to turn it off.

## closed as off-topic by MarcoB, halirutan♦, m_goldberg, Henrik Schumacher, eyorbleJun 1 '18 at 22:45

This question appears to be off-topic. The users who voted to close gave these specific reasons:

• "The question is out of scope for this site. The answer to this question requires either advice from Wolfram support or the services of a professional consultant." – halirutan, Henrik Schumacher, eyorble
• "This question arises due to a simple mistake such as a trivial syntax error, incorrect capitalization, spelling mistake, or other typographical error and is unlikely to help any future visitors, or else it is easily found in the documentation." – MarcoB, m_goldberg
If this question can be reworded to fit the rules in the help center, please edit the question.

• So, um, what is "depth sorting"? – Jason B. Mar 11 '16 at 15:46
• @Cham, please remain civil, this means not yelling at those who are trying to understand and help (your repeated use of exclamation points is what I'm talking about here) – Jason B. Mar 11 '16 at 16:14
• Cham, I am not the one who down-voted. However I am wondering what an image without depth sorting, or Z buffering, would look like. Perhaps others are also. Second, I do not find it apparent that Z-buffering is a significant performance issue on modern hardware; what reference or direct evidence can you give to support your assertion that it is? – Mr.Wizard Mar 11 '16 at 21:55
• Regarding "Mathematica has to calculate lots of useless depth sorting", I think the calculation is not done by Mathematica, but forwarded to OpenGL or DirectX engine of the host OS. – Silvia Mar 12 '16 at 11:55
• @Cham: Sorry for the car analogy, but that's like saying "my experience with my car has shown me that an automatic transmission wastes a lot of fuel. My plane uses too much fuel, so I'd like to turn of it's automatic transmission". Unless two systems use the same underlying algorithms and similar implementations, you can't transfer performance assumptions like that. – Niki Estner Mar 12 '16 at 12:32

I don't think Mathematica is using depth sorting to decide surface visibility. My reasoning is that a geometry like this:

Graphics3D[
Table[
{
AbsoluteThickness[10],
If[OddQ[u/(60 °)], Red, Blue],
Line[{{Cos[u], Sin[u], -.1}, {Cos[u + 80 °],
Sin[u + 80 °], +.1}}]
}, {u, 0, 360 °, 60 °}], Boxed -> False]


would be displayed incorrectly if the red and blue lines were sorted, then simply drawn in that order.

I strongly believe what is really going on here is called Z-buffering. In a nutshell, it means the GPU stores a depth value for every pixel, and when it renders a new pixel it compares the new pixel's depth with the old depth value, only rendering pixels with lower depth (closer to the viewer). Almost any graphics hardware available today (even tablets and cell phones) support this in hardware, so there is virtually no performance cost.

From the documentation:

The 3D renderer uses two different methods of sorting polygons. For graphics scenes that include no transparency, a hardware-accelerated depth buffer is used. Otherwise, the renderer uses a binary space partition tree to split and sort polygons from any viewpoint. The BSP tree is slower to create and is not hardware accelerated, but it provides the most general ability to support polygons.

So, if you want to avoid the performance hit, don't use transparency.

• Comments are not for extended discussion; this conversation has been moved to chat. – Mr.Wizard Mar 11 '16 at 20:46
• My guess: because people are honestly trying to help you solve your performance problem and you just argue in response. For example: you seem to think that depth buffering is very expensive. Depth buffering requires one extra comparison per pixel, so there is some cost. But that cost only depends on the number of pixels drawn. So if you simplify your geometry (by using fewer PlotPoints), and performance gets better, depth buffering isn't your problem. But when someone suggested that in a comment, you just shouted "no! Thats not what i want". It seems you dont want to accept help... – Niki Estner Mar 11 '16 at 22:27
• Yes @Cham, nobody understands what depth sorting is, not even Wikipedia. – Niki Estner Mar 12 '16 at 11:06
• @nikie, is there a way to turn off depth sorting for exportation ? – Cham Mar 12 '16 at 14:58
• @Cham: If there is, it's not documented. – Niki Estner Mar 12 '16 at 15:41

My QA provides a method to convert Graphics3D to a 2D projection in Graphics. Of course, there is no depth-sorting or z-buffering taking place in 2d graphics.

Using the wrapper function from the link:

Manipulate[
wrapper[Show[{curve1[t], curve2[t]},
PlotRange -> {{-1.5, 1.5}, {-1.5, 1.5}, {-1.5, 1.5}},
ImageSize -> 600], {-3, 3, 3}, {0, 0, 1}, {0, 0, 1}], {t, 1, 12}]


at high values of t the scene becomes very sluggish, much more so than just the Manipulate from edit 3 of OP. I think it can be concluded, that z-buffering gives a negligible performance hit. In fact, it is dwarfed by the computation time needed to project the lines onto a 2D plane using my top-level implementation.

My wrapper function does, however, prevent the issue mentioned in edit 2: Lines exported from Graphics are not depth-sorted and come out as single, grouped elements.

The answer to this question is

OP's assumption is wrong. z-buffering does not noticeably affect performance