Getting 3D graphs to look nice in Mathematica 6
Gavin Scott
nice with anti-aliased drawing, I had been unimpressed with the
3D quality both in my own use and as shown in the "What's new in
6" web seminar. Specifically the fact that no anti-aliasing appears
to be done and the edges of surfaces and axis lines and lables are
quite "jaggy".
Well, it turns out that you can probably fix this. Mathematica
appears to be using the 3D capabilities of your video card and the
card's own quality settings to do all the 3D rendering. I was
able to bring up the NVIDIA configuration program and add a set
of override settings for Mahtematica.exe and told it to turn all
the anti-aliasing and similar options up to their highest level.
Now I get smoothly rendered 3D surfaces and lines! In addition
when I save a notebook the saved copy of images take advantage
of the high quality so when someone opens the notebook the images
will look smooth (at least until they start to rotate or otherwise
recompute them) even if they don't have AA turned on.
There's a slight reduction in interaction speed when rotating 3D
images, but most Mathematica 3D graphs seem relatively simple in
terms of polygon count (compared to a modern 3D game say) and the
performance change isn't very noticeable (also you can adjust the
quality settings to choose the level of performance you want).
G.
Nasser Abbasi
"Gavin Scott" <ga...@allegro.com> wrote in message
news:1341rpm...@news.supernews.com...
> While most 2D graphics output from Mathematica 6 now looks pretty
> nice with anti-aliased drawing,
One of the most important things for me, which existed in Matlab for years
seems to be still missing in 2D plots in Mathematica, which is the following
simple task:
The ability to select a region on the plot using the mouse and zoom into
that area.
This is VERY important. Many times one wants to examine a small area on the
plot in more details, instead of having to mug up again with the command
used to make the original plot, and change some parameters and make a new
plot which shows in more details the region of interest, in Matlab one
simply uses the mouse to zoom in, then zoom out again when done.
I am amazed such an important feature is still missing in Mathematica after
all these years.
Another problem I noticed with 2D. Make a plot, say
Plot[Sin[x], {x, -Pi, Pi}]
Now select it, and pick up the a corner edge and shrink down the plot to
make it smaller and smaller.
Noticed something? the tick numbers on the axis do not shrink !, they remain
in large fonts. This means not everything in the plot shrinks in same
proportions.
Other than that, yes 2D plots now look smoother than before.
Nasser
Jon McLoone
> seems to be still missing in 2D plots in Mathematica, which is the following
> simple task:
>
> The ability to select a region on the plot using the mouse and zoom into
> that area.
>
> This is VERY important. Many times one wants to examine a small area on the
> plot in more details, instead of having to mug up again with the command
> used to make the original plot, and change some parameters and make a new
> plot which shows in more details the region of interest, in Matlab one
> simply uses the mouse to zoom in, then zoom out again when done.
There are lots of possible interface designs for graphics that you can
now implement relatively easily yourself. Here is a simplified version
of what you are requesting...
ClickZoomShow[gr_Graphics] :=
DynamicModule[{pr = PlotRange /. Options[gr, PlotRange]},
Dynamic[EventHandler[
Show[gr,
PlotRange -> pr],
{"MouseClicked" :> (pr = {(pr[[1]] +
MousePosition["Graphics"][[1]])/2,
(pr[[2]] +
MousePosition["Graphics"][[2]])/2})
}]]]
Use it like this...
ClickZoomShow[Plot[Sin[1/x] x, {x, -1, 1}]]
Now each click on the graphic will zoom towards that point.
You could adapt this to a better version by regenerating the plot each
time, as zooming does not produce any more detail, only lets you look
closer. This would be even more important in Matlab which does not
have adaptive plot sampling like Mathematica, so unless you have
chosen a very high sample rate at the start you would quickly run out
of detail.
Jon Harrop
> ClickZoomShow[gr_Graphics] :=
> DynamicModule[{pr = PlotRange /. Options[gr, PlotRange]},
> Dynamic[EventHandler[
> Show[gr,
> PlotRange -> pr],
> {"MouseClicked" :> (pr = {(pr[[1]] +
> MousePosition["Graphics"][[1]])/2,
> (pr[[2]] +
> MousePosition["Graphics"][[2]])/2})
> }]]]
>
Wow. I can't believe you can't zoom in to a 2D plot in Mathematica to see
the detail. You guys should really put that into 6.1.
We're working on a graphical library for the F# language from Microsoft:
http://www.ffconsultancy.com/products/fsharp_for_visualization/
I'll make sure that functionality goes in...
--
Dr Jon D Harrop, Flying Frog Consultancy
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?usenet
Jon McLoone
The approach of regenerating the function to increase detail is
potentially problematic as a standard behaviour unless your are only
visualizing elementary functions. Most examples of this feature that I
have seen have been in "graphing calculator" software.
If the function was dependant on some data set that has changed, or
was the result of a random process, or a record of a specific system
state at the time, it is not clear whether you want the function as it
was then or as it would be now? Getting more detail might, in some
cases, require re-running the process. What do you do if it is
expensive to calculate? What if the person holding the document with
the plot does not have access to the code that created it?
The typical set of assumptions might well deal with most cases but
will always render other valid cases inaccessible, so being able to
choose the kind of interaction you want rather than have it is imposed
is still important -- if it is easy to do.
Here is the simplest set of assumptions: zoom to the origin,
recalculating the function from scratch...
Manipulate[Plot[Sin[1/x] x, {x, -1/n, 1/n}], {n, 1, 100}]
Jon Harrop
> If the function was dependant on some data set that has changed, or
> was the result of a random process, or a record of a specific system
> state at the time, it is not clear whether you want the function as it
> was then or as it would be now?
The evaluation semantics for Mathematica's Plot function are undefined. So
the user is already at fault if they provided an impure function to be
plotted.
> Getting more detail might, in some cases, require re-running the process.
Yes.
> What do you do if it is expensive to calculate?
The same thing you do every other time: make the user wait. If you're really
interested in performance, put a high-performance compiler into
Mathematica.
> What if the person holding the document with
> the plot does not have access to the code that created it?
This is the primary advantage of using a rewrite system like Mathematica:
you can re-evaluate an expression using different semantics (e.g.
precision). Competitors (e.g. me) can't do this because they're using
statically-resolved compiled languages, so I'd expect this to be leveraged
as much as possible by WRI.
> The typical set of assumptions might well deal with most cases but
> will always render other valid cases inaccessible, so being able to
> choose the kind of interaction you want rather than have it is imposed
> is still important -- if it is easy to do.
Worst case, the zoomed version will be different (random data) or will take
about the same time to plot as the original. Either way, the user only
suffers if they choose to zoom and the plot was only wrong if the user made
a mistake.
D Herring
> Jon McLoone wrote:
>> If the function was dependant on some data set that has changed, or
>> was the result of a random process, or a record of a specific system
>> state at the time, it is not clear whether you want the function as it
>> was then or as it would be now?
>
> The evaluation semantics for Mathematica's Plot function are undefined. So
> the user is already at fault if they provided an impure function to be
> plotted.
RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html
In particular read up on Options->{PlotPoints, MaxRecursion,
MeshFunctions}. These are not new to version 6.
The rest of your points have similar counterpoints.
Please quit marketing your F- "language" on usenet. For many of us,
your continued off-topic hype is causing negative impressions.
-DH
Jon Harrop
> Jon Harrop wrote:
>> Jon McLoone wrote:
>>> If the function was dependant on some data set that has changed, or
>>> was the result of a random process, or a record of a specific system
>>> state at the time, it is not clear whether you want the function as it
>>> was then or as it would be now?
>>
>> The evaluation semantics for Mathematica's Plot function are undefined.
>> So the user is already at fault if they provided an impure function to be
>> plotted.
>
> RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html
> In particular read up on Options->{PlotPoints, MaxRecursion,
> MeshFunctions}. These are not new to version 6.
I cannot see any definition of the evaluation semantics (the order of
evaluation).
SzH
> D Herring wrote:
> > Jon Harrop wrote:
> >> Jon McLoone wrote:
> >>> If the function was dependant on some data set that has changed, or
> >>> was the result of a random process, or a record of a specific system
> >>> state at the time, it is not clear whether you want the function as it
> >>> was then or as it would be now?
>
> >> The evaluation semantics for Mathematica's Plot function are undefined.
> >> So the user is already at fault if they provided an impure function to be
> >> plotted.
>
> > RTFM:http://reference.wolfram.com/mathematica/ref/Plot.html
> > In particular read up on Options->{PlotPoints, MaxRecursion,
> > MeshFunctions}. These are not new to version 6.
>
> I cannot see any definition of the evaluation semantics (the order of
> evaluation).
What do you mean by the "order of evaluation"? Plot[] takes one
function to be evaluated several times.
SzH
Oh, I see. Your probably mean that for x1 < x2 it is not guaranteed
that that f[x1] is evaluated before f[x2] when Plot[]-ting f. In v5.2
you can ensure that f is evaluated with predictable arguments by using
PlotDivision -> 1.
Jon Harrop
> Oh, I see. Your probably mean that for x1 < x2 it is not guaranteed
> that that f[x1] is evaluated before f[x2] when Plot[]-ting f.
Exactly, yes.
> In v5.2
> you can ensure that f is evaluated with predictable arguments by using
> PlotDivision -> 1.
You mean it happens to work in 5.2 but, without a formal definition of the
evaluation semantics, there is no guarantee that it will continue to work
in that way in the future. So it would be a bad idea to write code that
relied upon it.
There is nothing wrong with leaving things undefined like this. In this
case, it allows WRI to implement better adaptive plotting algorithms in the
future.
My objection is simply that Jon McLoone was essentially saying that
already-broken code would break if they added zooming.
I don't think there is anything contentious here and I was surprised to see
DH give such a rude response...
D Herring
> D Herring wrote:
>> Jon Harrop wrote:
>>> Jon McLoone wrote:
>>>> If the function was dependant on some data set that has changed, or
>>>> was the result of a random process, or a record of a specific system
>>>> state at the time, it is not clear whether you want the function as it
>>>> was then or as it would be now?
>>> The evaluation semantics for Mathematica's Plot function are undefined.
>>> So the user is already at fault if they provided an impure function to be
>>> plotted.
>> RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html
>> In particular read up on Options->{PlotPoints, MaxRecursion,
>> MeshFunctions}. These are not new to version 6.
>
> I cannot see any definition of the evaluation semantics (the order of
> evaluation).
Ahh. For that you probably want ListPlot.
http://reference.wolfram.com/mathematica/ref/ListPlot.html
ListPlot is the moral equivalent of Matlab's plot command; the user has
complete control over how the lists are filled.
Another solution is to construct an InterpolatingFunction from the
original data and pass that to Plot.
http://reference.wolfram.com/mathematica/ref/InterpolatingFunction.html
- DH
P.S. Rude? My previous reply was overly harsh... but you do have a
tendency to post factual errors with an authoritative tone and then
segue into how your system fixes such problems.
Jon McLoone
> My objection is simply that Jon McLoone was essentially saying that
> already-broken code would break if they added zooming.
Not a fair summary of my comments.
I provided a zooming function (although I overlooked that you can
already do this in Mathematica by holding the ctrl key, dragging the
graphic frame to the region of interest, releasing the ctrl key, and
dragging the frame back again). And indicated that it would be easy
enough to do a version that re-called the function.
My comments were that automatically re-calling the original generator
code, however large, slow, non-deterministic, proprietary or absent it
might be, is not necessarily something that you want to happen
automatically every time and it might be wiser if the plot creator
made a decision about whether this is the behaviour they want to
provide to the consumer of their plot.
Jon Harrop
>> My objection is simply that Jon McLoone was essentially saying that
>> already-broken code would break if they added zooming.
>
> Not a fair summary of my comments.
Then I misunderstood
> My comments were that automatically re-calling the original generator
> code, however large, slow, non-deterministic, proprietary or absent it
> might be, is not necessarily something that you want to happen
> automatically every time and it might be wiser if the plot creator
> made a decision about whether this is the behaviour they want to
> provide to the consumer of their plot.
I think that would be fine for a default behaviour. Especially considering
users can precompute an interpolating function so easily in Mathematica.