gnuplot-beta

odds and ends

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

When running histograms.dem the line:

            /* Jun 2006 - Return to behavior of 3.7 and current docs:
	     *            do not interrupt plotted line because of missing data
	     */
	    fprintf(stderr,"Missing datum %d\n", i);


of plot2d.c prints out

gnuplot> load 'histograms.dem'
Missing datum 0
Missing datum 0
Missing datum 1
Missing datum 0
Missing datum 0

Should that fprintf be active for the 4.2 release?


I've probably asked this before, but preceding and trailing white spaces... should those not be ignored as the code currently does?

gnuplot> load ' histograms.dem'
                               ^
         Cannot open load file ' histograms.dem'
         util.c: No such file or directory

gnuplot> load 'histograms.dem '
                               ^
         Cannot open load file 'histograms.dem '
         util.c: No such file or directory


For the history readline, the Home key places an "OH" in the line and the End key places an "OF" in the command line.  Could those be altered so that Home moves the cursor to the front and End to the end of the line?

Dan

odds and ends

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

I noticed that molecule.dem is still not in all.dem, if Ethan wanted that one in the list.  (The second image would make a good animation to see both top and bottom of the hyperplane border.)

The demo

  set title "set pm3d corners2color c3"

has the text for the color bar off of the plot.  There is enough space to push the sample boxes upward and make more room for the color bar.

The demo "transparent_solids.dem" produces color differences between X11 and PostScript.  The interlocking tori example is all one color in X11, blueish purple.  In PostScript, the color fades from white to light red.  The Kuen's surface in X11 is grayscale where every element is the same shade.  In PostScript, it comes multicolored.

Also, somehow with the tori example I ended up with "view" and "scale" coordinates in a huge sans seriff font... Here's how I did it.  Run gnuplot and type:

load 'transparent_solids.dem'
load 'transparent_solids.dem'

On the second load of the demo the first graph has the font too large for the coordinates.  (There should be no way of controling the coordinate fonts, is that right?)

For 'transparent.dem'.  The font I see in the key is some strange glyph and different between X11 and PostScript.  (I've not followed font issues closely.)  The lines in the density function for red and yellow do not show up in PostScript.  The overlay of the third plot in this demo doesn't work the same for PostScript either.

The PDF terminal crashes gnuplot on demo "transparent_solids.dem".

  Hit return to continue
  PDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font 'frscript' not found

Problems here as well:

********************** file stringvar.dem *********************
Hit return to continueHit return to continueHit return to continueHit return to continuePDFlib exception (fatal): [2516] PDF_findfont: Metrics data for font 'WingDings' not found


Dan

Re: odds and ends

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

Ethan A Merritt wrote:
> On Tuesday 09 January 2007 19:19, Daniel J Sebald wrote:
> 
>> The demo "transparent_solids.dem" produces color differences
>> between X11 and PostScript.
> 
> 
> Well, since neither x11 nor postscript support transparency... Do you
> think the demo should refuse to run?

Do we have the mechanism to do that?  Saying that a terminal doesn't support transparency is fine with me.

> Should non-supporting terminals
> fall back to something in particular if transparency is not possible?
> What, exactly?

Falling back on something is fine, but it should be consistent across terminals.  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.  Were you trying to implement transparency in X11?  Or will that come once the alpha-channel mechanics are there?

If non-supporting terminals fall back, a warning message seems pertinent so that the (new) user realizes that what they are looking at isn't transparent.


>> Also, somehow with the tori example I ended up with "view" and
>> "scale" coordinates in a huge sans seriff font... Here's how I did
>> it.  Run gnuplot and type:
>> 
>> load 'transparent_solids.dem' load 'transparent_solids.dem'
>> 
>> On the second load of the demo the first graph has the font too
>> large for the coordinates.
> 
> 
> Hmm, yes. That does seem to be a bug. I can't see why it would have
> anything in particular to do with transparency, though. Probably just
> a case of the last thing in the previous plot being drawn with a
> large font, and the coordinate-drawing routine is missing a font
> reset.

That is what I'm imagining.

> Same thing again.
> 
> You need to configure the pdflib font installation. On my machine
> it's in /usr/local/share/pdflib.upr You can put aliases for fonts
> that are not an exact match. For example, frscript=z003034l.afm
> (Chancery Italic) is a decent substitute for the font used in the
> Kuen's surface demo

OK, I wasn't aware of the pdflib.upr file, thanks.

I've found the PDF file describing the library documentation.  Good documentation, just had to find it.

I used ZapfDingbats.afm and get this warning:

PDFlib warning (ignored): [2504] PDF_findfont: Use 'builtin' encoding instead of 'iso8859-1' for font 'WingDings'

but I manage to get some output at least (stars instead of smileys and clubs instead of thumbs down).  At least PDFlib is a little more forgiving on this.

I see the following are directed by pdf.trm to use internal fonts of the PDF viewer:

    if ( (strcmp(PDF_fontNameCur,"Symbol") == 0) ||
	 (strcmp(PDF_fontNameCur,"ZapfDingbats") == 0) ) {

which could expanded:

Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique,
Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique,
Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic,
Symbol, ZapfDingbats

In the PDFlib doc, there is a form of exception handling for C of this variety:

	PDF_TRY(myPDF) {
	    font_handle = PDF_findfont(myPDF, PDF_fontNameCur, "builtin", 1);
	}
	PDF_CATCH(myPDF) {
	    fprintf(stderr,"HEY!  I DON'T KNOW THIS FONT!!\n");
	    return;
	}

but I'm having no success (may be because I'm stuck back in the "helvetica" missing font mode).

Dan

Re: odds and ends

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

Daniel J Sebald wrote:

> In the PDFlib doc, there is a form of exception handling for C of this variety:
> 
> 	PDF_TRY(myPDF) {
> 	    font_handle = PDF_findfont(myPDF, PDF_fontNameCur, "builtin", 1);
> 	}
> 	PDF_CATCH(myPDF) {
> 	    fprintf(stderr,"HEY!  I DON'T KNOW THIS FONT!!\n");
> 	    return;
> 	}
> 
> but I'm having no success (may be because I'm stuck back in the "helvetica" missing font mode).

