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

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(28) 
2
(15) 
3
(4) 
4
(22) 
5
(22) 
6
(24) 
7
(4) 
8
(7) 
9
(6) 
10
(13) 
11
(4) 
12
(22) 
13
(55) 
14
(30) 
15
(24) 
16
(1) 
17
(2) 
18
(11) 
19
(28) 
20
(14) 
21
(18) 
22
(15) 
23
(7) 
24

25
(30) 
26
(26) 
27
(43) 
28
(26) 


From: Thatcher Ulrich <tu@tu...>  20020209 21:09:48

On Feb 09, 2002 at 12:58 0800, Josiah Manson wrote: > > #For example, sweptsphere > #vs. cappedcylinder is equivalent to ray vs. biggercappedcylinder. > > That's true if don't describe a capped cylinder to be the union of a > cylinder with spheres of equal radius at either end. Not to belabor this, but... no. It's true exactly when you *do* define a capped cylinder that way.  Thatcher Ulrich <tu@...> http://tulrich.com 
From: Josiah Manson <josiahmanson@ho...>  20020209 18:58:21

That's true if don't describe a capped cylinder to be the union of a = cylinder with spheres of equal radius at either end. An expanded = cylinder would have flat ends with rounded edges. An expanded line = segment would be a capped cylinder. #For example, sweptsphere #vs. cappedcylinder is equivalent to ray vs. biggercappedcylinder. Here, the line segments representing the bounds of the triangle are = properly expanded to capped cylinders. #Sweptsphere vs. triangle is equivalent to ray #vs. unionofoffsettrianglesandcappedcylinders. And so on  #hopefully you get the idea. 
From: Ulf Ochsenfahrt <ulfjack@gm...>  20020209 10:46:10

Mark Speir <maspeir@...> wrote on 08/02/02 22:44:26: > >OK, I have to admit that I was wrong. The algorithm that I found is based on >a center point and radii. DUH! I knew this. What I was trying to do is >inscribe the ellipse into a rectangle just like with Quickdraw. To this end, >it was working, just not like I was hoping. :( > >OK, now that I know what I really need.... > >Does anyone know where I can find an algorithm that takes a >rectangle(x1,y1,x2,y2 or top,left,bottom,right) and draws an ellipse into >it? > >Thanks, >Mark > > >_______________________________________________ >GDAlgorithmslist mailing list >GDAlgorithmslist@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 Hi! I just took the bresenham ellipse algorithm and did some minor modifications to the part where the pixels are actually drawn. I ain't no C coder, so sorry for the errors :P Before you start kiddin', I tried it in FreePascal and it worked. The original code can be found here: http://xarch.tugraz.ac.at/home/rurban/news/comp.graphics.algorithms/ellipse_bresenham.html The only interesting stuff are the changes in void symmetry(...). Ciao, Ulf. P.S.: Oh yes, and the calculation of a and b. // Note that left, top, right and bottom are used inclusively. // That means e.g. the rightmost pixel has coordinates // like (right, ?) and the leftmost pixel has coordinates // like (left, ?) ... void ellipse_in_rectangle(int left, int top, int right, int bottom) int a, b; void symmetry(int x, int y) { // all new PUT_PIXEL(right+xa, bottom+yb); PUT_PIXEL(left x+a, bottom+yb); PUT_PIXEL(left x+a, top y+b); PUT_PIXEL(right+xa, top y+b); } { a = (rightleft+1) / 2; // new b = (bottomtop+1) / 2; // new int x,y,a2,b2, S, T; a2 = a*a; b2 = b*b; x = 0; y = b; S = a2*(12*b) + 2*b2; T = b2  2*a2*(2*b1); symmetry(x,y); do { if (S<0) { S += 2*b2*(2*x+3); T += 4*b2*(x+1); x++; } else if (T<0) { S += 2*b2*(2*x+3)  4*a2*(y1); T += 4*b2*(x+1)  2*a2*(2*y3); x++; y; } else { S = 4*a2*(y1); T = 2*a2*(2*y3); y; } symmetry(x,y); } while (y>0); } 
From: Christopher Husband <chusband@ca...>  20020209 01:47:05

Hi all, I am truly confused, I have never had to do this before and I don't know how. If I had an isosceles triangle with lenght X that was always facing the camera, how do I determine the number of pixels it will take in a given screen resolution given the distance from camera to triangle? How about if is tilted away by an angel Theta or rotated by Phi? A solution would be helpful, but so would a link that could teach me how to solve these problems. Thanks all, Chirs 
From: Jon Watte <hplus@mi...>  20020209 00:57:02

Do you need to procedurally animate the model, or are you going to play back canned versions only? If you want the same behaviour, with procedural modification, you have no choice but to rederive the envelopes at runtime. Unless you want to store a spline per weight per vert  you really don't want to do that! One small simplication which might be possible is to store the weights at two "representative points" of the major bending joints, and lerp between them depending on how much the joint has bent. Something like this: onExportPerVert: bones = union( bones_with_weight_at_angle( 0 ), bones_with_weight_at_angle( 1 ) ); major_bone = find_major_bone_for_vert( ); weights0 = bone_weights_at_major_bone_angle( bones, bottom ); weights1 = bone_weights_at_major_bone_angle( bones, top ); onPlaybackPerVert: foreach bone: curAngle = angle_for( major_bone ); factor = (curAnglebottom)/(topbottom); weights = lerp( weights0, weights1, factor ); outVert = matrixBlend( bones, weights ); If this is not good enough, you might want to use 4 sets of weights and a cubic interpolation instead of a lerp based on the angle. You may also need to do a 4way lerp between two sets of weights if there more than one bone/joint whose angle has a "major" impact on this vert. It's all a speed/quality tradeoff. With a single character on a modern machine, it ought to be doable. Figure a microsecond per vert at four matrices (including the weight lerp), and 10,000 verts, that's about 10 milliseconds per frame you spend on this one dude. Depending on how advanced (or simple) you want to make this, and what your target is, I'm sure you can make it vary between the order of 0.1 us (Athlon XP, two bones, one angle per vertex) and 10 us (Pentium III 500, five bones, two angles). And as these numbers are WAY extrapolated from the numbers I actually have, they're probably a bit off, too... If you're playing back canned animations, you could store the entire mesh for each frame, which takes more memory but at least is computationally tractable. Cheers, / h+ > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of > Senftner, Blake > Sent: Friday, February 08, 2002 4:20 PM > To: R & D (GameBrains); GDAlgorithms > Subject: RE: [Algorithms] support for animating bone/vertex weights > > > An animator that I'm working with on a private project has this > great character I'd love to import into my engine, but the animations > use animating vertex weights. He uses animation of the bone weight > envelope to simulate secondary motion and muscle bulge. > > I'm aware that these anim effects can be done with other techniques, > but this character is already setup and animated with changing > envelopes. > > Blake > > Original Message > From: R & D (GameBrains) [mailto:research@...] > Sent: Friday, February 08, 2002 4:12 PM > To: Senftner, Blake; GDAlgorithms > Subject: Re: [Algorithms] support for animating bone/vertex weights > > > Blake, > Ah, I see. We don't animate the weights themselves. Interesting > though, what are you trying to do or what effect are you trying to > achieve? It seems that if one wasn't careful you would could end up > with stray verts or odd effects :) > Brett > >  Original Message  > From: "Senftner, Blake" <bsenftner@...> > To: "R & D (GameBrains)" <research@...>; "GDAlgorithms" > <gdalgorithmslist@...> > Sent: Saturday, February 09, 2002 7:51 AM > Subject: RE: [Algorithms] support for animating bone/vertex weights > > > I guess I did not explain the question well enough... > > I don't mean animating bones, I mean animating vertex weights. > > During the course of an animation, the vertex weights associated > with each vertex could change. > > frame 1 has vertex weights {w0,w1,w2,w3} for a specific vertex, > frame 10 has vertex weights {w0',w1',w2',w3'} for that same vertex > > where w0 != w0', w1 != w1', etc... > > Blake > > Original Message > From: R & D (GameBrains) [mailto:research@...] > Sent: Friday, February 08, 2002 3:45 PM > To: Senftner, Blake; GDAlgorithms > Subject: Re: [Algorithms] support for animating bone/vertex weights > > > > > > Does anyone support animating bone/vertex weights in their engines? > > yes. > > >If so, what technique? I can think of two methods: > >1) express the weights as a spline. > >2) support the bone envelope animation & do the vertex intersection > >with them during run time. > > each mesh has up to four bone weights exported for each vertex. export > done via Max and all data compressed into the mesh with the x,y,u,v,etc. > > Brett > > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > 
From: Senftner, Blake <bsenftner@pa...>  20020209 00:20:14

