gnuplot-beta — Developers and beta testers of new gnuplot code

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> On Monday 15 January 2007 00:01, Daniel J Sebald wrote:
> 
>>Anything wrong with the following approach?
> 
> 
> Please go back and read the 2005 discussion.

In 1077726 patch?  I read it.


> As I understood the argument, the whole point of the "pm3d hidden3d" option
> was the cleverness of doing the border tracing at the same time as the pm3d
> fill. This gives you the [admittedly imperfect] hidden-surface removal
> essentialy for free.

Well, it really isn't hidden3d.  I'd prefer the name "tileline" or something like that.  And then use the name "hidden3d" to mean exactly what appears in the documentation.


> Yes, you could do a better job on the lines by handling them in the true
> hidden3d code instead (I had a patch to do that, but I cannot recall if I
> circulated it).  But it's much slower.

Actually, I'm not sure it is much slower.  As implemented right now, hidden line removal on Kuen is pretty fast, whereas the pm3d variant is noticably slower.  Granted, one may have an order complexity greater than the other for increasing N.  Something about pm3d is slow right now.

Even still, a nice, correct plot for the user is the end goal.  If they want to use a mode (say "depthorder" plus "tileline") for a quick rough idea, and then generate a correct, but slow plot (i.e., "hidden3d" turned on) for publication or presentation, that would be very nice.

What you suggest is the correct approach to take and road to follow.  Hidden 3D has it's level of complexity:  surface element covering point (fairly easy), surface element covering line (difficult), surface covering surface (very difficult).  But the mathematical constructs between methods are related I would think.  I suspect good estimates would result from augmenting line removal.  That is, as one goes along and makes decisions about surfaces in conjunction with line removal there is more info available than the current depth order scheme.  Relationship to neighboring elements is information that can be used whereas if all you have are list of surface elements and faced with the problem of correctly ordering them options are limited.

I would probably take an object oriented approach.  Ultimately one would like a list of points, lines and surfaces intermingled in the proper plotting order.  Also, tag each element as hidden or not.  (In the case of lines, I think hidden3d breaks them up, so there is no idea of a "partially hidden" line.  In the case of surfaces, "hidden" would not include the class of partially hidden.  I don't think we want to go to the complexity of breaking up surfaces.  It's consequences are minimal for the same reason depth ordering works OK.)  That way, one can toss out hidden lines for the effect as seen in so many demos.  Or the hidden lines can be retained for the purposes of the transparent solids feature.

>  Given the difference in speed, and
> the fact that the pm3d rectangles themselves still cannot be ordered
> perfectly, it was judged a net loss rather than a gain.

Had I been paying more attention at the time, I probably would have argued that slowness isn't an issue.  Again, having both options fast/guesstimate and slow/estimate is fine in my opinion so long as it is made clear to the user what the distinction is.


 It doesn't do
> much good to get the bounding line occlusions right if the rectangles
> themselves stick out where they shouldn't.

This Kuen example is one where colors of incorrect ordered quadrangles is so close to the ones it is interchanged with that it would hardly be noticable.  If the colors of the quadrangles were that drastically different, then they probably would not have been mis-ordered.

> 
> On the other hand, I was disappointed at the time that we didn't pursue 
> the complementary option of allowing inclusion of pm3d rectangles in the
> true "set hidden3d" code path.  For all the reasons that Hans-Bernhard
> enumerated, rectangle-rectangle occlusions still would not be handled
> correctly in the general case.  Certainly it is not going to help the
> Kuen's surface rendering much.

Actually, I think it might.  The first example of Kuen I sent showed an improvment when I used a "surface cover point" approach; still some flaws.  But "surface cover line" is more robust in terms of correctly estimating overlap.  And the second example of Kuen I sent showed that in fact appears to have corrected the flaws that still remained in my "surface cover point" approach.  (Note the couple comments I made about hidden line removal in the previous post.)

Dan

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

My previous mail has come through as of yet.  Anyway, I've found that the depth sort approach works a little better (at least for the Kuen surface) when using the average depth of corners as opposed to the max z value.

Well, a few of those flawed surfaces at the thin parts of the Kuen surface still seem odd to me.  The quadrangle on the back side *at the edge* seems to be ahead of the quandrangle on the front side *at the edge*.  But these two quadrangles share a couple points; so what I find hard to believe, looking at the Kuen surface from other angles, is that the two other points for the quadrangles average out so that the back quadrangle is more ahead.

But hold on, this may be for naught.  I may have an easier fix for this given the situation.  Give me a bit...

Dan

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

I've gotten a little further with some ideas.  As far as uncertainty with implementing ideas and the potential for bugs in the code, I think I'm to the point where thoughts are beginning to gel.

I understand the issues that Hans has raised (and actually one he hasn't raise that I think is also a problem here, I'll come back to that).  However, I think this Kuen example is one function where a sequence of tiling exists that will produce the desired appearance.  The question is finding that sequence... and I will propose some further ideas later.

I've written a routine that can tell whether a surface element (e.g., kuen demo) covers a point.  That's not too difficult.  Break things into triangles and use simple linear algebra equations using hyperplanes, matrix inverse, etc.  I've put some numbers into the equations and printed them to screen and I'm fairly confident they are correct.

OK, so with a "quadrangle cover point" routine, it is possible to correct some errors due to the depth sorting approach.  That is, after the sort, sweep through the list and examine the corners of quadrangles.  Is there:

1) Any quadrangle with a corner hidden by a "lower" quandrangle?  If so, move that quadrangle down in the list.

2) Any quadrangle that does not cover the corners of a lower quandrangle?  If so, move that quadrangle down in the list.

(Note, the above sweep is done by rearranging points only after all tests are complete.  Doing so before the sweep is complete would only lead to other problems I think.)

