How to turn off depth sorting of 3D curves for Manipulate?

Question

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.

Answer 1

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.

Answer 2

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