Is Export limitated by screen resolution?
- To: mathgroup at smc.vnet.net
- Subject: [mg121159] Is Export limitated by screen resolution?
- From: "Alexey Popkov" <lehin.p at gmail.com>
- Date: Thu, 1 Sep 2011 06:03:28 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <201183015021.387235@jfultz3winlap>
John,
Thank you for the options "TubePoints" and "SpherePoints". Probably
"TubePoints" does not affect rendering when
MeshStyle -> {{GrayLevel[.7], Tube[0.01]}}
because FullForm shows that Mesh is formed by Polygons in this case, not
Tubes. So I have come to the following hack:
pl = ContourPlot3D[< ... >, PlotPoints -> 40,
MeshStyle -> Directive[GrayLevel[.7]],
Method -> {"TubePoints" -> {1, 1}, "SpherePoints" -> 15}];
pl = pl /. {Directive[GrayLevel[0.7`]], b : _Line ..} :>
{Glow[GrayLevel[.7]], Black, JoinForm["Bevel"],
Tube[List @@ Join[b],
0.0015]};
After adding the 200 spheres an attempt to display this inside of the
FrontEnd leads to crash, but Export works if the following set of conditions
is fulfilled:
1) It is fresh FrontEnd session
2) Notebook contains no 3D graphics
3) It is first attempt to Export anything (an attempt to Export the same
graphics again leads to crash).
When trying to Export the final graphics with high resolution I discovered
obvious interrelation between crashes and screen resolution. For example,
when working with screen resolution 1680x1050 (the highest possible on my
laptop) Mathematica generally allows to Export the graphics with ImageSize
up to 1680 with the following specifics:
1) When ImageSize is set to more than 1651 the FrontEnd sometimes (randomly)
crashes after successfull export and sometimes cannot export at all even
when the above conditions are fullfilled. Another trial with the same values
may give success.
2) ImageSize equal to 1651 never leads to crash when the above conditions
are fullfilled.
3) ImageSize more than 1680 always crashes FrontEnd.
4) Strangely enough that setting ImageSize to 1555 or 1600 always crashes it
too.
Every of the above points is a result of not less than 4 runs of the same
code in fresh FrontEnd sessions. Note that 1652 is the width of the white
area inside of a Notebook window when this window is maximized. Also note
that when I try to export Magnified version of the graphics with high
magnification (for example, 8) the exported image is always of width 1651
when screen resolution is 1680x1050 and is of width 1251 when I set screen
resolution to 1280x768 (on the same laptop).
An attempt to Export the graphics with ImageSize more than 1555 when screen
resolution is 1280x768 always leads to crash (ImageSize 1555 never leads to
crash). Switching back to resolution 1680x1050 restores original behavior
(crash when ImageSize is from the 1500 to the 1600 inclusive). Checked
values of ImageSize for both resolutions: 1200, 1251, 1280, 1300, 1400,
1550, 1555, 1556, 1557, 1560, 1570, 1590, 1600, 1651.
To summarize:
1) Crashes strongly depend on screen resolution, this behavior is
well-reproducible.
2) When screen resolution is 1680x1050 Mathematica is always able to Export
graphics with ImageSize 1651 without crashes (in fresh session) but always
cannot to Export it with ImageSize from the 1500 to the 1600 inclusive and
with ImageSize more than 1680.
3) When screen resolution is 1280x768 Mathematica is always able to Export
graphics with ImageSize 1555 without crashes (in fresh session) but always
cannot to Export it with ImageSize more than 1555.
How can this be explained? Is there a way to Export graphics with ImageSize
more than maximum screen resolution?
Many thanks in advance,
Alexey
P.S. My system: Lenovo R500 laptop with 32bit Windows XP SP3 installed.
Screen magnification in operating system is set to 120 dpi. I use
Mathematica 7.0.1.
----- Original Message -----
From: "John Fultz" <jfultz at wolfram.com>
To: <lehin.p at gmail.com>; <mathgroup at smc.vnet.net>
Sent: Wednesday, August 31, 2011 12:00 AM
Subject: [mg121159] Re: Defective Mesh lines in ContourPlot3D
I forgot to mention that you could reduce the number of polygons in the
tubes,
too.
Graphics3D[{Tube[{{0, 0, 0}, {1, 1, 1}}, .25]},
Method -> {"TubePoints" -> {3, 2}}]
Adding both "TubePoints" and "SpherePoints" would, I imagine, make the
result
considerably more manageable. Furthermore, I don't know how you're adding
the
Sphere[]s, but I strongly recommend that you use multi-Sphere[]s. I.e.,
(* not this *) {Sphere[p1, r], Sphere[p2, r], ...}
(* but this *) Sphere[{p1, p2, ...}, r]
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
On Tue, 30 Aug 2011 09:37:00 -0500, John Fultz wrote:
> As I said, the BSPTree method involves a massive amount of subdivision of
> the polygons. Yes, when you add a lot more, the memory usage is going to
> explode. Although you could, at least, reduce the number of new polygons
> being used in this case using the "SpherePoints" method option...
>
> Graphics3D[Sphere[], Method -> {"SpherePoints" -> 5}]
>
> That example, of course, looks horrible, but if your Sphere[]s are
> effectively
> points, nobody will ever notice.
>
> Upgrading to v8 is, of course, an option as well. The DepthPeeling
> method is
> superior for most transparent renderings, and definitely for the example
> you
> included here.
>
> Sincerely,
>
> John Fultz
> jfultz at wolfram.com
> User Interface Group
> Wolfram Research, Inc.
>
> On Tue, 30 Aug 2011 10:30:41 +0400, Alexey Popkov wrote:
>> John,
>>
>> The option
>>
>> MeshStyle -> {{GrayLevel[.7], Tube[0.01]}}
>>
>> solves the problem with overlapped Mesh lines. Now another problem:
>> FrontEnd crashes when I add a set of 200 little non-tranparent spheres
>> to
>> the plot. I am forced to use Spheres instead of Points primarily because
>> Points are not scaled with distance in 3D. It seems that the crash
>> happens because the number of 3D-objects becomes large when Mesh is also
>> rendered as 3D. Crash also happens when I increase PlotPoints option:
>>
>> ContourPlot3D[
>> x^4 + y^4 + z^4 - (x^2 + y^2 + z^2)^2 + 3 (x^2 + y^2 + z^2) ==
>> 3, {x, -2, 2}, {y, -2, 2}, {z, -2, 2},
>> BoundaryStyle -> Directive[Black, Thickness[.003]],
>> ContourStyle ->
>> Directive[Orange, Opacity[0.5], Specularity[White, 300]],
>> Ticks -> None, PlotPoints -> 60,
>> MeshStyle -> {{Glow[GrayLevel[.7]], Black, Tube[0.005]}},
>> Lighting -> {{"Directional",
>> RGBColor[1, 1, 1], {ImageScaled@{1, 0, 1},
>> ImageScaled@{0, 0, 0}}}}]
>>
>> Is there any workaround for this (I need semi-transparent surface)?
>>
>> (I use Lenove R500 laptop with 32bit Windows XP SP3 installed and
>> Mathematica 7.0.1.)
>>
>> Thank you for your help,
>> Alexey
>>
>>
>> ----- Original Message -----
>> From: "John Fultz" <jfultz at wolfram.com>
>> To: <lehin.p at gmail.com> <mathgroup at smc.vnet.net>
>> Sent: Tuesday, August 30, 2011 12:14 AM
>> Subject: Re: Defective Mesh lines in ContourPlot3D
>>
>>
>> Version 8 has three rendering methods, controlled by the
>> RenderingOptions->{"Graphics3DRenderingEngine"} option:
>>
>> DepthBuffer
>> Advantage - very fast
>> Disadvantage - absolutely unusable with transparency
>>
>> BSPTree
>> Advantage - renders everything
>> Disadvantage - divvies up the polygons into a bazillion sub-polygons,
>> which
>> are
>> reordered during rotation. Most of this happens in the CPU, not the
>> GPU.
>> By
>> far, the slowest rendering method.
>>
>> DepthPeeling
>> Advantage - renders most transparency fine, uses GPU hardware.
>> Disadvantage - some older video cards don't support it, a few (but rare)
>> outlying transparent cases don't work well.
>>
>> V7 only had the first two options. What you're seeing is a complication
>> stemming from the facts that:
>>
>> * There's a great deal of polygonal subdividision
>> * The mesh is also highly subdivided
>> * The mesh and the polygons are nearly (or sometimes exactly) coplanar
>> polygons
>>
>> In v7, there are two ways out of this. One is to prevent the BSPTree
>> method from being used by removing the transparency from the graphic.
>> The second is to prevent the coplanarity by changing how the mesh is
>> rendered. There's an undocumented usage of the MeshStyle option which
>> would do this:
>>
>> MeshStyle -> {{GrayLevel[.7], Tube[0.01]}}
>>
>> In v8, the DepthPeeling method does a vastly better job with the
>> transparent version of the graphic. And, if your hardware supports it,
>> DepthPeeling is what Mathematica will use by default.
>>
>> Sincerely,
>>
>> John Fultz
>> jfultz at wolfram.com
>> User Interface Group
>> Wolfram Research, Inc.
>>
>>
>> On Mon, 29 Aug 2011 03:46:57 -0400 (EDT), Alexey Popkov wrote:
>>> Hello,
>>>
>>> I have a problem with rendering of Mesh lines on a 3D surface produced
>>> by
>>> ContourPlot3D in Mathematica 7.0.1:
>>>
>>> p=ContourPlot3D[x^4+y^4+z^4-(x^2+y^2+z^2)^2+3(x^2+y^2+z^2)==3,
>>> {x, -2,2}, {y, -2, 2}, {z,-2,2},
>>> BoundaryStyle->Directive[Black,Thickness[.003]],
>>> ContourStyle->Directive[Orange,Opacity[0.5],Specularity[White,300]],
>>> PlotPoints->90,Ticks->None,
>>> MeshStyle->Directive[GrayLevel[.7],Thickness[.001]],
>>> Lighting->{{"Directional",RGBColor[1,1,1],
>>> {ImageScaled@{1,0,1},ImageScaled@{0,0,0}}}}];
>>> p=Graphics[Inset[p,{0,0},Center,{1,1}],
>>> PlotRange->{{-.5,.5},{-.5,.5}},Frame->True]
>>>
>>> (see screenshot here: http://i.stack.imgur.com/zBtYC.png )
>>>
>>> Let us to look closer on Mesh lines:
>>>
>>> Show[p, PlotRange -> {{-.16, -.05}, {0, .1}}]
>>>
>>> (see screenshot here: http://i.stack.imgur.com/JBkcc.png )
>>>
>>> You can see that gray Mesh lines are overlapped by surface-forming
>>> triangles in many places and even look dashed. Is there a way to avoid
>>> this?