Barring any bugs (it's a painstaking use of pointers and such), the result is in the attached PNG.  The method does an OK job.  It cleans up a good deal of the tiling problems, but notice there are a few flaws remaining.  To search for the reason of these, I've fooled around with coloring the tiles that the code thinks should be moved downward.  Most of these flawed tiles you see are ones that the routine thinks should not be moved.

However, if I look at the flaws, there are some cases where a flawed corner lands inside a tile.  Those should be found by the routine.  (The ones that will pose a problem are those quandrangles that overlap yet no corner is inside the other quadrangle.)  So what is the issue?

Reasons for this might be:

1) Bug in the sorting approach.  (Let's say I'm 75% confident in what I've written.)

2) Issue with the map3d_xyz routine, or the manner in which it is used.  I assume people are confident with map3d_xyz.  However, one small issue (and I don't think it is the ultimate problem) is that pm3d code will call map3d_xyz and then cast the x and y values to integers.  That isn't exactly good if later your code depends on some computations involving relationships between x, y and z.  The z value is no longer the actual z value associated with x and y after x and y have been rounded to integers.  Probably only a slight discrepency in most cases.

3) Mutual cover, i.e., QA covers QB covers QC covers QA kind of problem.  Like I said, I don't think this Kuen function is an example of that.

4) *sample resolution*  could be an issue here.  And not in the manner of having to choose a greater sample resolution.  Let me try to explain with the Kuen example.  Notice that a lot of the tiles that are sticking through from the back to the front are big tiles.  Could it be that the curvature of the surface is such that a linear approximation interpolating points in the quad_covers_point() test fails?  That is, per my added test, the tiles that are flaws really do have corners that look to be on the other side of the surface (which also uses linear approximations)?

I suggest number 4 is likely an issue here.  Well, this requires more thought.  Anyway, let me propose a few things, because I think we'd like to be able to give the user the facility to generate a plot to their desires.

A)  Might we have more success by going to a more robust "quad_covers_line" approach as opposed to the quad_covers_point() approach for determining if an element should be moved down in depth (i.e., plotted sooner)?  This would mean that quadrangles overlapping quadrangles but neither has a corner landing inside the other quadrangle are addressed.  As I've shown, the hidden3d example of Kuen surface looks good.

B)  Can we introduce some heuristic options.  For example, one rule would be "the group of quadrangles for which all four corners are hidden are plotted first before the groups with at least one point visible".  Not the a good universal approach for sure, but as far as an option it could serve a purpose.

C)  Better interpolation than just linear?  Dodgy.  It is complicated because we have to keep track of neighboring quadrangles.  Also, it will really slow things down.

D)  A new feature perhaps, called "touchup".  Here me out :-).  Let's say the user can provide a list of x,y coordinates pertaining to the view.  These coordinates are problem areas where the pm3d routine should--after the depth order is done--go back and find the top-most element in the list corresponding to the (x,y) view coordinate and move it down in the depth order somehow.  Kind of of clunky, but generating the data might be made easier using the mouse.  I.e., user clicks on "bad tiles" and then types "replot".  (In 'transparent_solids.dem' the data would be known ahead of time.)

Dan


Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
> 
>>Daniel J Sebald wrote:
>>
>>
>>>Hans-Bernhard Bröker wrote:
>>>
>>>
>>>>Daniel J Sebald wrote:
>>
>>
>>>>>Hmm, might there be a slight alteration of this that would work
>>>>>"better"? 
>>
>>
>>>>No.  The whole idea of "depth sorting" is fundamentally flawed.  No 
>>>>slight alteration can make it work correctly.  The only real effect a 
>>>>slight alteration will have is to move the errors to a different 
>>>>region of parameter space, i.e. replace a known-bad guess by an 
>>>>unknown one.
>>>
>>>
>>>Depth sorting with something like qsort() is fundamentally flawed.  
>>
>>
>>No.  It's the "sorting" itself that is based on incorrect assumptions 
>>--- not the choice of sort algorithm or implementation.  The "covered 
>>by" relation is not an ordering.
>>
>>To get correct display, an algorithm has to go beyond sorting.  It has 
>>to be prepared to split some objects into smaller fragments to get a 
>>list that can be sorted.
>>
>>
>>>The assumption of equality is a problem in a sort like that.
>>
>>
>>Equality is not really a problem --- transitivity is.  For a set to be 
>>ordered by a relation '<', it has to be transitive, i.e. the condition
>>
>>    (a < b) and (b < c)  ==> a < c
>>
>>has to hold.  But doesn't hold for the relation "object obstructs (part 
>>of) other object from view)".
> 
> 
> Right.
> 
> 
> 
>>And worse yet, the ordering isn't local.  I.e. you can have two polygons 
>>A and B whose drawing order cannot be determined in any way looking at 
>>these two polygons alone (think of disjoint polygons in a plane parallel 
>>to the view plane).  Adding a third polygon, C, can cause them to have 
>>to be drawn either A before B, or B before A, depending on C.
> 
> 
> Those, for the time being, aren't a concern.  Two reasons.  They are rare (if those start occurring at too high a percentage in one's plot, s/he has not selected the sampling interval large enough or your function has some kind of singularity problem, e.g., 1/sin(x)).  The plotting of the quadrangle which doesn't have convex points is not unique, so you get what you get.
> 
> Barring that class of nasty quadrangles, one can sort but can't use the transitive property.  Hence, almost anything below O(N^2) algorithm is out for a good approximation.
> 
> 
> 
>>Painters' algorithm is a different problem from sorting.  Calling it 
>>"depth sorting" is ultimately a lie.  It's actually harder than sorting. 
>> For vector graphics output like gnuplot's terminal API it has a lower 
>>bound of O(N^2) output size, and thus O(N^2) time for N polygons, 
>>compared to sorting's O(N*log(N)).
> 
> 
> Well, gnuplot is doing depth sorting.  There may be a subtle difference I'm not aware of.
> 
> Dan
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


