Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Petr Mikulik <mikulik@ph...>  20090128 13:02:18

The enclosed script using the "pm3d depthorder" gives wrong ordering of faces on gnuplotcvs, and sometimes wrong and sometimes good ordering on gnuplot 4.2. Also try to rotate the plot by mouse. How can this happen? *** f(x,y)=sin(x*y*pi/180)/(x*y*pi/180) if (1) set xrange [720:720]; set yrange [720:720]; \ set sample 10; set isosamples 10; set table 'a.dat'; splot f(x,y); unset table; reset set auto fix #set xrange [0:10]; set yrange [0:10] set xlabel "x axis"; set ylabel "y axis" set xyplane at 0 set pm3d set pm3d depthorder set view 64, 287 splot 'a.dat' with pm3d pause 1 set view 64, 286; replot 
From: Daniel J Sebald <daniel.sebald@ie...>  20090202 01:08:35

Petr Mikulik wrote: > The enclosed script using the "pm3d depthorder" gives wrong ordering of > faces on gnuplotcvs, and sometimes wrong and sometimes good ordering on > gnuplot 4.2. Also try to rotate the plot by mouse. How can this happen? Petr, depthorder is a very much an approximation to true hidden surface features. I think there was some discussion a couple years ago about this. If I'm remembering correctly, I wrote a patch for determining the depth which I thought was a bit more robust. But after discussions with Ethan, I thought it would be more worthwhile putting effort into actual hidden surface, if one had time. (A generalization of the hidden lines code where a hidden surface is broken into smaller parts.) The problem in your example is that the surfaces are too big relative to the resolution such that in 3D space their depths overlap. Furthermore, this example is probably undersampling anyway because the peaks aren't visible. Try set dgrid3d 100,100 replot and you should get improvement in the behavior of both. (But there are still hidden surface flaws.) Dan > > *** > > f(x,y)=sin(x*y*pi/180)/(x*y*pi/180) > > if (1) set xrange [720:720]; set yrange [720:720]; \ > set sample 10; set isosamples 10; set table 'a.dat'; splot f(x,y); > unset table; reset > > set auto fix > #set xrange [0:10]; set yrange [0:10] > set xlabel "x axis"; set ylabel "y axis" > set xyplane at 0 > > set pm3d > > set pm3d depthorder > > set view 64, 287 > splot 'a.dat' with pm3d > > pause 1 > > set view 64, 286; replot > >  > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sfspreadtheword > _______________________________________________ > gnuplotbeta mailing list > gnuplotbeta@... > https://lists.sourceforge.net/lists/listinfo/gnuplotbeta >  Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com 
From: Petr Mikulik <mikulik@ph...>  20090202 09:47:00

> > The enclosed script using the "pm3d depthorder" gives wrong ordering of > > faces on gnuplotcvs, and sometimes wrong and sometimes good ordering on > > gnuplot 4.2. Also try to rotate the plot by mouse. How can this happen? > > Petr, > > depthorder is a very much an approximation to true hidden surface features. I > think there was some discussion a couple years ago about this. If I'm > remembering correctly, I wrote a patch for determining the depth which I > thought was a bit more robust. But after discussions with Ethan, I thought it > would be more worthwhile putting effort into actual hidden surface, if one had > time. (A generalization of the hidden lines code where a hidden surface is > broken into smaller parts.) > > The problem in your example is that the surfaces are too big relative to the > resolution such that in 3D space their depths overlap. Furthermore, this > example is probably undersampling anyway because the peaks aren't visible. I was wondering which point(s) of the rectangle is/are used for the depth ordering. Is it min(all 4 corners) or centerofrectangle or all of them? It seems to me that this is producing this bug: the two problematic rectangles touch in one edge (2 corners), but their other 2 corners have different depth.  PM 
From: Daniel J Sebald <daniel.sebald@ie...>  20090202 14:52:44

Petr Mikulik wrote: >>>The enclosed script using the "pm3d depthorder" gives wrong ordering of >>>faces on gnuplotcvs, and sometimes wrong and sometimes good ordering on >>>gnuplot 4.2. Also try to rotate the plot by mouse. How can this happen? >> >>Petr, >> >>depthorder is a very much an approximation to true hidden surface features. I >>think there was some discussion a couple years ago about this. If I'm >>remembering correctly, I wrote a patch for determining the depth which I >>thought was a bit more robust. But after discussions with Ethan, I thought it >>would be more worthwhile putting effort into actual hidden surface, if one had >>time. (A generalization of the hidden lines code where a hidden surface is >>broken into smaller parts.) >> >>The problem in your example is that the surfaces are too big relative to the >>resolution such that in 3D space their depths overlap. Furthermore, this >>example is probably undersampling anyway because the peaks aren't visible. > > > I was wondering which point(s) of the rectangle is/are used for the depth > ordering. Is it min(all 4 corners) or centerofrectangle or all of them? It > seems to me that this is producing this bug: the two problematic rectangles > touch in one edge (2 corners), but their other 2 corners have different > depth. You've found the right issue. It is min or max, I can't recall which. I think I'd written a patch that used average or something. All choices have their particular problem scenarios. Dan 
From: HansBernhard Bröker <HBB<roeker@t...>  20090202 21:17:57

Petr Mikulik wrote: > I was wondering which point(s) of the rectangle is/are used for the depth > ordering. It may seem like this should be an important detail. But it's not. It's completely irrelevant which number you sort by. It just moves the problem into different regions, but does nothing at all to solve it. The heart of the matter is that depth sorting does not work. It's quite easy to prove by counterexample. You have to do more than just sort polygons to get a correct rendering. The sort itself can't be done by comparing a single "characteristic" number. You have to compare entire polygons, using basically all their geometric data. And sometimes the answer still is "undecidable", in which case you have to split one of them. For the gory details, look up the NewellNewellSancha algorithm, or consult the literature on BSP trees and their usage to do hiddensurface removal. 
Sign up for the SourceForge newsletter:
No, thanks