An animator that I'm working with on a private project has this great character I'd love to import into my engine, but the animations use animating vertex weights. He uses animation of the bone weight envelope to simulate secondary motion and muscle bulge. I'm aware that these anim effects can be done with other techniques, but this character is already setup and animated with changing envelopes. Blake Original Message From: R & D (GameBrains) [mailto:research@...] Sent: Friday, February 08, 2002 4:12 PM To: Senftner, Blake; GDAlgorithms Subject: Re: [Algorithms] support for animating bone/vertex weights Blake, Ah, I see. We don't animate the weights themselves. Interesting though, what are you trying to do or what effect are you trying to achieve? It seems that if one wasn't careful you would could end up with stray verts or odd effects :) Brett  Original Message =20 From: "Senftner, Blake" <bsenftner@...> To: "R & D (GameBrains)" <research@...>; "GDAlgorithms" <gdalgorithmslist@...> Sent: Saturday, February 09, 2002 7:51 AM Subject: RE: [Algorithms] support for animating bone/vertex weights I guess I did not explain the question well enough... I don't mean animating bones, I mean animating vertex weights. During the course of an animation, the vertex weights associated with each vertex could change. frame 1 has vertex weights {w0,w1,w2,w3} for a specific vertex, frame 10 has vertex weights {w0',w1',w2',w3'} for that same vertex where w0 !=3D w0', w1 !=3D w1', etc... Blake Original Message From: R & D (GameBrains) [mailto:research@...] Sent: Friday, February 08, 2002 3:45 PM To: Senftner, Blake; GDAlgorithms Subject: Re: [Algorithms] support for animating bone/vertex weights > Does anyone support animating bone/vertex weights in their engines? yes. >If so, what technique? I can think of two methods: >1) express the weights as a spline. >2) support the bone envelope animation & do the vertex intersection >with them during run time. each mesh has up to four bone weights exported for each vertex. export done via Max and all data compressed into the mesh with the x,y,u,v,etc. Brett 