-- 

Dan Sebald
phone: 608 256 7718
email: daniel DOT sebald AT ieee DOT org
URL: http://webpages DOT charter DOT net/dsebald/

Re: universal binaries for Mac

[Ethan M. <merritt@u.washington.edu>]

On Friday 12 January 2007 11:36, Mojca Miklavec wrote:
> Hello,
> 
> There are no gnuplot binaries for 4.2 available yet (which would be
> helpful for users to test), 

There is a Windows binary for 4.2-rc1
	http://gnuplot.sourceforge.net/development/binaries/

But yes, it would be nice to offer a Mac binary as well.
I was planning to put our 4.2-rc3 this week.  Would you be able to
make a corresponding Mac binary for testing?  

I think that inclusion of the wxt terminal on native OSX
(e.g. not via X11) is still not worked out, but that's the only issue
I have seen discussed.  





> bet I guess that for Mac it would be 
> hepful to have universal binaries (to work both on PowerPc & Intel
> processor) and I don't think that gnuplot currently takes care about
> that.
> 
> Here are some notes:
> 
> http://developer.apple.com/technotes/tn2005/tn2137.html
> 
> Most importantly, this should be added:
> 
> CFLAGS
>     -arch i386 -arch ppc
> LDFLAGS
>     -arch i386 -arch ppc
> 
> ./configure ... --disable-dependency-tracking
> 
> The --disable-dependency-tracking option to configure causes it to not
> use gcc's built-in dependency generation code, which does not work
> with multiple -arch targets.
> 
> 
> Mojca
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: surface elements for transparent_solids.dem

[Ethan A M. <merritt@u.washington.edu>]

On Monday 15 January 2007 00:01, Daniel J Sebald wrote:
> Anything wrong with the following approach?

Please go back and read the 2005 discussion.

As I understood the argument, the whole point of the "pm3d hidden3d" option
was the cleverness of doing the border tracing at the same time as the pm3d
fill. This gives you the [admittedly imperfect] hidden-surface removal
essentialy for free.

Yes, you could do a better job on the lines by handling them in the true
hidden3d code instead (I had a patch to do that, but I cannot recall if I
circulated it).  But it's much slower.  Given the difference in speed, and
the fact that the pm3d rectangles themselves still cannot be ordered
perfectly, it was judged a net loss rather than a gain. It doesn't do
much good to get the bounding line occlusions right if the rectangles
themselves stick out where they shouldn't.

On the other hand, I was disappointed at the time that we didn't pursue 
the complementary option of allowing inclusion of pm3d rectangles in the
true "set hidden3d" code path.  For all the reasons that Hans-Bernhard
enumerated, rectangle-rectangle occlusions still would not be handled
correctly in the general case.  Certainly it is not going to help the
Kuen's surface rendering much.  *But*, there are some very useful special
cases that it _would_ handle correctly.  In particular I was interested
in painting false-color plots onto rectangular sections through a
3D vector field. In cases like this the issue of multiple rectangles with
mutual  occlusion simply doesn't arise; we only need to worry about
occlusion of vector segments by a rectangle, and vice versa.
Examples
	http://www.math.uni-bremen.de/~justen/Forschung/ie_condenser.jpg
	http://www.asd-online.com/piceng/cleanroom_simulation.gif



> As a prototype, I've moved the hidden3d line draw to after the pm3d is plotted in graph3d.c and changed the transparent_solids.dem command to: 
> 
> set pm3d
> splot x(u,v), y(u,v), z(u,v) with lines linecolor rgbcolor "black"
> 
> Remember, this is a prototype result.  The standard "set pm3d" version doesn't do depth sorting properly so you will see to the right that the colors don't properly follow the curve at middle height.
> 
> Some comments:
> 
> 1) Ramifications for transparency I'm not considering now, just that tiling problem from the previous email.
> 
> 2) Regarding the tiling problem, they are still there, but because the individual quadrangles weren't outlined these problems aren't too noticable.  The places where the depthorder sort fails happen for quadrangles that are pretty much the same value.  So, this isn't really a solution to the hidden surface issue, just a potential quick fix in some instances.
> 
> 3) I do see some flecks here and there in the hidden line draw.  Perhaps a bug in the line draw (e.g., rounding/precision issues)?  Hans?
> 
> 4) Also in the hidden line draw, note the difference between the attached PNG and the previous PNG.  There appear to be a couple lines missing from the Kuen surface on the left, pumpkin-colored surface where it curves inward vetically.
> 
> Dan
> 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

problem with 4.2rc2 and wxt_gui.cpp on Solaris

[Kostas O. <ko...@re...>]

Hello,

I just built 4.2rc2 on Solaris 10 using Sun's compilers (Sun 
Studio 11).  Everything seems to work, but when I press the 
"Configuration" button on the wxt terminal, I get a core dump.

This is what happens:

