Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-12-07 20:39:15
|
On 07.12.2010 16:42, Stanislav Maslovski wrote: > So, I solved this issue by patching pm3d.c:pm3d_depth_queue_flush() > so that sorting of quadrangles was done based on the average depth of > 4 corners. Unfortunately that's not really a solution. There is no particular reason to prefer one sorting criterion over the other. Painter's algorithm is plain and simply wrong --- no matter which property you sort by. If it appears to work sometimes that's by happenstance, not by design. |
|
From: Stanislav M. <sta...@gm...> - 2010-12-09 15:53:47
|
Hello, On Tue, 2010-12-07 at 15:42 +0000, Stanislav Maslovski wrote: > On Tue, 2010-12-07 at 11:51 +0000, Stanislav Maslovski wrote: > > Hello, > > > > Can anyone advise me on how can I workaround the problem with 3D > > rendering in the plot [1]? The problem is that the surfaces that must be > > hidden are seen in this plot (to clearly see them, > > load "maxout.gnuplot" and try rotating the plot). > > > > The plot was generated in maxima, using the draw3d command. Any help > > will be very much appreciated! > > > > [1] http://zalil.ru/30094104 (wait 10 secs, and download will start) > > Replying to myself: actually, after reading some docs (and the code) I > realized that it was a limitation of the rendering algorithm used by the > gnuplot (a variant of painter's algorithm). So, I solved this issue by > patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles > was done based on the average depth of 4 corners. > > It would be nice if this could be made configurable. I will probably > come out with a patch in the next couple of days to enable this feature. Just in case: the patch with an example is available from here http://sourceforge.net/tracker/?func=detail&aid=3132649&group_id=2055&atid=302055 Cheers, -- Stanislav |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-12-09 20:11:48
|
On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote: > Hello, > > On Tue, 2010-12-07 at 15:42 +0000, Stanislav Maslovski wrote: > > On Tue, 2010-12-07 at 11:51 +0000, Stanislav Maslovski wrote: > > > Hello, > > > > > > Can anyone advise me on how can I workaround the problem with 3D > > > rendering in the plot [1]? The problem is that the surfaces that must be > > > hidden are seen in this plot (to clearly see them, > > > load "maxout.gnuplot" and try rotating the plot). > > > > > > The plot was generated in maxima, using the draw3d command. Any help > > > will be very much appreciated! > > > > > > [1] http://zalil.ru/30094104 (wait 10 secs, and download will start) > > > > Replying to myself: actually, after reading some docs (and the code) I > > realized that it was a limitation of the rendering algorithm used by the > > gnuplot (a variant of painter's algorithm). So, I solved this issue by > > patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles > > was done based on the average depth of 4 corners. I don't think this is the best way to approach the problem. As Hans-Bernhard pointed out, _any_ simple-minded sorting on a single Z value is going to fail for some configuration of triangles. The bigger the triangle, the more likely that any single Z value is not right for the whole thing. I suggest that a better approach would be to add a pass that splits large triangles into smaller pieces before sorting and rendering. The only tricky part is how to define "large". [OK, there's potentially another tricky part if you are coloring by something other than Z since you have to decide how to assign colors to the newly created vertices.] You can probably find sample code for this kind of divide-and-conquer approach in a textbook or article, but it should be simple enough to work it out from scratch. Ethan > > > > It would be nice if this could be made configurable. I will probably > > come out with a patch in the next couple of days to enable this feature. > > Just in case: the patch with an example is available from here > http://sourceforge.net/tracker/?func=detail&aid=3132649&group_id=2055&atid=302055 > > Cheers, > -- > Stanislav |
|
From: Daniel J S. <dan...@ie...> - 2010-12-09 21:58:38
|
Ethan Merritt wrote: > On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote: > >>Hello, >> >>On Tue, 2010-12-07 at 15:42 +0000, Stanislav Maslovski wrote: >> >>>On Tue, 2010-12-07 at 11:51 +0000, Stanislav Maslovski wrote: >>> >>>>Hello, >>>> >>>>Can anyone advise me on how can I workaround the problem with 3D >>>>rendering in the plot [1]? The problem is that the surfaces that must be >>>>hidden are seen in this plot (to clearly see them, >>>>load "maxout.gnuplot" and try rotating the plot). >>>> >>>>The plot was generated in maxima, using the draw3d command. Any help >>>>will be very much appreciated! >>>> >>>>[1] http://zalil.ru/30094104 (wait 10 secs, and download will start) >>> >>>Replying to myself: actually, after reading some docs (and the code) I >>>realized that it was a limitation of the rendering algorithm used by the >>>gnuplot (a variant of painter's algorithm). So, I solved this issue by >>>patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles >>>was done based on the average depth of 4 corners. > > > I don't think this is the best way to approach the problem. > As Hans-Bernhard pointed out, _any_ simple-minded sorting on a > single Z value is going to fail for some configuration of triangles. > The bigger the triangle, the more likely that any single Z value is not > right for the whole thing. > > I suggest that a better approach would be to add a pass that splits large > triangles into smaller pieces before sorting and rendering. > The only tricky part is how to define "large". > [OK, there's potentially another tricky part if you are coloring by > something other than Z since you have to decide how to assign colors > to the newly created vertices.] > > You can probably find sample code for this kind of divide-and-conquer > approach in a textbook or article, but it should be simple enough to > work it out from scratch. The rendering of the 3D surfaces doesn't cut it. I tried very hard myself to come up with a good compromise, but it seemed there was no good approach for the general case. (Some examples would look good, others not.) What Ethan is suggesting might help (or not, depending on the example perhaps), but that still isn't the answer. I had reached the conclusion that implementing the rendering by determining intersections of surfaces pretty much as defined might be the best place to put effort. It was just after I had looked at the 2D mesh code that had some boundary issues. The 2D code looks for intersections of lines and then breaks those lines up. If one thinks in terms of vectors and matrices (i.e., linear algebra formulas), keeping things straight is not too difficult. The same would apply for 3D surfaces. Look for intersecting surfaces and then break those up--being 3D there are a lot of cases and the result will be a growth in code, but one just has to be organized about it. The "painter algorithm" works for a first pass, i.e., if there is not intersection along the depth, (or width or height) for two particular triangles, then there is no way there can be intersections and no need to check. That will speed processing significantly. Actual 3D rendering would be a nice addition. Might make for a good little project one of these days. Dan |
|
From: Stanislav M. <sta...@gm...> - 2010-12-10 11:17:36
|
Hello, On Thu, 2010-12-09 at 12:11 -0800, Ethan Merritt wrote: > On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote: > > > Replying to myself: actually, after reading some docs (and the code) I > > > realized that it was a limitation of the rendering algorithm used by the > > > gnuplot (a variant of painter's algorithm). So, I solved this issue by > > > patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles > > > was done based on the average depth of 4 corners. > > I don't think this is the best way to approach the problem. > As Hans-Bernhard pointed out, _any_ simple-minded sorting on a > single Z value is going to fail for some configuration of triangles. > The bigger the triangle, the more likely that any single Z value is not > right for the whole thing. Yes, I agree. That was just the first thing I tried and it worked for my task. However, until a better rendering algorithm is available, I still suggest including my patch because it makes the depth sorting configurable which certainly helps in some cases (while keeping the same default behavior). The reasoning behind this is purely practical: 1) configurability of depth sorting can be useful with sparse datasets; 2) all the infrastructure that my patch relies upon is already in the code (in the realization of corners2color option). > I suggest that a better approach would be to add a pass that splits large > triangles into smaller pieces before sorting and rendering. > The only tricky part is how to define "large". I was thinking about exactly the same thing, but then realized that there is already the "interpolate" option that does (almost) the same. But sometimes we want to look at a dataset _without_ smoothing it, right? -- Stanislav |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-12-10 17:24:09
|
On Friday, December 10, 2010 03:17:16 am Stanislav Maslovski wrote: > > I suggest that a better approach would be to add a pass that splits large > > triangles into smaller pieces before sorting and rendering. > > The only tricky part is how to define "large". > > I was thinking about exactly the same thing, but then realized that > there is already the "interpolate" option that does (almost) the same. > But sometimes we want to look at a dataset without smoothing it, > right? Splitting an existing triangle into sub-triangles would not create any smoothing. In the absence of occluding objects, the rendered image of the new set of smaller triangles is indistiguishable from that of the original single triangle. The issue of interpolation only arises if you need to assign a color to the newly created vertex based on differing colors belonging to the existing vertices. |
|
From: Petr M. <mi...@ph...> - 2010-12-10 21:07:04
|
> > I suggest that a better approach would be to add a pass that splits large > > triangles into smaller pieces before sorting and rendering. > > The only tricky part is how to define "large". > > I was thinking about exactly the same thing, but then realized that > there is already the "interpolate" option that does (almost) the same. Does "pm3d interpolate x,y" works for you? Yes, this interpolation is some kind of smoothing because you add new objects. > of 4 corners, instead, it introduces a new pm3d option "corners2depth" > that allows for configurability of the depth sorting in a similar manner > as already existing "corners2color" option adds configurability I think this option is useful. --- PM |
|
From: Stanislav M. <sta...@gm...> - 2010-12-12 17:08:37
Attachments:
default.png
c3.png
|
Hello, On Fri, Dec 10, 2010 at 10:06:52PM +0100, Petr Mikulik wrote: > > > I suggest that a better approach would be to add a pass that splits large > > > triangles into smaller pieces before sorting and rendering. > > > The only tricky part is how to define "large". > > > > I was thinking about exactly the same thing, but then realized that > > there is already the "interpolate" option that does (almost) the same. > > Does "pm3d interpolate x,y" works for you? You mean, for that dataset that I submitted together with the patch? I just tested it with "interpolate 0,0". As expected, interpolation smoothens the surface and produces a better figure, but it still has very noticeable artefacts (see the attached default.png). If I add "corners2depth c3" the result is much better (c3.png). > Yes, this interpolation is some kind of smoothing because you add new > objects. > > > of 4 corners, instead, it introduces a new pm3d option "corners2depth" > > that allows for configurability of the depth sorting in a similar manner > > as already existing "corners2color" option adds configurability > > I think this option is useful. Yes, with the curent rendering algorithm it is for sure useful. -- Stanislav |
|
From: Stanislav M. <sta...@gm...> - 2010-12-10 11:39:55
|
On Thu, 2010-12-09 at 12:11 -0800, Ethan Merritt wrote: > On Thursday, December 09, 2010 07:53:12 am Stanislav Maslovski wrote: > > > Replying to myself: actually, after reading some docs (and the code) I > > > realized that it was a limitation of the rendering algorithm used by the > > > gnuplot (a variant of painter's algorithm). So, I solved this issue by > > > patching pm3d.c:pm3d_depth_queue_flush() so that sorting of quadrangles > > > was done based on the average depth of 4 corners. > > I don't think this is the best way to approach the problem. > As Hans-Bernhard pointed out, _any_ simple-minded sorting on a > single Z value is going to fail for some configuration of triangles. > The bigger the triangle, the more likely that any single Z value is not > right for the whole thing. BTW, just a little clarification in case if someone reading this has not looked into the patch: the patch does more than just averaging the depth of 4 corners, instead, it introduces a new pm3d option "corners2depth" that allows for configurability of the depth sorting in a similar manner as already existing "corners2color" option adds configurability to the coloring. -- Stanislav |
|
From: Alexandre F. <o.a...@gm...> - 2010-12-12 15:52:05
|
"I had reached the conclusion that implementing the rendering by determining intersections of surfaces pretty much as defined might be the best place to put effort." - Daniel J Sebald Find all the triangle pairs for wich the nearest vertex of firstis nearer than the farthest of the vertexes of the second triangle, and the farthest vertex of first is farther than the nearest of the vertexes of the second triangle. these are the ones who may need to be splited. then take the planes containing the two triangles, intersect them, it can result an line (say Li), or a null intersection, in case of being a line, find all the intersections of Li with the triangles edges. it must be in the following sequence enter triangle 1, exit triangle 1 enter triangle 2, exit triangle 2 in all other cases, the triangles are splited in the line Li After proceeding in this way you can use any criteria to sort the triangles, i think this is the minimal algorithm, it takes about 1 days to be coded ant two or three to get working :D I have a C++ 3D geometry class. but it uses overloaded operators (everywhere), with this class I am able to implement, i think, what i described above. if one want to translate the C++ to C and compile it i can spend some time for writing it, and send yet this week. |
|
From: Daniel J S. <dan...@ie...> - 2010-12-12 18:11:31
|
Alexandre Felipe wrote: > "I had reached the conclusion that implementing the rendering by determining > intersections of surfaces pretty much as defined might be the best place to > put effort." - Daniel J Sebald > > > Find all the triangle pairs for wich the nearest vertex of firstis nearer > than the farthest of the vertexes of the second triangle, and the farthest > vertex of first is farther than the nearest of the vertexes of the second > triangle. > > these are the ones who may need to be splited. > > then take the planes containing the two triangles, intersect them, it can > result an line (say Li), or a null intersection, in case of being a line, > find all the intersections of Li with the triangles edges. > it must be in the following sequence > > enter triangle 1, exit triangle 1 > enter triangle 2, exit triangle 2 > > in all other cases, the triangles are splited in the line Li > > After proceeding in this way you can use any criteria to sort the triangles, > i think this is the minimal algorithm, it takes about 1 days to be coded ant > two or three to get working :D Yes, that is the main idea. But this is a two week project, I believe. The number of cases balloons when going from 2D to 3D. First, one has to represent the triangles as planes (a hyperplane is always convenient). There is some linear algebra associated with computing that. Those would have to be saved with the triangle representations. Then there is determining the line of interestection (probably an easy matrix inversion). But there is the possibility of a singular matrix, which probably corresponds to the two planes being parallel. So, one computes the line of intersection of the plane, then there is still the issue determining exactly where the intersection is in terms of the original triangles. There is complete coverage, partial coverage, triangle broken into two pieces, etc. And when the split occurs, a four sided polygon could result, which means that four sided polygon would have to be represented as two triangles. It's easy envisioning how it would work, but doing it nicely is another issue. Not something to embark on without a good plan and mathematical representation of the problem. > I have a C++ 3D geometry class. but it uses overloaded operators > (everywhere), with this class I am able to implement, i think, what i > described above. if one want to translate the C++ to C and compile it i can > spend some time for writing it, and send yet this week. It would need proper licensing if it is a completed work. Theory of operation is just as good. Dan |
|
From: Alexandre F. <o.a...@gm...> - 2010-12-12 19:26:17
|
In Reply to Daniel: Hiperplane? i think planes are enough, because any representation will be 3D, ignoring colors and any extra data, the only thing we do here is copy that data (and eventually interpolate it as mentioned above). Or we can call some function which will process the data such as colors. If we concern with the 3D problem i'd discovered fighting with my PC that matrixe algebra is not the better aproach. It's very good for transformations, or vectors with to many components, or even dynamic programming, but for geometric problems is better to use geometric solution. regarding the licence of the 3D class, there is no problem, since i writen it from 0Byte, using pure C++, the only thing i didn't wrote was sqrt function. |
|
From: Daniel J S. <dan...@ie...> - 2010-12-12 20:02:36
|
Alexandre Felipe wrote: > In Reply to Daniel: > > Hiperplane? i think planes are enough, because any representation will be > 3D, ignoring colors and any extra data, the only thing we do here is copy > that data (and eventually interpolate it as mentioned above). Or we can call > some function which will process the data such as colors. A hyperplane is simply a general method of representing an N-1 dimensioned surface in a N dimensional space. As an example, say we want to represent a line in 2D space. We could pick two points to represent that line. We could use the formula y = mx + b. Or we could represent the line as w'v = b, where w = [1 -m]' and v = [y x]'. Convenience more than anything. > If we concern with the 3D problem i'd discovered fighting with my PC that > matrixe algebra is not the better aproach. It's very good for > transformations, or vectors with to many components, or even dynamic > programming, but for geometric problems is better to use geometric solution. For me, three dimensions is already too many components. :-) Dan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-12-12 18:22:57
|
On 12.12.2010 16:51, Alexandre Felipe wrote: > Find all the triangle pairs for wich the nearest vertex of firstis > nearer than the farthest of the vertexes of the second triangle, and the > farthest vertex of first is farther than the nearest of the vertexes of > the second triangle. [...] You've pretty much re-invented the Newell-Newell-Sancha algorithm that I've mentioned before, except that their textbook algorithm doesn't split the job into two passes (first splitting, second sorting) like you did. That avoids a good deal of unnecessary splitting. > After proceeding in this way you can use any criteria to sort the > triangles, i think this is the minimal algorithm, it takes about 1 days > to be coded ant two or three to get working :D If only. You would be amazed at the kind of precision problems you'll run into with this algorithm in practice. Just for starters, consider what all those tests will do with a pair of triangles that just so happen to share a vertex, or an edge. |
|
From: Ethan M. <merritt@u.washington.edu> - 2010-12-12 19:10:35
|
On Sunday, December 12, 2010, Hans-Bernhard Bröker wrote: > On 12.12.2010 16:51, Alexandre Felipe wrote: > > > Find all the triangle pairs for wich the nearest vertex of firstis > > nearer than the farthest of the vertexes of the second triangle, and the > > farthest vertex of first is farther than the nearest of the vertexes of > > the second triangle. > [...] > > You've pretty much re-invented the Newell-Newell-Sancha algorithm that > I've mentioned before, except that their textbook algorithm doesn't > split the job into two passes (first splitting, second sorting) like you > did. That avoids a good deal of unnecessary splitting. Is it possible that instead of modifying the pm3d code, one could modify the hidden-surface removal code in hidden3d? The hidden3d code is already finding all the relevant lines of intersection and occlusion. At the end of the hidden3d calculation there is a collection of edges, each of which is either all or part of an edge from the original set of polygons or an intersection of two polygons. At that point the code walks through the list and draws all the edges. Does it track enough information to also call term->filled_polygon() for each facet? If not, could the data structures be expanded to hold that tracking information? |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2010-12-12 19:28:31
|
On 12.12.2010 20:10, Ethan Merritt wrote: > Is it possible that instead of modifying the pm3d code, one could modify > the hidden-surface removal code in hidden3d? The hidden3d code is > already finding all the relevant lines of intersection and occlusion. Actually, no. hidden3d deals with hidden _line_ removal, only. It has no code whatsoever for either sorting or splitting triangles. > At the end of the hidden3d calculation there is a collection of edges, > each of which is either all or part of an edge from the original set > of polygons or an intersection of two polygons. At that point the code > walks through the list and draws all the edges. Again, not really. hidden3d draws individual surviving segments immediately when they're discovered (in_front() calls draw_edge() itself). There is no complete list of visible edge fragments in memory at any time. > Does it track enough information to also call term->filled_polygon() > for each facet? It doesn't even try to track facets. It tracks edge fragments, not polygon fragments. > If not, could the data structures be expanded to hold that tracking > information? "Expanding" wouldn't really do describing the job justice. It'd be more of a complete rewrite. |
|
From: Alexandre F. <o.a...@gm...> - 2010-12-13 21:07:30
|
input: -0.5 -0.5 1 1.2 1 3 1.2 -1 3 0.5 0.5 0.9 -1.2 -1 3.3 -1.2 1 3 e output: 0.013636 -0.046791 1.6043 1.2 -1 3 0.05122 -0.66212 1.6485 -1.2 1 3 0.013636 -0.046791 1.6043 0.05122 -0.66212 1.6485 0.05122 -0.66212 1.6485 -0.5 -0.5 1 0.013636 -0.046791 1.6043 0.013636 -0.046791 1.6043 1.2 1 3 1.2 -1 3 0.5 0.5 0.9 0.05122 -0.66212 1.6485 0.013636 -0.046791 1.6043 0.05122 -0.66212 1.6485 -1.2 -1 3.3 -1.2 1 3 e |
|
From: Alexandre F. <o.a...@gm...> - 2010-12-13 21:16:13
|
When i said some test i was very vague, excuse-me, the test is a sequence of triples (x,y,z), of several triangles, it's not a triangle strip, if you send some different data please explain how i should interpret it. |
|
From: Daniel J S. <dan...@ie...> - 2010-12-13 23:51:26
|
Alexandre, It's difficult to visualize what you are doing. For discussion lists it is best to create hunks of code or patches that people can use to test things out. (A patch is created by editing the source code then using the "diff" utility.) Also, if you are thinking that what you have might be a good start for a long term project, placing the patch and discussion in SourceForge helps for organization. Always think in terms of convenience for the audience. Making things easy for half a dozen people helps. The way you would incorporate code is to get the source, modify it and create a patch that can be uploaded to Sourceforge. The patch will then eventually be reviewed and discussed. Anyway, I took the input and output triangles you created and plotted those as follows: USE THE FOLLOWING TO CREATE THE TWO INPUT TRIANGLES YOU MENTION: splot '-' with pm3d, '-' with pm3d -0.5 -0.5 1 0.5 -0.5 -0.5 1 0.5 1.2 1 3 0.5 1.2 -1 3 0.5 e 0.5 0.5 0.9 0.75 0.5 0.5 0.9 0.75 -1.2 -1 3.3 0.75 -1.2 1 3 0.75 e ------- USE THE FOLLOWING TO CREATE THE SIX OUTPUT TRIANGLES YOU MENTION: splot '-' with pm3d, '-' with pm3d, '-' with pm3d, '-' with pm3d, '-' with pm3d, '-' with pm3d 0.013636 -0.046791 1.6043 0.5 0.013636 -0.046791 1.6043 0.5 1.2 -1 3 0.5 0.05122 -0.66212 1.6485 0.5 e -1.2 1 3 0.6 -1.2 1 3 0.6 0.013636 -0.046791 1.6043 0.6 0.05122 -0.66212 1.6485 0.6 e 0.05122 -0.66212 1.6485 0.7 0.05122 -0.66212 1.6485 0.7 -0.5 -0.5 1 0.7 0.013636 -0.046791 1.6043 0.7 e 0.013636 -0.046791 1.6043 0.8 0.013636 -0.046791 1.6043 0.8 1.2 1 3 0.8 1.2 -1 3 0.8 e 0.5 0.5 0.9 0.9 0.5 0.5 0.9 0.9 0.05122 -0.66212 1.6485 0.9 0.013636 -0.046791 1.6043 0.9 e 0.05122 -0.66212 1.6485 1.0 0.05122 -0.66212 1.6485 1.0 -1.2 -1 3.3 1.0 -1.2 1 3 1.0 e -------- There are several things about this. The two input triangles you give don't seem to intersect in their visible portions. That is, I can rotate the plot and find a point where the two triangles don't touch. If the triangles intersect, there should be no angle at which I can rotate the view without the two triangles touching. The second group of triangles don't really seem to match the first two input triangles. I can see one group of three triangles forms one of the triangles of the input. But the second group of three doesn't come close to forming the other input triangle. In fact, the second group of three triangles doesn't form an actual triangle. But upon rotation it does look as though where these polygons intersect is in fact the correct line. So there is something incorrect in what you are doing here. But we need a better means of communicating the concepts you are trying to convey. Try compiling the code and creating some examples. Theory of operation is good too, rather than just code. Dan Alexandre Felipe wrote: > I started writing something here, but i don't know if my input test is good > can someone send-me some triangle pairs to be rendered looking from the > origin > viewing z > 0; -z<x<z; -z<y<z > > There is a result attached in this e-mail (i hope it can be delivered), i > put two problematic triangle (who are called this triangles), after the > program separate it in six triangles, wich must render exactly de same > points but with the diference that, for these triangles there are no more > changes in the visibility, if one point of a triangle is in the front of the > other, all points of this triangle will be in the front of any point in the > other. > The idea is, since the change of the visibility happens in the > intersections, i only constructed a new set of triangles wich don't > intersect in a distance greater than 0.01% of an edge. > > I think it's convenient test it, and then start translating it to C, then i > send it for you, does someone know a software for this? > > now it is 192+181+160 lines length > > > > ------------------------------------------------------------------------ > > input: > -0.5 -0.5 1 > 1.2 1 3 > 1.2 -1 3 > 0.5 0.5 0.9 > -1.2 -1 3.3 > -1.2 1 3 > e > output: > 0.013636 -0.046791 1.6043 > 1.2 -1 3 > 0.05122 -0.66212 1.6485 > > -1.2 1 3 > 0.013636 -0.046791 1.6043 > 0.05122 -0.66212 1.6485 > > 0.05122 -0.66212 1.6485 > -0.5 -0.5 1 > 0.013636 -0.046791 1.6043 > > 0.013636 -0.046791 1.6043 > 1.2 1 3 > 1.2 -1 3 > > 0.5 0.5 0.9 > 0.05122 -0.66212 1.6485 > 0.013636 -0.046791 1.6043 > > 0.05122 -0.66212 1.6485 > -1.2 -1 3.3 > -1.2 1 3 > e > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: Stanislav M. <sta...@gm...> - 2010-12-08 11:41:32
|
On Tue, Dec 07, 2010 at 09:39:05PM +0100, Hans-Bernhard Bröker wrote: > On 07.12.2010 16:42, Stanislav Maslovski wrote: > > >So, I solved this issue by patching pm3d.c:pm3d_depth_queue_flush() > >so that sorting of quadrangles was done based on the average depth of > >4 corners. > > Unfortunately that's not really a solution. There is no particular > reason to prefer one sorting criterion over the other. Painter's > algorithm is plain and simply wrong --- no matter which property you > sort by. If it appears to work sometimes that's by happenstance, not > by design. Yes, I agree completely. "Solved" above meant that it helped me to produce a reasonable result in a reasonable time, and nothing more. >From what I have read from the docs it seems that the developers are against of impelementing a better algorithm (I noticed a statement like gnuplot is not a virtual reality software therefore...). If that is the current position, then I think it would be reasonable at least to make the depth sorting algorith configurable, do not you think so? -- Stanislav |