A PDF file is corrupted once an exception occurs, so can't get back from that.  However, there is a way to lessen the font problems to returning a -1 rather than causing an exception:

    PDF_set_parameter(myPDF, "fontwarning", "false");

Almost works, but not quite...hmm

Dan

Re: odds and ends

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

Daniel J Sebald wrote:
> A PDF file is corrupted once an exception occurs, so can't get back from that.  However, there is a way to lessen the font problems to returning a -1 rather than causing an exception:
> 
>     PDF_set_parameter(myPDF, "fontwarning", "false");
> 
> Almost works, but not quite...hmm

Got it...

Timothée asked a question about fonts

Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique,
Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique,
Times-Roman, Times-Bold, Times-Italic, Times-BoldItalic,
Symbol, ZapfDingbats

not all having to be declared as builtin.  The answer is, I don't know.

Dan

Re: odds and ends

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

On Wednesday 10 January 2007 03:39, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > On Tuesday 09 January 2007 19:19, Daniel J Sebald wrote:
> > 
> >> The demo "transparent_solids.dem" produces color differences
> >> between X11 and PostScript.
> > 
> > 
> > Well, since neither x11 nor postscript support transparency... 
> 
> > Should non-supporting terminals fall back to something in particular if transparency is not possible?
> > What, exactly?
> 
> Falling back on something is fine, but it should be consistent across terminals.  

Let me explain the two possibilities I see for a driver that cannot handle transparency.

(1) Pretend that the style is 
	    "fillstyle solid <density>"
     rather than 
	    "fillstyle transparent solid <opacity>"
     This is what the PostScript driver is doing.  It makes the pair of tori look very pale,
     because instead of a mostly transparent surface (opacity=30%) it renders a surface
     that is at most 30% saturated with the fullscale color from the colorbar

(2) Ignore the opacity value altogether,  yielding full-scale color with no transparency.
     I don't think any of the drivers are doing this at the moment, but it would be easy
     enough to change. 

> 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.

> Were you trying to implement transparency in X11?   
> Or will that come once the alpha-channel mechanics are there?   

I think that implementing transparency on top of X11 is such a hard problem that it would
require a whole graphics project in its own right.  And in fact such projects exist. Two
obvious ones we could use are OpenGL, for which prototype gnuplot drivers have been
explored, and  wxWidgets, for which we now have a fully developed driver. 

So as I see it, the current best answer to "How can I use transparency with x11?"
is  "Use the wxt terminal"!

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.

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

[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

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:

> Let me explain the two possibilities I see for a driver that cannot handle transparency.
> 
> (1) Pretend that the style is 
> 	    "fillstyle solid <density>"
>      rather than 
> 	    "fillstyle transparent solid <opacity>"
>      This is what the PostScript driver is doing.  It makes the pair of tori look very pale,
>      because instead of a mostly transparent surface (opacity=30%) it renders a surface
>      that is at most 30% saturated with the fullscale color from the colorbar

Oh, I see now why what I'm looking at is "sort of transparent".


> (2) Ignore the opacity value altogether,  yielding full-scale color with no transparency.
>      I don't think any of the drivers are doing this at the moment, but it would be easy
>      enough to change.

A combination of the two would be fine too, I think.  For the most part, go with (2).  There may be some utility to (1) if it is acceptable to the user.  I would think then that comments like:

"Transparency not available:  reverting to solid"
"Transparency not available:  reverting to density approximation"

(Use a global variable to only print once for a driver.)

Well, is the situation what you are describing in (1) suggesting two different modes?  Is that conventional in the graphics field?  That is, rather than just "transparent" it should be "opaque" and "saturation"?  Then, if one of those don't exist *always* fall back on (2) because the user on his or her own will be able to attempt "saturation" option if "opaque" option didn't work.

> I think that implementing transparency on top of X11 is such a hard problem that it would
> require a whole graphics project in its own right.  And in fact such projects exist. Two
> obvious ones we could use are OpenGL, for which prototype gnuplot drivers have been
> explored, and  wxWidgets, for which we now have a fully developed driver. 
> 
> So as I see it, the current best answer to "How can I use transparency with x11?"
> is  "Use the wxt terminal"!

That's certainly an acceptable solution with me.

Dan

Re: odds and ends

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

On Wednesday 10 January 2007 12:58, you wrote:
> 
> Is that conventional in the graphics field?  
> That is, rather than just "transparent" it should be "opaque" 

"transparency" and "opacity" are complementary descriptions of the same property.
  see-through  	   <--------------> solid
transparency	1 <--------------> 0
opacity		0 <--------------> 1

It is most annoying that there is no consistency of whether an "alpha channel"
holds transparency or opacity.  Both conventions are used.

> and "saturation"? 

"Saturation" is one axis of HSV color specification.
It runs from 0 (neutral) to 1 (full color in question)

http://en.wikipedia.org/wiki/Saturation_(color_theory)

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

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

[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...>]

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

[<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.

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: 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: ***[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:
> 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: 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...>]

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: 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

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