-4
$\begingroup$

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.

Improve this question
$\endgroup$
28
  • 3
    $\begingroup$ So, um, what is "depth sorting"? $\endgroup$ Commented Mar 11, 2016 at 15:46
  • 4
    $\begingroup$ @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) $\endgroup$ Commented Mar 11, 2016 at 16:14
  • 5
    $\begingroup$ 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? $\endgroup$ Commented Mar 11, 2016 at 21:55
  • 2
    $\begingroup$ 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. $\endgroup$ Commented Mar 12, 2016 at 11:55
  • 5
    $\begingroup$ @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. $\endgroup$ Commented Mar 12, 2016 at 12:32

2 Answers 2

Reset to default
9
$\begingroup$

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]

enter image description here

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.

Improve this answer
$\endgroup$
16
  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ Commented Mar 11, 2016 at 20:46
  • 2
    $\begingroup$ 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... $\endgroup$ Commented Mar 11, 2016 at 22:27
  • 2
    $\begingroup$ Yes @Cham, nobody understands what depth sorting is, not even Wikipedia. $\endgroup$ Commented Mar 12, 2016 at 11:06
  • 1
    $\begingroup$ @nikie, is there a way to turn off depth sorting for exportation ? $\endgroup$ Commented Mar 12, 2016 at 14:58
  • 1
    $\begingroup$ @Cham: If there is, it's not documented. $\endgroup$ Commented Mar 12, 2016 at 15:41
3
$\begingroup$

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

Improve this answer
$\endgroup$

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.