Message Boards Message Boards

2
|
3171 Views
|
3 Replies
|
3 Total Likes
View groups...
Share
Share this post:

How to display tubes more efficiently in 13.2?

To render outputs of some of the methods I use i need display large amounts of Lines and Tubes. This had some issues before but are now all fixed (here, here, and here). In my application I can easily generate 0.5M tracts and subsample them for display. For the type of images I need between 5k and 10k Lines or Tubes to be drawn. Other considerations are:

  • The tract coordinates are isotropic and different from the display coordinates
  • The display coordinates are anisotropic (but i want the tubes to be round ->Scale)
  • Tracts are colored for their local orientation
  • Each tract can have a different length but a fixed step size

With 13.2 Generating some tracts with color and defining the Graphics primitives goes very fast and is very straight forward.

When you ask for display the troubles start. As far as i can see the frontend (but not the kernel) is doing some very big computations since CPU is at 50% for most of the wait time. The copying to the GPU is almost instant and once in GPU memory its smooth sailing.

For Lines this generally no problem and displaying 10k lines takes around 5-6s ( both on mac and windows) to display. Once on screen the GPU takes over and rotation is very smooth. For Tubes, 1k is OKish, however drawing only 2k can take up to 60s and if I increase to 4k waiting times are between 90 to 120s. But more annoying drawing can the also cause the frontend to crash (1 out of 4 times, see image) and in some cases even crash my display divers. Again once displayed (if successful) all is very smooth.

I have attached a notebook with some code. I'm curious if anyone can reproduce my problems and more important if anyone has some ideas about making displaying tubes more workable.

enter image description here enter image description here enter image description here

POSTED BY: Martijn Froeling
3 Replies

But it should be difficult to create that many tubes, no? Each tube is made of cylinder segments, which in turn are made of triangles, with texture and other attributes. And you have thousands of tubes. It is bound to take a ton of memory and time to generate them, way more than lines (which are not really 3D objects at all).

As you say, once you push the result onto a high-powered graphics cards it will be fine, because the hard work is done.

POSTED BY: Gareth Russell

Yes i agree, it should be hard, but not minutes. That's why i reduce the render quality considerably compared to default values. I don't mind waiting a bit, but the time for me does not scales linearly with the number of tube points. And the frontend crashes way before I run out of memory.

POSTED BY: Martijn Froeling

When I had similar graphics but quite different data problems, I made a work flow: construct and manipulate Graphics objects and Show them together, in my case with resized external photos, in Mathematica.

Each unit I exported as scalable PDF and 'placed' the pdfs in different layers into Adobe Ilustrator where they can be placed, resized and bound together to subunits.

Illustrator seems to be a reliabe basis for grouping, implanting, text writing, making projections to parts and layers and, printing what is seen on the screen, and never complains about too liitle memory. By the time used, the print process takes to translate a vector graphics into printer lines, one may get an impression, why an interpreting language cannot do such things.

Later trying import of the results to InkScape are of no use.

I tried your example, it simply does not work with tubes by time and memory.

POSTED BY: Roland Franzius
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard

Group Abstract Group Abstract