(<unknown>:9638): Gtk-CRITICAL **: file gtklabel.c: line 
2643: assertion `str != NULL' failed
(<unknown>:9638): Gtk-CRITICAL **: file gtklabel.c: line 
2643: assertion `str != NULL' failed
(<unknown>:9638): Gtk-CRITICAL **: file gtklabel.c: line 
2643: assertion `str != NULL' failed
(<unknown>:9638): Gtk-CRITICAL **: file gtkaccellabel.c: 
line 187: assertion `string != NULL' failed
(<unknown>:9638): Gtk-CRITICAL **: file gtkmisc.c: line 185: 
assertion `GTK_IS_MISC (misc)' failed
(<unknown>:9638): Gtk-CRITICAL **: file gtkcontainer.c: line 
946: assertion `GTK_IS_WIDGET (widget)' failed
(<unknown>:9638): Gtk-CRITICAL **: file gtkaccellabel.c: 
line 384: assertion `GTK_IS_ACCEL_LABEL (accel_label)' failed
Segmentation Fault (core dumped)


I found out that the first 3 messages are caused by

	wxCheckBox *check1 = new wxCheckBox ( ...)

in wxt_gui.cpp.  But I have no idea what to do to fix them. 
  I have wxwidgets 2.7.2.

Any help would be appreciated.

				Kostas

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Anything wrong with the following approach?  As a prototype, I've moved the hidden3d line draw to after the pm3d is plotted in graph3d.c and changed the transparent_solids.dem command to:

set pm3d
splot x(u,v), y(u,v), z(u,v) with lines linecolor rgbcolor "black"

Remember, this is a prototype result.  The standard "set pm3d" version doesn't do depth sorting properly so you will see to the right that the colors don't properly follow the curve at middle height.

Some comments:

1) Ramifications for transparency I'm not considering now, just that tiling problem from the previous email.

2) Regarding the tiling problem, they are still there, but because the individual quadrangles weren't outlined these problems aren't too noticable.  The places where the depthorder sort fails happen for quadrangles that are pretty much the same value.  So, this isn't really a solution to the hidden surface issue, just a potential quick fix in some instances.

3) I do see some flecks here and there in the hidden line draw.  Perhaps a bug in the line draw (e.g., rounding/precision issues)?  Hans?

4) Also in the hidden line draw, note the difference between the attached PNG and the previous PNG.  There appear to be a couple lines missing from the Kuen surface on the left, pumpkin-colored surface where it curves inward vetically.

Dan

Re: Last minute glitches - X11 font problem

[m s. <mw...@us...>]

> Message: 4
> Date: Fri, 12 Jan 2007 21:52:44 -0800
> From: Ethan A Merritt <merritt@u.washington.edu>
> Subject: Re: Last minute glitches - X11 font problem
> To: gnu...@li...
> Message-ID: <200701122152.44765.merritt@u.washington.edu>
> Content-Type: text/plain;  charset=3D"utf-8"
>=20
> On Friday 12 January 2007 17:04, Ethan Merritt wrote:
> >
> > The issue is what to do by default if no specific encoding has=20
> > been specified by the user.  The code currently fills the fields=20
> > in with
> > wild-cards:
> > 	-*-times-*-r-*-*-12-*-*-*-*-*-*-*
> >
> > This used to work, or at least I convinced myself at one time that it w=
as
> > working.  Now it doesn't.  Perhaps this is because I now have newer
> > versions of x11 (x.org); perhaps it is because I have a wider variety of
> > fonts installed, including multibyte fonts; perhaps it is because I am =
now
> > using a UTF-8 locale everywhere.  I don't know.
>=20
> Follow-up:
> I booted up last year's OS (Mandriva 2006 rather than 2007) and confirmed
> that the current code _does_ work.  So the breakage is recent, and
> I suppose is due either to the x.org libraries or to the font server.
> I have versions
>    working:	xorg-x11-6.9-1.cvs20050915.2mdk
>    not working:	xorg-x11-7.1.0-6mdv2007.0
>=20
> So I propose that for 4.2 we leave the default as it is, but I will add
> an X-resource that can change the default on systems suffering from the
> same oddity as Mandriva 2007 seems to be.  That permits a user-accessible
> fix we can document in the FAQ.
>=20

Ethan,

I have Mandrake 10.1, Redhat (Core 2?) and Solaris that I can test on.

I have noticed odd X11 font stuff, but I figured I was just screwing up the=
 font specification.  Do you have a sample font specification to test with?

Mike Sutton

Lines after this one were added by the stupid free mail system.


--=20
Low Prices, Wide Selection of Gas Masks
Everyday low price guarantee. We offer special police discounts and an extr=
emely wide selection of gas masks, filters and huge selection of preparedne=
ss gear.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D24e08df2353d2e6cb9bae=
3a0e3c8c61e

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>> Hans-Bernhard Bröker wrote:
>>
>>> Daniel J Sebald wrote:
> 
> 
>>>> Hmm, might there be a slight alteration of this that would work
>>>> "better"? 
> 
> 
>>> No.  The whole idea of "depth sorting" is fundamentally flawed.  No 
>>> slight alteration can make it work correctly.  The only real effect a 
>>> slight alteration will have is to move the errors to a different 
>>> region of parameter space, i.e. replace a known-bad guess by an 
>>> unknown one.
>>
>>
>> Depth sorting with something like qsort() is fundamentally flawed.  
> 
> 
> No.  It's the "sorting" itself that is based on incorrect assumptions 
> --- not the choice of sort algorithm or implementation.  The "covered 
> by" relation is not an ordering.
> 
> To get correct display, an algorithm has to go beyond sorting.  It has 
> to be prepared to split some objects into smaller fragments to get a 
> list that can be sorted.
> 
>> The assumption of equality is a problem in a sort like that.
> 
> 
> Equality is not really a problem --- transitivity is.  For a set to be 
> ordered by a relation '<', it has to be transitive, i.e. the condition
> 
>     (a < b) and (b < c)  ==> a < c
> 
> has to hold.  But doesn't hold for the relation "object obstructs (part 
> of) other object from view)".

Right.


> And worse yet, the ordering isn't local.  I.e. you can have two polygons 
> A and B whose drawing order cannot be determined in any way looking at 
> these two polygons alone (think of disjoint polygons in a plane parallel 
> to the view plane).  Adding a third polygon, C, can cause them to have 
> to be drawn either A before B, or B before A, depending on C.

Those, for the time being, aren't a concern.  Two reasons.  They are rare (if those start occurring at too high a percentage in one's plot, s/he has not selected the sampling interval large enough or your function has some kind of singularity problem, e.g., 1/sin(x)).  The plotting of the quadrangle which doesn't have convex points is not unique, so you get what you get.

Barring that class of nasty quadrangles, one can sort but can't use the transitive property.  Hence, almost anything below O(N^2) algorithm is out for a good approximation.


> Painters' algorithm is a different problem from sorting.  Calling it 
> "depth sorting" is ultimately a lie.  It's actually harder than sorting. 
>  For vector graphics output like gnuplot's terminal API it has a lower 
> bound of O(N^2) output size, and thus O(N^2) time for N polygons, 
> compared to sorting's O(N*log(N)).

Well, gnuplot is doing depth sorting.  There may be a subtle difference I'm not aware of.

Dan

Re: cannot set terminal X11

[<HBB...@t-...>]

David Vaknin wrote:

> I installed gnuplot Version 4.2 patchlevel rc2 and everything works  
> fine except that I cannot set terminal to X11.  When I start gnuplot  
> the following appears "Terminal type set to 'unknown' " and set  
> terminal command does not show x11 as an option.  I can plot to  
> postscript files etc..but not to screen.

Your X11 installation lacks the packages needed to develop (i.e.: 
compile) X11 applications.  You'll have to install something like 
"x11-devel".

Re: surface elements for transparent_solids.dem

[<HBB...@t-...>]

Daniel J Sebald wrote:
> Hans-Bernhard Bröker wrote:
>> Daniel J Sebald wrote:

>>> Hmm, might there be a slight alteration of this that would work
>>> "better"? 

>> No.  The whole idea of "depth sorting" is fundamentally flawed.  No 
>> slight alteration can make it work correctly.  The only real effect a 
>> slight alteration will have is to move the errors to a different 
>> region of parameter space, i.e. replace a known-bad guess by an 
>> unknown one.
> 
> Depth sorting with something like qsort() is fundamentally flawed.  

No.  It's the "sorting" itself that is based on incorrect assumptions 
--- not the choice of sort algorithm or implementation.  The "covered 
by" relation is not an ordering.

To get correct display, an algorithm has to go beyond sorting.  It has 
to be prepared to split some objects into smaller fragments to get a 
list that can be sorted.

> The assumption of equality is a problem in a sort like that.

Equality is not really a problem --- transitivity is.  For a set to be 
ordered by a relation '<', it has to be transitive, i.e. the condition

	(a < b) and (b < c)  ==> a < c

has to hold.  But doesn't hold for the relation "object obstructs (part 
of) other object from view)".

And worse yet, the ordering isn't local.  I.e. you can have two polygons 
A and B whose drawing order cannot be determined in any way looking at 
these two polygons alone (think of disjoint polygons in a plane parallel 
to the view plane).  Adding a third polygon, C, can cause them to have 
to be drawn either A before B, or B before A, depending on C.

Painters' algorithm is a different problem from sorting.  Calling it 
"depth sorting" is ultimately a lie.  It's actually harder than sorting. 
  For vector graphics output like gnuplot's terminal API it has a lower 
bound of O(N^2) output size, and thus O(N^2) time for N polygons, 
compared to sorting's O(N*log(N)).

Re: Last minute glitches - X11 font problem

[Ethan A M. <merritt@u.washington.edu>]

On Friday 12 January 2007 17:04, Ethan Merritt wrote:
> 
> The issue is what to do by default if no specific encoding has been 
> specified by the user.  The code currently fills the fields in with
> wild-cards:
> 	-*-times-*-r-*-*-12-*-*-*-*-*-*-*
> 
> This used to work, or at least I convinced myself at one time that it was
> working.  Now it doesn't.  Perhaps this is because I now have newer
> versions of x11 (x.org); perhaps it is because I have a wider variety of
> fonts installed, including multibyte fonts; perhaps it is because I am now
> using a UTF-8 locale everywhere.  I don't know.

Follow-up:
I booted up last year's OS (Mandriva 2006 rather than 2007) and confirmed
that the current code _does_ work.  So the breakage is recent, and
I suppose is due either to the x.org libraries or to the font server.
I have versions
  working:	xorg-x11-6.9-1.cvs20050915.2mdk
  not working:	xorg-x11-7.1.0-6mdv2007.0

So I propose that for 4.2 we leave the default as it is, but I will add
an X-resource that can change the default on systems suffering from the
same oddity as Mandriva 2007 seems to be.  That permits a user-accessible
fix we can document in the FAQ.

I don't see any relevant bugs or fixes listed on x.org's Bugzilla site.
Does anyone on this list have a bleeding-edge version 7.2-cvs of x.org to
see if the bug is still there?  Rebuilding x11 from cvs source is a little
more work than I have time to tackle.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Last minute glitches - X11 font problem

[Ethan M. <merritt@u.washington.edu>]

I've been using the wxt terminal by default for so long now that I failed
to notice breakage with the x11 terminal.  Or perhaps it broke even longer
ago and I just didn't notice.  Here is the problem:

When you specify a simple font name and size, for example
	set term x11 font "times,12"
gnuplot_x11 eventually translates this into a full x11 font spec of the form
	-*-times-*-r-*-*-12-*-*-*-*-*-iso8859-15

Notice in particular those last two fields, which specify the desired
character encoding.  If you tell gnuplot "set encoding koi8r", or whatever,
it will correctly fill in those last two fields accordingly.  No problem there.

The issue is what to do by default if no specific encoding has been 
specified by the user.  The code currently fills the fields in with
wild-cards:
	-*-times-*-r-*-*-12-*-*-*-*-*-*-*

This used to work, or at least I convinced myself at one time that it was
working.  Now it doesn't.  Perhaps this is because I now have newer
versions of x11 (x.org); perhaps it is because I have a wider variety of
fonts installed, including multibyte fonts; perhaps it is because I am now
using a UTF-8 locale everywhere.  I don't know.

Because gnuplot_x11 tries very hard to fall back to something reasonable,
in general you may not notice that you didn't get exactly what you asked for.
But if you ask for something more exotic, like 
	set term x11 font "french script mt,30"
it becomes apparent that it isn't being correctly selected.

I can fix this on my machines by changing the full wild-card    *-*
to the more restricted wild-card   iso*-*
but I have not tested it nearly as widely as I would like. Up until now
I didn't even know you _could_ specify restricted wild-cards in an x11
font spec.  I will put this change into cvs for additional testing.

The real conundrum is what to do for 4.2

- Leave it as is?
  (broken on current machines)

- Change the default to iso8859-1?
  (likely to work on the maximum number of machines, but unfortunate
   for those who don't use isolatin1)

- Change the default to iso*-*?
  (works for me, and doesn't limit to isolatin1, but I have no idea how
   universally accepted this syntax is)

- Make the default encoding an X-resource?
  (There would still have to be a default, with same concerns as above,
  but at least the end-user can be given instructions how to change it)

Can someone confirm whether the current code really does work on
older x11 setups?  If it has been broken all along then I don't worry so
much that a change to iso8859-1 or iso8859-* or iso*-* will be worse
than the current code on some machines.

If you want to experiment, the code at issue starts at gplt_x11.c line 5453

            fontencoding = (
                encoding == S_ENC_CP437     ? "dosencoding-cp437" :
                encoding == S_ENC_CP850     ? "dosencoding-cp850" :
                encoding == S_ENC_ISO8859_1 ? "iso8859-1" :
                encoding == S_ENC_ISO8859_2 ? "iso8859-2" :
                encoding == S_ENC_ISO8859_15 ? "iso8859-15" :
                encoding == S_ENC_KOI8_R    ? "koi8-r" :
                encoding == S_ENC_KOI8_U    ? "koi8-u" :
                "*-*" ) ;

The proposed fix is to change that last line to  "iso*-*" or "iso8859-*"
I would have expected that latter change to potentially break UTF-8
setups, but it doesn't break mine so I may be worrying needlessly.

   

Re: ***[Possible UCE]*** Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
> 
>>Hmm, might there be a slight alteration of this that would work
>>"better"? 
> 
> 
> No.  The whole idea of "depth sorting" is fundamentally flawed.  No 
> slight alteration can make it work correctly.  The only real effect a 
> slight alteration will have is to move the errors to a different region 
> of parameter space, i.e. replace a known-bad guess by an unknown one.

Depth sorting with something like qsort() is fundamentally flawed.  The assumption of equality is a problem in a sort like that.  If "does not overlap" is assigned to the equality class, a = b (a and b don't overlap) and b = c (b and c don't overlap) does not imply a = c (a and c might overlap).


>>Rather than carrying out a bubble sort on depthorder, couldn't we
>>carry out a bubble sort on "covered by"?
> 
> 
> No --- because "covered by" isn't a proper ordering criterion.  Cyclic 
> obstruction from view is possible with as little as three triangles in 
> the scene.  And surface patch can intersect each other, share edges or 
> vertices, and do various other kinds of "special case" things that are 
> hard to think of before-hand.

Well, what you are saying is generally true.  However, such an approach might (repeat might, I'm trying it out right now) work for samplings which do not have the property you mention, and this could be a broad class.  If every element only covers elements that do not lead back to cover the original element, I can imagine a valid sorting method (but again, sorts based upon a notion of equality won't do it).

What I'm saying is that even though we are using an approximation to "ray tracing" (for lack of phrase, i.e., the correct solution) we might be able to improve the current approximation and get good results in a high number of cases.

I have some ideas.  More later.


>>Anyway, it shouldn't be too difficult to write a routine, given two
>>elements that establishes draw order for the scenarios above.
> 
> 
> Oh, it _is_ difficult.  If you don't believe my words, believe the code 
> I wrote to implement hidden3d, or get yourself a textbook on 3D computer 
> graphics.

Yes.  I've been trying out a few things and then came to the conclusion that the problem of determinining if two general convex surfaces in 3-space overlap is deceptively difficult.  I then started looking to some research-oriented stuff on the topic and learned a bit about this.

Dan

Re: surface elements for transparent_solids.dem

[<HBB...@t-...>]

Daniel J Sebald wrote:

> Hmm, might there be a slight alteration of this that would work
> "better"? 

No.  The whole idea of "depth sorting" is fundamentally flawed.  No 
slight alteration can make it work correctly.  The only real effect a 
slight alteration will have is to move the errors to a different region 
of parameter space, i.e. replace a known-bad guess by an unknown one.

> Rather than carrying out a bubble sort on depthorder, couldn't we
> carry out a bubble sort on "covered by"?

No --- because "covered by" isn't a proper ordering criterion.  Cyclic 
obstruction from view is possible with as little as three triangles in 
the scene.  And surface patch can intersect each other, share edges or 
vertices, and do various other kinds of "special case" things that are 
hard to think of before-hand.

> Anyway, it shouldn't be too difficult to write a routine, given two
> elements that establishes draw order for the scenarios above.

Oh, it _is_ difficult.  If you don't believe my words, believe the code 
I wrote to implement hidden3d, or get yourself a textbook on 3D computer 
graphics.

universal binaries for Mac

[Mojca M. <moj...@gm...>]

Hello,

There are no gnuplot binaries for 4.2 available yet (which would be
helpful for users to test), bet I guess that for Mac it would be
hepful to have universal binaries (to work both on PowerPc & Intel
processor) and I don't think that gnuplot currently takes care about
that.

Here are some notes:

http://developer.apple.com/technotes/tn2005/tn2137.html

Most importantly, this should be added:

CFLAGS
    -arch i386 -arch ppc
LDFLAGS
    -arch i386 -arch ppc

./configure ... --disable-dependency-tracking

The --disable-dependency-tracking option to configure causes it to not
use gcc's built-in dependency generation code, which does not work
with multiple -arch targets.


Mojca

fonts, encodings (utf-8) and wxt

[Mojca M. <moj...@gm...>]

Hello,

Timoth=E9e asked me some time ago whether utf-8 works with wxt under mac.

The answer was "no".

But if I change:

gchar * gp_cairo_convert(plot_struct *plot, const char* string)
{
=09const char *charset =3D NULL;
=09gchar * string_utf8;

=09charset =3D gp_cairo_get_encoding(plot);

=09string_utf8 =3D g_convert(string, -1, "UTF-8", charset, &bytes_read,
NULL, &error);

into
=09string_utf8 =3D g_convert(string, -1, "UTF-8", "UTF-8", &bytes_read,
NULL, &error);

then it works OK. The encoding is set to 'default' in gnuplot itself,
locales are set to UTF-8, but apparently it's still thought that my
terminal works in "US-ASCII" encoding (apart from the fact that
command-line is completely confused if I try to use left-right arrow
or to delete anything: that still seems to be broken).

If I change encoding to ISO_8859_2 for example, then I don't get any
warning during conversion, but of course it doesn't work properly
either.


The next problem: I always get three warnings when I plot:

(process:26777): Pango-WARNING **: Error loading GDEF table 85
(process:26777): Pango-WARNING **: Error loading GPOS table 85
(process:26777): Pango-WARNING **: Error loading GSUB table 85

This doesn't happen if I also specify some font explicitely (set term
wxt font "validname").

Mojca

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Wednesday 10 January 2007 22:50, Daniel J Sebald wrote:
> 
>>>>One thing I notice when the fill is solid is that along some of the
>>>>edges of the Kuen's surface example are some oddly shaped surface
>>>>elements.
>>
>>I'm pretty certain this is a bug; there are some elements from a hidden
>>surface for some reason being mixed in with the elements from the visible
>>surface.  Hidden lines works as it should. 
> 
> 
> 
> The "depthorder hidden3d" option of pm3d is just plain different from the 
> "set hidden3d" code. They will not, in general produce the same result.

Oh, so the "depthorder hidden3d" draws a line around each element, right?  And this sort of mimmicks what hidden3d looks like, I assume?

  
> The "set pm3d depthorder" doesn't really calculate hidden lines or surfaces 
> at all (please see docs); it just sorts the quadrangles based on the mean 
> W-coordinate of each, and draws them in order of increasing W.

I see.  Draw the ones that are further back in the view (on average) first.  Unfortunately, in this case with that thin edge there are some elements of the hidden surface which are further forward than the elements on the visible surface.

 
> "W" here is the virtual axis from the center of the plot to your eye.  
> Because it uses the mean W of the whole tile to make a call for the entire tile, 
> you can get misplaced corners if the protrude above/below the mean W of the 
> next tile in view.  C'est la vie.

Yeah, c'est la vie.  Not exactly the desired effect.

Hmm, might there be a slight alteration of this that would work "better"?  (I.e., works differently but gives an effect more suitable for other desired scenarios.)

Rather than carrying out a bubble sort on depthorder, couldn't we carry out a bubble sort on "covered by"?

Imagine taking two quadrangles somewhere in 3D space.  With respect to W, the projection from N dimensional space to N-1 dimensional space there are three scenarios that can occur:

1)  There is no overlap of the elements.  Doesn't matter which order the elements are displayed.

2)  Element #1 covers a portion of element #2 *and* no portion of element #2 covers element #1.  Element #2 should be drawn first.

3)  Element #2 covers a portion of element #1 *and* no portion of element #1 covers element #1.  Element #1 should be drawn first.

4)  Tricky part:  Element #1 covers a portion of element #2 *and* a portion of element #2 covers element #1.  Hmm what to do.  Random?  No.  Percentage of which is covered more?  Perhaps.  Fall back on depth order in this case?  Perhaps.

Anyway, it shouldn't be too difficult to write a routine, given two elements that establishes draw order for the scenarios above.  (BTW, a portion of the image code is like this, i.e., Does the corner of this pixel land inside the view box?  Vice versa?  That sort of thing.)

OK, so the idea is rather than a bubble sort with the question "Which is deeper?", the sort would be carried out with the question "Which is covered?"

After the bubble sort, the sequence at which elements are drawn may come out funny, but I doubt it would bother too many people.

Dan

Re: surface elements for transparent_solids.dem

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 10 January 2007 22:50, Daniel J Sebald wrote:
> > 
> >>One thing I notice when the fill is solid is that along some of the
> >>edges of the Kuen's surface example are some oddly shaped surface
> >>elements.
> 
> I'm pretty certain this is a bug; there are some elements from a hidden
> surface for some reason being mixed in with the elements from the visible
> surface.  Hidden lines works as it should. 


The "depthorder hidden3d" option of pm3d is just plain different from the 
"set hidden3d" code. They will not, in general produce the same result.  
The "set pm3d depthorder" doesn't really calculate hidden lines or surfaces 
at all (please see docs); it just sorts the quadrangles based on the mean 
W-coordinate of each, and draws them in order of increasing W. 
"W" here is the virtual axis from the center of the plot to your eye.  
Because it uses the mean W of the whole tile to make a call for the entire tile, 
you can get misplaced corners if the protrude above/below the mean W of the 
next tile in view.  C'est la vie.

Please see also the previous extensive discussion and argument with regard 
to patch #1077726 from Nov 2005.









> To verify this, run the 
> transparent_solids.dem file three times in X11 creating a new window each
> time so the various Kuen surface plots can be compared.
> 
> load 'transparent_solids.dem'
> (hit return twice)
> (
> change
>   splot x(u,v), y(u,v), z(u,v) with pm3d
> to
>   splot x(u,v), y(u,v), z(u,v) with lines
> in transparent_solids.dem'
> )
> set term x11 2
> load 'transparent_solids.dem'
> (hit return twice)
> (
> add
>   unset hidden3d
>   splot x(u,v), y(u,v), z(u,v) with lines
> in transparent_solids.dem'
> )
> set term x11 3
> load 'transparent_solids.dem'
> (hit return twice)
> 
> I believe the second plot with hidden lines but no pm3d elements looks
> correct.  Now, if one looks at the third plot with the quadrangles from
> what would be hidden surfaces, these match the geometry of the few
> quadrangles in the first "hidden3d pm3d" plot.
> 
> It would be nice to fix this for 4.2 (don't want the flagship figures hilighting flaws).  This seems like it would be but a line or two alteration.  Anyone?
> 
> Dan
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> Daniel J Sebald wrote:
> 
>>One thing I notice when the fill is solid is that along some of the
>>edges of the Kuen's surface example are some oddly shaped surface
>>elements.

I'm pretty certain this is a bug; there are some elements from a hidden
surface for some reason being mixed in with the elements from the visible
surface.  Hidden lines works as it should.  To verify this, run the
transparent_solids.dem file three times in X11 creating a new window each
time so the various Kuen surface plots can be compared.

load 'transparent_solids.dem'
(hit return twice)
(
change
  splot x(u,v), y(u,v), z(u,v) with pm3d
to
  splot x(u,v), y(u,v), z(u,v) with lines
in transparent_solids.dem'
)
set term x11 2
load 'transparent_solids.dem'
(hit return twice)
(
add
  unset hidden3d
  splot x(u,v), y(u,v), z(u,v) with lines
in transparent_solids.dem'
)
set term x11 3
load 'transparent_solids.dem'
(hit return twice)

I believe the second plot with hidden lines but no pm3d elements looks
correct.  Now, if one looks at the third plot with the quadrangles from
what would be hidden surfaces, these match the geometry of the few
quadrangles in the first "hidden3d pm3d" plot.

It would be nice to fix this for 4.2 (don't want the flagship figures hilighting flaws).  This seems like it would be but a line or two alteration.  Anyone?

Dan

Re: surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:
> One thing I notice when the fill is solid is that along some of the
> edges of the Kuen's surface example are some oddly shaped surface
> elements.  For example, along the orange/red edge of the surface are
> some elements that appear to be tiled in a direction counter to the
> reset of the element flow.  Is this a known effect, either in general
> or for this particular manifold?  Is there some cusp along that upper
> ridge that causes this?

Looking at this more closely, it does seem like a bug.  If one plots in x11 and uses the mouse to pan about, the manifold gets very "thin" along the locations where the strange elements appear.  Could this be an effect where a tile from an underlying surface is coming through the top surface?  Could there be a roundoff error in a conditional test somewhere that the gnuplot algorithm thinks an element should come through and above a top surface when it really shouldn't?

Dan

surface elements for transparent_solids.dem

[Daniel J S. <dan...@ie...>]

One thing I notice when the fill is solid is that along some of the edges of the Kuen's surface example are some oddly shaped surface elements.  For example, along the orange/red edge of the surface are some elements that appear to be tiled in a direction counter to the reset of the element flow.  Is this a known effect, either in general or for this particular manifold?  Is there some cusp along that upper ridge that causes this?

Dan

Re: odds and ends

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot-old/src/gplt_x11.c      2006-12-28 10:25:50.000000000 -0800
> +++ gnuplot-new/src/gplt_x11.c  2007-01-10 13:31:15.000000000 -0800
> @@ -3578,6 +3578,7 @@
>                 index = plot->cmap->allocated -1;
> 
>         XSetForeground(dpy, gc, plot->cmap->pixels[index]);
> +       plot->current_rgb = plot->cmap->rgbcolors[index];
>      }
>  }

You typed too quickly; replace rgbcolors[index] by pixels[index] in the above and it works great.

Dan

Re: odds and ends

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

> However, the output from transparent_solids.dem still looks a bit odd,
> so there may be another bug still lurking.

First time through, the very "bottom" (first or last) palette color looks off.  Run the demo again and the palette colors look random.  Step forward though.

Dan

Re: odds and ends

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 10 January 2007 11:02, Ethan Merritt wrote:
> 
> > I would think in this case that if x11 behaved the same as PostScript 
> > (i.e., the same color elements,  but just not the transparency) would be fine.  
> 
> That was the intent.  There may be a bug.

Indeed.  There is a bug in gplt_x11.c such that any color selected via
PaletteSetColor() is not saved for future reference.  

That is, unlike other color selection pathways, it does not update the 
current color as maintained in  plot->current_rgb

That oversight has a 1-line fix:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot-old/src/gplt_x11.c      2006-12-28 10:25:50.000000000 -0800
+++ gnuplot-new/src/gplt_x11.c  2007-01-10 13:31:15.000000000 -0800
@@ -3578,6 +3578,7 @@
                index = plot->cmap->allocated -1;

        XSetForeground(dpy, gc, plot->cmap->pixels[index]);
+       plot->current_rgb = plot->cmap->rgbcolors[index];
     }
 }

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

However, the output from transparent_solids.dem still looks a bit odd,
so there may be another bug still lurking.