You can subscribe to this list here.
2001 
_{Jan}

_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}


2002 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}

2003 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(1) 
_{Aug}
(1) 
_{Sep}

_{Oct}
(83) 
_{Nov}
(57) 
_{Dec}
(111) 
2004 
_{Jan}
(38) 
_{Feb}
(121) 
_{Mar}
(107) 
_{Apr}
(241) 
_{May}
(102) 
_{Jun}
(190) 
_{Jul}
(239) 
_{Aug}
(158) 
_{Sep}
(184) 
_{Oct}
(193) 
_{Nov}
(47) 
_{Dec}
(68) 
2005 
_{Jan}
(190) 
_{Feb}
(105) 
_{Mar}
(99) 
_{Apr}
(65) 
_{May}
(92) 
_{Jun}
(250) 
_{Jul}
(197) 
_{Aug}
(128) 
_{Sep}
(101) 
_{Oct}
(183) 
_{Nov}
(186) 
_{Dec}
(42) 
2006 
_{Jan}
(102) 
_{Feb}
(122) 
_{Mar}
(154) 
_{Apr}
(196) 
_{May}
(181) 
_{Jun}
(281) 
_{Jul}
(310) 
_{Aug}
(198) 
_{Sep}
(145) 
_{Oct}
(188) 
_{Nov}
(134) 
_{Dec}
(90) 
2007 
_{Jan}
(134) 
_{Feb}
(181) 
_{Mar}
(157) 
_{Apr}
(57) 
_{May}
(81) 
_{Jun}
(204) 
_{Jul}
(60) 
_{Aug}
(37) 
_{Sep}
(17) 
_{Oct}
(90) 
_{Nov}
(122) 
_{Dec}
(72) 
2008 
_{Jan}
(130) 
_{Feb}
(108) 
_{Mar}
(160) 
_{Apr}
(38) 
_{May}
(83) 
_{Jun}
(42) 
_{Jul}
(75) 
_{Aug}
(16) 
_{Sep}
(71) 
_{Oct}
(57) 
_{Nov}
(59) 
_{Dec}
(152) 
2009 
_{Jan}
(73) 
_{Feb}
(213) 
_{Mar}
(67) 
_{Apr}
(40) 
_{May}
(46) 
_{Jun}
(82) 
_{Jul}
(73) 
_{Aug}
(57) 
_{Sep}
(108) 
_{Oct}
(36) 
_{Nov}
(153) 
_{Dec}
(77) 
2010 
_{Jan}
(42) 
_{Feb}
(171) 
_{Mar}
(150) 
_{Apr}
(6) 
_{May}
(22) 
_{Jun}
(34) 
_{Jul}
(31) 
_{Aug}
(38) 
_{Sep}
(32) 
_{Oct}
(59) 
_{Nov}
(13) 
_{Dec}
(62) 
2011 
_{Jan}
(114) 
_{Feb}
(139) 
_{Mar}
(126) 
_{Apr}
(51) 
_{May}
(53) 
_{Jun}
(29) 
_{Jul}
(41) 
_{Aug}
(29) 
_{Sep}
(35) 
_{Oct}
(87) 
_{Nov}
(42) 
_{Dec}
(20) 
2012 
_{Jan}
(111) 
_{Feb}
(66) 
_{Mar}
(35) 
_{Apr}
(59) 
_{May}
(71) 
_{Jun}
(32) 
_{Jul}
(11) 
_{Aug}
(48) 
_{Sep}
(60) 
_{Oct}
(87) 
_{Nov}
(16) 
_{Dec}
(38) 
2013 
_{Jan}
(5) 
_{Feb}
(19) 
_{Mar}
(41) 
_{Apr}
(47) 
_{May}
(14) 
_{Jun}
(32) 
_{Jul}
(18) 
_{Aug}
(68) 
_{Sep}
(9) 
_{Oct}
(42) 
_{Nov}
(12) 
_{Dec}
(10) 
2014 
_{Jan}
(14) 
_{Feb}
(139) 
_{Mar}
(137) 
_{Apr}
(66) 
_{May}
(72) 
_{Jun}
(142) 
_{Jul}
(70) 
_{Aug}
(31) 
_{Sep}
(39) 
_{Oct}
(98) 
_{Nov}
(133) 
_{Dec}
(44) 
2015 
_{Jan}
(70) 
_{Feb}
(27) 
_{Mar}
(36) 
_{Apr}
(11) 
_{May}
(15) 
_{Jun}
(70) 
_{Jul}
(30) 
_{Aug}
(63) 
_{Sep}
(18) 
_{Oct}
(15) 
_{Nov}
(42) 
_{Dec}
(29) 
2016 
_{Jan}
(37) 
_{Feb}
(48) 
_{Mar}
(59) 
_{Apr}
(28) 
_{May}
(30) 
_{Jun}
(43) 
_{Jul}
(47) 
_{Aug}
(14) 
_{Sep}
(21) 
_{Oct}
(26) 
_{Nov}
(10) 
_{Dec}
(2) 
2017 
_{Jan}
(26) 
_{Feb}
(27) 
_{Mar}
(44) 
_{Apr}
(11) 
_{May}
(29) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1

2

3

4
(1) 
5

6

7
(1) 
8
(2) 
9
(15) 
10
(5) 
11

12
(8) 
13
(3) 
14
(8) 
15

16

17

18

19

20

21
(1) 
22

23

24

25

26

27

28
(4) 
29
(14) 
30

31


From: Daniel J Sebald <daniel.sebald@ie...>  20101212 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 N1 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: HansBernhard Bröker <HBBroeker@t...>  20101212 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 hiddensurface 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 Felipe <o.alexandre.felipe@gm...>  20101212 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: Ethan Merritt <merritt@u.washington.edu>  20101212 19:10:35

On Sunday, December 12, 2010, HansBernhard 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 reinvented the NewellNewellSancha 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 hiddensurface 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: HansBernhard Bröker <HBBroeker@t...>  20101212 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 reinvented the NewellNewellSancha 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: Daniel J Sebald <daniel.sebald@ie...>  20101212 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: Stanislav Maslovski <stanislav.maslovski@gm...>  20101212 17:08:37

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: Alexandre Felipe <o.alexandre.felipe@gm...>  20101212 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. 