[Date Index]
[Thread Index]
[Author Index]
Re: Re: Mathematica Graphics - speed bottleneck
*To*: mathgroup at smc.vnet.net
*Subject*: [mg97737] Re: [mg97711] Re: [mg97664] Mathematica Graphics - speed bottleneck
*From*: "David Park" <djmpark at comcast.net>
*Date*: Fri, 20 Mar 2009 02:39:14 -0500 (EST)
*References*: <13486459.1237450560451.JavaMail.root@m02>
It would be very nice if the Help page for Graphics3D gave a more complete
listing, and a few examples, of the various Methods that can be used. The
current statement is limited to:
" Settings that can be given through the Method option include
"SpherePoints" and "CylinderPoints"." with no indication of what these might
mean - although one might guess.
And in general, the String options need better documentation at the point
where they are used. Or the Method page could have sections for each of the
major commands giving the allowed options, just like the ColorFunction page
gives argument usage for each of the plot types.
David Park
djmpark at comcast.net
http://home.comcast.net/~djmpark/
From: John Fultz [mailto:jfultz at wolfram.com]
On Wed, 18 Mar 2009 04:54:02 -0500 (EST), robert prince-wright wrote:
>
>
> Mathematica 7. has lured me back into using Mathematica at work and I am
> wondering if it really has reached a point where it can be used to deploy
> applications / solutions. I had some success with one small application
> but found the graphics became a bottleneck which slowed to a grinding
> halt when applied to a real problem. Key culprits were the vector field
> plotting functions, and Graphics3D's ability to manipulate objects
> comprising hundreds of tubes. It was fine for tens but not hundreds. This
> led me to wonder if there are alternative approaches. I recall
> LiveGraphics3D but it seems to have stopped at v5. Basically I want to
> manipulate 3D graphics through use of DynamicModule, Sliders, etc. and
> see the changes in realtime (as opposed to geological time!)
>
> Any thoughts?
Not having seen your problem, I can't make any authoritative comment on
what's
causing your performance problems. If your examples are purely about
manipulation of graphics primitives and spend lots of time in the graphics
rendering pipelines, then there's probably not much that can be done without
improvements to the front end or off-loading the rendering to another app.
But you mention plotting vector fields as an example of something that's
slow.
This isn't just about the rendering pipelines. There's a large amount of
computation that's going on here, too. Finding another rendering platform
wouldn't help if, in your case, the time sink is in computing the primitives
to
be displayed rather than actually displaying them.
So I wouldn't jump to any conclusions like "manipulating 3D graphics is
slow"
without first quantifying where the actual time is being spent.
I will make a few quick remarks about graphics performance, though. In
general,
when dealing with large numbers of objects, things will be much more
efficient
if you use multi-primitives rather than many individual primitives.
Primitives
like Tube[], Point[], Line[], etc., all support forms where you can specify
a
collection of primitives by passing in a list of coordinate lists. E.g.,
randompoint := {RandomReal[], RandomReal[], RandomReal[]};
Graphics3D[Tube[Table[{randompoint, randompoint}, {50}]]]
Secondly, 3D graphics with any transparency at all are always going to
render
far more slowly than 3D graphics without transparency. The overhead for
sorting
polygons is much higher when you take into account that you can actually see
through some of them.
Finally, Graphics3D supports the Method options "SpherePoints",
"ConePoints",
"CylinderPoints", and "TubePoints" which can specify the number of points
used
to render each kind of primitive in the entire scene. Providing a very
small
number can make a big performance difference with virtually no visual
difference
if the primitives are tiny or thin in your graphic. E.g.,
randompoint := {RandomReal[], RandomReal[], RandomReal[]};
Graphics3D[Tube[Table[{randompoint, randompoint}, {500}]],
Method -> {"TubePoints" -> 6}]
which rotates quite noticeably faster than if you omit the Method option.
In the help viewer type
=09tutorial/ThreeDimensionalGraphicsPrimitives
to see documentation which discusses multi-primitives and the Method
options.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
Prev by Date:
**Re: demonstrations and presentations**
Next by Date:
**Re: Incompatible units?**
Previous by thread:
**Re: Mathematica Graphics - speed bottleneck**
Next by thread:
**Re: Mathematica Graphics - speed bottleneck**
| |