Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2009-01-28 13:02:18
|
The enclosed script using the "pm3d depthorder" gives wrong ordering of
faces on gnuplot-cvs, 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 S. <dan...@ie...> - 2009-02-02 01:08:35
|
Petr Mikulik wrote: > The enclosed script using the "pm3d depthorder" gives wrong ordering of > faces on gnuplot-cvs, 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/sf-spreadtheword > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Dan Sebald email: daniel(DOT)sebald(AT)ieee(DOT)org URL: http://www(DOT)dansebald(DOT)com |
|
From: Petr M. <mi...@ph...> - 2009-02-02 09:47:00
|
> > The enclosed script using the "pm3d depthorder" gives wrong ordering of > > faces on gnuplot-cvs, 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 center-of-rectangle 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 S. <dan...@ie...> - 2009-02-02 14:52:44
|
Petr Mikulik wrote: >>>The enclosed script using the "pm3d depthorder" gives wrong ordering of >>>faces on gnuplot-cvs, 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 center-of-rectangle 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: Hans-Bernhard B. <HBB...@t-...> - 2009-02-02 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 counter-example. 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 Newell-Newell-Sancha algorithm, or consult the literature on BSP trees and their usage to do hidden-surface removal. |
