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}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

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

_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(44) 
2
(37) 
3
(50) 
4
(5) 
5
(7) 
6
(14) 
7
(34) 
8
(18) 
9
(43) 
10
(75) 
11
(7) 
12
(3) 
13
(43) 
14
(19) 
15
(29) 
16
(21) 
17
(54) 
18
(12) 
19

20
(36) 
21
(9) 
22
(18) 
23
(30) 
24
(29) 
25
(18) 
26
(18) 
27
(38) 
28
(23) 
29
(21) 
30
(11) 
31
(19) 

From: Charles Bloom <cbloom@cb...>  20010808 23:37:56

As a sort of add on : I hear a rumour that D3D adds a rasterizer convention conversion to its pipe since its 0.5 convention is different that OGL and most cards only support OGL. This is basically just a tweak to your projection matrix. Anyway, the rumor is that this is implicitly tacked on all vshaders, but you can disable it with some flag.  Charles Bloom cbloom@... http://www.cbloom.com 
From: Dave Forsey <dforsey@ra...>  20010808 20:13:30

Re: BSpline_vs_Bezier > My question therefore is: why use BSpline (or NURBS) over Bezier (or > rational Bezier)? The answer is highly application specific, so here I'll just address technical issues reguarding continuity properties. Cubic Bsplines automatically maintain C1 & C2 (curvature) continuity over the curve/surface. Nonuniform Bsplines let you have hard edges along isoparms without duplicating control points (which introduces nasty flat sections). A Bezier representation of a bspline surface will use more control points than the bspline. Bezier patches are independent unless you procedurally control the placement of neighbouring control points. C1 or G1 continuity is easily achieved across borders for cubic (and higher order). G2 or C2 continuity between patches requires procedurally fixing the surrounding 16 bezier patches. On corners where multiple cubic bezier patches meet you can run out of degrees of freedom and can only approximate C1 continuity. The flip side of this is that you have direct control over the hardness of each edge.. (with great power comes great responsibility... :) Bezier curves have a "tighter" control graph than Bsplines. i.e. the convex hull is, in general, closer to the curve/surface that the equivalent bspline control graph. (Note that a cubic NURBS curve with triple knots is a Bezier). NURBS have a rectangular control mesh and thus have a restricted topology unless you stitch them together as you do with Bezier patches. You can only add entire row or columns to tensorproduct Bsplines or bezier patches (unless you use a hiearchical form). Subdivision surfaces are a superset of splines that relax the topology restrictions of tensorproduct bspline/bezier surfaces. CatmullClark surfaces are a generalization of cubic Bsplines and there exists versions corresponding to NURBS surfaces as well. A very cool extension of CatmullClark lets you control the sharpness of individual edges. > ____ > > From: Martin Fuller <mfuller@...> > > My memory's failing but don't the tangents also have to be the same = > distance apart to maintain C1? (Possibly not I can't remember) The internal control points must be colinear and equidistant from the shared edge point to be C1. If they are only colinear, then the curve/ surface is G1, the tangents match but not the parametric "speed" of the curve surface at the seam. > ____ > > From: Tom Forsyth <tomf@...> > Remember that almsot all of these spline primitives can be converted > (offline) into rational Bezier curves, so model in whatever primitive = > you like, then process into Bezier curves for actual rendering. All of these formulations are methods for presenting polynomial functions with geometrically meaningful parameters, and so can generally be converted into each other (though it may not be a onetoone mapping). Bezier is the "friendliest" for rendering because of the tight convex hull, the direct availability of the tangents, and the simple subdivision algorithm. > ____ > > From: "Philippe Beaudoin" <Philippe.Beaudoin@...> > ReplyTo: gdalgorithmslist@... > > What do you mean by "almost all of these spline"? I can certainly see how= > to > convert an order N BSpline with knots {0,...,0,1,...,1} into an order N > Bezier but I can't see how to do it in the general case. (Maybe I've not > reached this chapter in the book yet ;)) Each "patch" of the NURBS surface converts to a single rational bezier patch of the same order. It turns out to be a simple matrix operation on the control points to change the basis used to represent the polynomial. > As for converting subdivision into Bezier, I guess you're talking about > "approximating" the subdivision limit surface. If not, I'd really want to > know how to do this. "Patching Catmullclark Meshes" Jorg Peters, SIGGRAPH 2000. The NURB representation is exact except around an extraordinary point where it is a C1 approximation to the C1 surface around that point. Dave Forsey Radical Entertainment. 
From: Scott Le Grand <varelse@be...>  20010808 20:01:41

At 05:50 PM 8/8/2001 +0100, you wrote: >Hi there, > >It's been a (very) long while since I've had to write a polygon scan >conversion routine  3d graphic cards make you lazy you know  and I think >I'm suffering from slightly inaccurate results. I've gone through the >usual books in an effort to reengage those scan conversion grey cells of >a few years ago and I'm still not sure where exactly I'm going slightly >wrong. I can tell it's slightly off by comparing it to the line (drawn >using bog old bresenham) outline of the subject polygon. > >Your help would be greatly appreciated.... > Go read Chris Hecker's articles on perspective texture mapping. I used 'em as the basis for an entire rasterizer on an embedded system. The result was both 10x faster than its predecessor and devoid of rasterization errors. Scott 
From: Tom Forsyth <tomf@mu...>  20010808 19:10:56

> From: Pierre Terdiman [mailto:p.terdiman@...] > > > > It's just a matter of adding 0.5 and 0.5*delta to various starting > positions > > (as appropriate). It makes life easier if you actually draw > some lines on > > bigsquare graph paper  you can see where to add the > various offsets. > > Errr ? It depends on your subpixel conventions. You can get > rid of all 0.5 > fixes by choosing appropriate rasterization rules  and it's actually > recommended since it makes the code way easier/cleaner. Oh, certainly  what I mean is that the offsets might explain the differences between the two algorithms. It's pretty easy to let a halfpixel offset creep into a Bresenham algo without actually realising it. > No time to spot the bug in Warrick's code anyway, but the > paper hint is a > good one. Drawing things once and for all really helps. I had a quick look at the code, and he's doing generally the right things. There might still be a typo  I didn't look in detail, but I don't think there's anything fundamentally wrong. > Frenchcompliant algoers can have a look at that old one : > http://www.codercorner.com/Subpixel.txt > > I think Chris Hecker also wrote some papers about > scanconversion in GDMag > some years ago. The good old Fatmap2.txt was also the > reference document for > demomakers by that time, and maybe it can help as well. > > In any case it definitely sounds like subpixelrelated > inaccuracies so check > your conventions and current FPU rounding mode. > > Sorry, no time for better help :( > > P. Tom Forsyth  Muckyfoot bloke. What's he up to now (and can I have a go)? http://www.eidosinteractive.com/downloads/search.html?gmid=86 
From: Pierre Terdiman <p.terdiman@wa...>  20010808 18:55:16

> It's just a matter of adding 0.5 and 0.5*delta to various starting positions > (as appropriate). It makes life easier if you actually draw some lines on > bigsquare graph paper  you can see where to add the various offsets. Errr ? It depends on your subpixel conventions. You can get rid of all 0.5 fixes by choosing appropriate rasterization rules  and it's actually recommended since it makes the code way easier/cleaner. No time to spot the bug in Warrick's code anyway, but the paper hint is a good one. Drawing things once and for all really helps. Frenchcompliant algoers can have a look at that old one : http://www.codercorner.com/Subpixel.txt I think Chris Hecker also wrote some papers about scanconversion in GDMag some years ago. The good old Fatmap2.txt was also the reference document for demomakers by that time, and maybe it can help as well. In any case it definitely sounds like subpixelrelated inaccuracies so check your conventions and current FPU rounding mode. Sorry, no time for better help :( P. 
From: Tom Forsyth <tomf@mu...>  20010808 18:19:54

It's just a matter of adding 0.5 and 0.5*delta to various starting positions (as appropriate). It makes life easier if you actually draw some lines on bigsquare graph paper  you can see where to add the various offsets. Tom Forsyth  Muckyfoot bloke. What's he up to now (and can I have a go)? http://www.eidosinteractive.com/downloads/search.html?gmid=86 Original Message From: Warrick Buchanan [mailto:warrick@...] Sent: 08 August 2001 17:51 To: gdalgorithmslist@... Subject: [Algorithms] Polygon scan conversion accuracy... Hi there, It's been a (very) long while since I've had to write a polygon scan conversion routine  3d graphic cards make you lazy you know  and I think I'm suffering from slightly inaccurate results. I've gone through the usual books in an effort to reengage those scan conversion grey cells of a few years ago and I'm still not sure where exactly I'm going slightly wrong. I can tell it's slightly off by comparing it to the line (drawn using bog old bresenham) outline of the subject polygon. Your help would be greatly appreciated.... here's the snippets of relevant code: (btw it's currently all floating point not fixed point  I know that's evil but it doesn't have to be fast and it is still possible to get it accurate!) struct Vertex { float x; float y; } void rightSection(const Vertex *vertex, const unsigned long vertices, float &x, unsigned long &v0, unsigned long &v1, unsigned long &height, float &dxdy ) { do { v0 = v1; v1 = (v1 == vertices  1) ? 0 : v1 + 1; height = ceil(vertex[v1].y)  ceil(vertex[v0].y); } while(!height); dxdy = (vertex[v1].x  vertex[v0].x)/(vertex[v1].y  vertex[v0].y); x = vertex[v0].x + (ceil(vertex[v0].y)  vertex[v0].y)*dxdy; } void leftSection(const Vertex *vertex, const unsigned long vertices, float &x, unsigned long &v0, unsigned long &v1, unsigned long &height, float &dxdy ) { do { v0 = v1; v1 = v1 ? v1  1 : vertices  1; height = ceil(vertex[v1].y)  ceil(vertex[v0].y); } while(!height); dxdy = (vertex[v1].x  vertex[v0].x)/(vertex[v1].y  vertex[v0].y); x = vertex[v0].x + (ceil(vertex[v0].y)  vertex[v0].y)*dxdy; } // Obviously not optimised yet! void fill(Image_ARGB8 &image, const float lx, const float rx, const unsigned long y, const Pixel_ARGB8 &colour) { Pixel_ARGB8 *data = image.data + long(ceil(lx)) + y*image.width; unsigned long pixels = ceil(rx)  ceil(lx); if(pixels) while(pixels) *data++ = colour; } // Assumes polygon is convex and of the correct winding! void polygon(Image_ARGB8 &image, const Vertex *vertex, const unsigned long vertices, const Pixel_ARGB8 &colour) { unsigned long ymax = 0; unsigned long ymin = 0; // Find ymin and ymax vertices for(unsigned long v = 1; v < vertices; v++) { if(vertex[v].y > vertex[ymax].y) ymax = v; if(vertex[v].y < vertex[ymin].y) ymin = v; } unsigned long l0 = ymin; unsigned long l1 = ymin ? ymin  1 : vertices  1; unsigned long r0 = ymin; unsigned long r1 = (ymin == vertices  1) ? 0 : ymin + 1; unsigned long rows = ceil(vertex[ymax].y)  ceil(vertex[ymin].y); unsigned long y = ceil(vertex[ymin].y); unsigned long lheight, rheight; float ldxdy, rdxdy; float lx, rx; if(!rows) return; lheight = ceil(vertex[l1].y)  ceil(vertex[l0].y); if(lheight) { ldxdy = (vertex[l1].x  vertex[l0].x)/(vertex[l1].y  vertex[l0].y); lx = vertex[l0].x + (ceil(vertex[l0].y)  vertex[l0].y)*ldxdy; } else leftSection(vertex, vertices, lx, l0, l1, lheight, ldxdy); rheight = ceil(vertex[r1].y)  ceil(vertex[r0].y); if(rheight) { rdxdy = (vertex[r1].x  vertex[r0].x)/(vertex[r1].y  vertex[r0].y); rx = vertex[r0].x + (ceil(vertex[r0].y)  vertex[r0].y)*rdxdy; } else rightSection(vertex, vertices, rx, r0, r1, rheight, rdxdy); while(rows) { if(rheight == 0) rightSection(vertex, vertices, rx, r0, r1, rheight, rdxdy); if(lheight == 0) leftSection(vertex, vertices, lx, l0, l1, lheight, ldxdy); if(lx < rx) fill(image, lx, rx, y, colour); rx += rdxdy; lx += ldxdy; y++; } } Thanks, Warrick. 
From: Warrick Buchanan <warrick@co...>  20010808 16:51:56

Hi there, It's been a (very) long while since I've had to write a polygon scan = conversion routine  3d graphic cards make you lazy you know  and I = think I'm suffering from slightly inaccurate results. I've gone through = the usual books in an effort to reengage those scan conversion grey = cells of a few years ago and I'm still not sure where exactly I'm going = slightly wrong. I can tell it's slightly off by comparing it to the = line (drawn using bog old bresenham) outline of the subject polygon. Your help would be greatly appreciated.... here's the snippets of relevant code: (btw it's currently all floating point not fixed point  I know that's = evil but it doesn't have to be fast and it is still possible to get it = accurate!) struct Vertex { float x; float y; } void rightSection(const Vertex *vertex, const unsigned long vertices, float &x, unsigned long &v0, unsigned long &v1, unsigned long &height, float &dxdy ) { do { v0 =3D v1; v1 =3D (v1 =3D=3D vertices  1) ? 0 : v1 + 1; height =3D ceil(vertex[v1].y)  ceil(vertex[v0].y); } while(!height); dxdy =3D (vertex[v1].x  vertex[v0].x)/(vertex[v1].y  vertex[v0].y); x =3D vertex[v0].x + (ceil(vertex[v0].y)  vertex[v0].y)*dxdy;=20 } void leftSection(const Vertex *vertex, const unsigned long vertices, float &x, unsigned long &v0, unsigned long &v1, unsigned long &height, float &dxdy ) { do { v0 =3D v1; v1 =3D v1 ? v1  1 : vertices  1; height =3D ceil(vertex[v1].y)  ceil(vertex[v0].y); } while(!height); dxdy =3D (vertex[v1].x  vertex[v0].x)/(vertex[v1].y  vertex[v0].y); x =3D vertex[v0].x + (ceil(vertex[v0].y)  vertex[v0].y)*dxdy; } // Obviously not optimised yet! void fill(Image_ARGB8 &image, const float lx, const float rx, const = unsigned long y, const Pixel_ARGB8 &colour) { Pixel_ARGB8 *data =3D image.data + long(ceil(lx)) + y*image.width; unsigned long pixels =3D ceil(rx)  ceil(lx); if(pixels) while(pixels) *data++ =3D colour; } // Assumes polygon is convex and of the correct winding! void polygon(Image_ARGB8 &image, const Vertex *vertex, const unsigned = long vertices, const Pixel_ARGB8 &colour) { unsigned long ymax =3D 0; unsigned long ymin =3D 0; =20 // Find ymin and ymax vertices for(unsigned long v =3D 1; v < vertices; v++) { if(vertex[v].y > vertex[ymax].y) ymax =3D v; if(vertex[v].y < vertex[ymin].y) ymin =3D v; } =20 unsigned long l0 =3D ymin; unsigned long l1 =3D ymin ? ymin  1 : vertices  1; unsigned long r0 =3D ymin; unsigned long r1 =3D (ymin =3D=3D vertices  1) ? 0 : ymin + 1; =20 unsigned long rows =3D ceil(vertex[ymax].y)  ceil(vertex[ymin].y); unsigned long y =3D ceil(vertex[ymin].y); unsigned long lheight, rheight; float ldxdy, rdxdy; float lx, rx; =20 if(!rows) return; =20 =20 lheight =3D ceil(vertex[l1].y)  ceil(vertex[l0].y); =20 if(lheight) { ldxdy =3D (vertex[l1].x  vertex[l0].x)/(vertex[l1].y  vertex[l0].y); lx =3D vertex[l0].x + (ceil(vertex[l0].y)  vertex[l0].y)*ldxdy; } else leftSection(vertex, vertices, lx, l0, l1, lheight, ldxdy); =20 =20 rheight =3D ceil(vertex[r1].y)  ceil(vertex[r0].y); =20 if(rheight) { rdxdy =3D (vertex[r1].x  vertex[r0].x)/(vertex[r1].y  vertex[r0].y); rx =3D vertex[r0].x + (ceil(vertex[r0].y)  vertex[r0].y)*rdxdy; } else rightSection(vertex, vertices, rx, r0, r1, rheight, rdxdy); =20 =20 while(rows) { if(rheight =3D=3D 0) rightSection(vertex, vertices, rx, r0, r1, = rheight, rdxdy); if(lheight =3D=3D 0) leftSection(vertex, vertices, lx, l0, l1, = lheight, ldxdy); =20 if(lx < rx) fill(image, lx, rx, y, colour); =20 rx +=3D rdxdy; lx +=3D ldxdy; =20 y++; } } Thanks, Warrick. 
From: Don Williamson <don@do...>  20010808 16:24:26

I apologise for my trigger happiness with the subject line. > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of Don > Williamson > Sent: 08 August 2001 17:08 > To: gdalgorithmslist@... > Subject: [Algorithms] RE: [Algorithms] RE: [Algorithms] RE: [Algorithms] > BSpline vs Bézier > > > > If you have access to the ACM Digital Library, you may find the following > paper interesting: > > Realtime rendering of trimmed surfaces > > http://www.acm.org/pubs/citations/proceedings/graph/74333/p107rockwood/ > > They discuss the modular rendering of various surface representations > (NURBS) by converting to bezier form. > > Seeya, >  Don > > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...]On Behalf Of Tom > > Forsyth > > Sent: 08 August 2001 16:07 > > To: gdalgorithmslist@... > > Subject: [Algorithms] RE: [Algorithms] RE: [Algorithms] BSpline vs > > Bézier > > > > > > I believe you can convert any order N Bspline (with any knot > > sequence) into > > a series of Bezier patches of order N. At least, that's my memories from > > reading one of the standard books, though I didn't look into > the maths at > > the time. > > > > The specific example of the subdiv surfaces was a paper on converting > > CatmullClarke (one day I'll spell their names right) surfaces > into Bezier > > splines (or maybe into NURBS, and then to Bezier). I believe > it's an exact > > conversion, rather than an approximation, which is quite > > impressive. Again, > > I only skimmed the paper, and I've forgotten the name, author, > > etc. now. I'm > > sure a hunt with Google or similar will turn it up. > > > > Tom Forsyth  Muckyfoot bloke. > > > > What's he up to now (and can I have a go)? > > http://www.eidosinteractive.com/downloads/search.html?gmid=86 > > > > > Original Message > > > From: Philippe Beaudoin [mailto:Philippe.Beaudoin@...] > > > Sent: 08 August 2001 15:17 > > > To: gdalgorithmslist@... > > > Subject: [Algorithms] RE: [Algorithms] BSpline vs Bézier > > > > > > > > > What do you mean by "almost all of these spline"? I can > > > certainly see how to > > > convert an order N BSpline with knots {0,...,0,1,...,1} into > > > an order N > > > Bézier but I can't see how to do it in the general case. > > > (Maybe I've not > > > reached this chapter in the book yet ;)) > > > > > > As for converting subdivision into Bézier, I guess you're > > > talking about > > > "approximating" the subdivision limit surface. If not, I'd > > > really want to > > > know how to do this. > > > > > > Philippe > > > > > > > > > > Original Message > > > > From: gdalgorithmslistadmin@... > > > > [mailto:gdalgorithmslistadmin@...]On > > > Behalf Of Tom > > > > Forsyth > > > > Sent: 8Aug2001 09:21 > > > > To: gdalgorithmslist@... > > > > Subject: [Algorithms] RE: [Algorithms] BSpline vs Bézier > > > > > > > > > > > > Remember that almsot all of these spline primitives can be converted > > > > (offline) into rational Bezier curves, so model in whatever > > > primitive you > > > > like, then process into Bezier curves for actual rendering. > > > > > > > > Trimming is still a problem for Bezier curves as well of course. > > > > Subdivision > > > > surfaces solve a lot of these problems, but the tools > > > aren't really there > > > > yet. A lot of them can also be converted into Bezier curves > > > for rendering > > > > :) > > > > > > > > Tom Forsyth  Muckyfoot bloke. > > > > > > > > What's he up to now (and can I have a go)? > > > > http://www.eidosinteractive.com/downloads/search.html?gmid=86 > > > > > > > > > _______________________________________________ > > > GDAlgorithmslist mailing list > > > GDAlgorithmslist@... > > > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Don Williamson <don@do...>  20010808 16:08:20

If you have access to the ACM Digital Library, you may find the following paper interesting: Realtime rendering of trimmed surfaces http://www.acm.org/pubs/citations/proceedings/graph/74333/p107rockwood/ They discuss the modular rendering of various surface representations (NURBS) by converting to bezier form. Seeya,  Don > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of Tom > Forsyth > Sent: 08 August 2001 16:07 > To: gdalgorithmslist@... > Subject: [Algorithms] RE: [Algorithms] RE: [Algorithms] BSpline vs > Bézier > > > I believe you can convert any order N Bspline (with any knot > sequence) into > a series of Bezier patches of order N. At least, that's my memories from > reading one of the standard books, though I didn't look into the maths at > the time. > > The specific example of the subdiv surfaces was a paper on converting > CatmullClarke (one day I'll spell their names right) surfaces into Bezier > splines (or maybe into NURBS, and then to Bezier). I believe it's an exact > conversion, rather than an approximation, which is quite > impressive. Again, > I only skimmed the paper, and I've forgotten the name, author, > etc. now. I'm > sure a hunt with Google or similar will turn it up. > > Tom Forsyth  Muckyfoot bloke. > > What's he up to now (and can I have a go)? > http://www.eidosinteractive.com/downloads/search.html?gmid=86 > > > Original Message > > From: Philippe Beaudoin [mailto:Philippe.Beaudoin@...] > > Sent: 08 August 2001 15:17 > > To: gdalgorithmslist@... > > Subject: [Algorithms] RE: [Algorithms] BSpline vs Bézier > > > > > > What do you mean by "almost all of these spline"? I can > > certainly see how to > > convert an order N BSpline with knots {0,...,0,1,...,1} into > > an order N > > Bézier but I can't see how to do it in the general case. > > (Maybe I've not > > reached this chapter in the book yet ;)) > > > > As for converting subdivision into Bézier, I guess you're > > talking about > > "approximating" the subdivision limit surface. If not, I'd > > really want to > > know how to do this. > > > > Philippe > > > > > > > Original Message > > > From: gdalgorithmslistadmin@... > > > [mailto:gdalgorithmslistadmin@...]On > > Behalf Of Tom > > > Forsyth > > > Sent: 8Aug2001 09:21 > > > To: gdalgorithmslist@... > > > Subject: [Algorithms] RE: [Algorithms] BSpline vs Bézier > > > > > > > > > Remember that almsot all of these spline primitives can be converted > > > (offline) into rational Bezier curves, so model in whatever > > primitive you > > > like, then process into Bezier curves for actual rendering. > > > > > > Trimming is still a problem for Bezier curves as well of course. > > > Subdivision > > > surfaces solve a lot of these problems, but the tools > > aren't really there > > > yet. A lot of them can also be converted into Bezier curves > > for rendering > > > :) > > > > > > Tom Forsyth  Muckyfoot bloke. > > > > > > What's he up to now (and can I have a go)? > > > http://www.eidosinteractive.com/downloads/search.html?gmid=86 > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Charles Ocheret <chuck@wr...>  20010808 15:58:03

The BSpline representation is a little more flexible in that it is = more straighforward to do things like degree elevation/reduction, point insertion, maintaining local control of the curve. Of course the 2 representations are ultimately interchangeable after doing some math. = All of my BSpline rendering code converts the BSpline representation into = a Bezier representation before rendering because of the simplicity of 'recursive' techniques for subdividing Bezier curves. ~chuck Original Message From: Philippe Beaudoin [mailto:Philippe.Beaudoin@...] Sent: Tuesday, August 07, 2001 1:43 PM To: gdalgorithmslist@... Subject: [Algorithms] BSpline vs B=E9zier Reading The NURBS Book I came across this strange explanation for the introduction of BSplines. The authors mention it would be hard to use piecewise B=E9zier while maintaining C1 continuity in interactive shape design. Now, I remember using Adobe Illustrator and the basic curve primitive = looked a lot like piecewise B=E9zier splines. In this software, C1 continuity = could be maintained during interaction by "locking together" two handles. = This way, when moving the tangent at the end of curve i, the tangent at the beginning of curve i+1 moved too in order to stay parallel and maintain continuity. This worked with 1D curves in a 2D space, but I don't see = why the process could not be extended to 2D patches in 3D space. My question therefore is: why use BSpline (or NURBS) over B=E9zier (or rational B=E9zier)? Philippe Beaudoin Matrox Graphics _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist ************************************************************************= **** IMPORTANT NOTICES: ************************************************************************= **** This message is intended only for the addressee. Please notify the = sender by email if you are not the intended recipient. If you are not the intended recipient, you may not copy, disclose, or distribute this message or its content to any other person and any such actions may be unlawful. Electronic mail sent through the Internet is not secure. WR Hambrecht + Co (WRH) does not accept time sensitive, actionoriented messages or transaction orders, including orders to purchase or sell securities, via email. WRH reserves the right to monitor and review the content of all = messages sent to or from this email address. Messages sent to or from this = email address may be stored on the WRH email system. ************************************************************************= **** 
From: Tom Forsyth <tomf@mu...>  20010808 15:11:09

I believe you can convert any order N Bspline (with any knot sequence) = into a series of Bezier patches of order N. At least, that's my memories = from reading one of the standard books, though I didn't look into the maths = at the time. The specific example of the subdiv surfaces was a paper on converting CatmullClarke (one day I'll spell their names right) surfaces into = Bezier splines (or maybe into NURBS, and then to Bezier). I believe it's an = exact conversion, rather than an approximation, which is quite impressive. = Again, I only skimmed the paper, and I've forgotten the name, author, etc. = now. I'm sure a hunt with Google or similar will turn it up. Tom Forsyth  Muckyfoot bloke. What's he up to now (and can I have a go)? http://www.eidosinteractive.com/downloads/search.html?gmid=3D86 > Original Message > From: Philippe Beaudoin [mailto:Philippe.Beaudoin@...] > Sent: 08 August 2001 15:17 > To: gdalgorithmslist@... > Subject: [Algorithms] RE: [Algorithms] BSpline vs B=E9zier >=20 >=20 > What do you mean by "almost all of these spline"? I can=20 > certainly see how to > convert an order N BSpline with knots {0,...,0,1,...,1} into=20 > an order N > B=E9zier but I can't see how to do it in the general case.=20 > (Maybe I've not > reached this chapter in the book yet ;)) >=20 > As for converting subdivision into B=E9zier, I guess you're=20 > talking about > "approximating" the subdivision limit surface. If not, I'd=20 > really want to > know how to do this. >=20 > Philippe >=20 >=20 > > Original Message > > From: gdalgorithmslistadmin@... > > [mailto:gdalgorithmslistadmin@...]On=20 > Behalf Of Tom > > Forsyth > > Sent: 8Aug2001 09:21 > > To: gdalgorithmslist@... > > Subject: [Algorithms] RE: [Algorithms] BSpline vs B=E9zier > > > > > > Remember that almsot all of these spline primitives can be = converted > > (offline) into rational Bezier curves, so model in whatever=20 > primitive you > > like, then process into Bezier curves for actual rendering. > > > > Trimming is still a problem for Bezier curves as well of course. > > Subdivision > > surfaces solve a lot of these problems, but the tools=20 > aren't really there > > yet. A lot of them can also be converted into Bezier curves=20 > for rendering > > :) > > > > Tom Forsyth  Muckyfoot bloke. > > > > What's he up to now (and can I have a go)? > > http://www.eidosinteractive.com/downloads/search.html?gmid=3D86 >=20 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >=20 
From: Philippe Beaudoin <Philippe.Beaudoin@Matrox.COM>  20010808 14:18:27

What do you mean by "almost all of these spline"? I can certainly see how= to convert an order N BSpline with knots {0,...,0,1,...,1} into an order N B=E9zier but I can't see how to do it in the general case. (Maybe I've no= t reached this chapter in the book yet ;)) As for converting subdivision into B=E9zier, I guess you're talking about "approximating" the subdivision limit surface. If not, I'd really want to know how to do this. Philippe > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...]On Behalf Of Tom > Forsyth > Sent: 8Aug2001 09:21 > To: gdalgorithmslist@... > Subject: [Algorithms] RE: [Algorithms] BSpline vs B=E9zier > > > Remember that almsot all of these spline primitives can be converted > (offline) into rational Bezier curves, so model in whatever primitive y= ou > like, then process into Bezier curves for actual rendering. > > Trimming is still a problem for Bezier curves as well of course. > Subdivision > surfaces solve a lot of these problems, but the tools aren't really the= re > yet. A lot of them can also be converted into Bezier curves for renderi= ng > :) > > Tom Forsyth  Muckyfoot bloke. > > What's he up to now (and can I have a go)? > http://www.eidosinteractive.com/downloads/search.html?gmid=3D86 
From: Tom Forsyth <tomf@mu...>  20010808 13:24:49

Remember that almsot all of these spline primitives can be converted (offline) into rational Bezier curves, so model in whatever primitive = you like, then process into Bezier curves for actual rendering. Trimming is still a problem for Bezier curves as well of course. = Subdivision surfaces solve a lot of these problems, but the tools aren't really = there yet. A lot of them can also be converted into Bezier curves for = rendering :) Tom Forsyth  Muckyfoot bloke. What's he up to now (and can I have a go)? http://www.eidosinteractive.com/downloads/search.html?gmid=3D86 > Original Message > From: Philippe Beaudoin [mailto:Philippe.Beaudoin@...] > Sent: 07 August 2001 21:43 > To: gdalgorithmslist@... > Subject: [Algorithms] BSpline vs B=E9zier >=20 >=20 > Reading The NURBS Book I came across this strange explanation for the > introduction of BSplines. The authors mention it would be hard to = use > piecewise B=E9zier while maintaining C1 continuity in interactive = shape > design. >=20 > Now, I remember using Adobe Illustrator and the basic curve=20 > primitive looked > a lot like piecewise B=E9zier splines. In this software, C1=20 > continuity could > be maintained during interaction by "locking together" two=20 > handles. This > way, when moving the tangent at the end of curve i, the tangent at = the > beginning of curve i+1 moved too in order to stay parallel=20 > and maintain > continuity. This worked with 1D curves in a 2D space, but I=20 > don't see why > the process could not be extended to 2D patches in 3D space. >=20 > My question therefore is: why use BSpline (or NURBS) over B=E9zier = (or > rational B=E9zier)? >=20 >=20 > Philippe Beaudoin > Matrox Graphics >=20 >=20 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >=20 
From: Andrew Jones <andrew@em...>  20010808 12:51:06

From: "Sivef=E4ldt Ola" <Ola.Sivefaldt@...> > My question is: How do i calculate the velocity of a point that is rotating > around an Origin that is translating? If you have the vector from the origin to the point (v1) and the angular velocity of the point around the origin in vector form(v2) (axis vector, length=3D speed) then you can get the linear velocity of the point due to rotation by doin= g the cross product of v1 and v2 above. Then you just add on the linear velocity of the origin. This is the vector form of basic circular motion stuff. (v=3D r * omega) Andrew Jones 
From: <Ola.S<ivefaldt@gu...>  20010808 12:38:59

Hi! Just started with angular effects in my collision response. My question is: How do i calculate the velocity of a point that is rotating around an Origin that is translating? 
From: Peter Prade <prade@ph...>  20010808 10:28:45

If you divide the Ndimensional space into the seperate dimensions you can't use examples that have properties of more than 1 dimension. (Your suggestion would require all examples to be positioned on the axes) As an example, take this 2dimensional Space with Samples (vxyz): ^ x 1  y 2     v z +> If you look at the dimensions seperately and you want a morph for position (1) you will find x as the closest match in vertical and z as closest match in horizontal dimension. but, as you can see, in the 2dimensional space y is much closer, and x and y are actually very far from our desired position. Similar problem for position (2). In short, you cannot use examples like (y) when you consider the dimensions seperately. On the other hand, an example like (y) may be just what you need when your artists see that (x) and (z) morph to something ugly. Just my 2P, Peter Prade Ursprüngliche Nachricht Von: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...]Im Auftrag von Conor Stokes Gesendet: Mittwoch, 8. August 2001 1:35 An: gdalgorithmslist@... Betreff: Re: [Algorithms] Lerping samples in Ndimensional space. You don't exactly have to. The interpolation of one dimension in this case, is not dependant upon the other dimensions. (ie, you can interpolate it without refering to them). You get 10 1d splines (which you would probably represent as 2d splines for obvious reasons). And all you need to say is the longer the segment of curve between points is the longer it takes to morph between models. Conor Stokes > The problem is that the space is in 10 dimensions or something, and I don't > have an intuitive grasp of that, or the splines required, so I doubt an > artist will either. We will certainly be adding models in places where the > interpolation looks wrong  the question is how to update the splines to > best use this new example. > > Tom Forsyth  Muckyfoot bloke. > > What's he up to now (and can I have a go)? > http://www.eidosinteractive.com/downloads/search.html?gmid=86 > > > Original Message > > From: Conor Stokes [mailto:cstokes@...] > > Sent: 07 August 2001 03:12 > > To: gdalgorithmslist@... > > Subject: Re: [Algorithms] Lerping samples in Ndimensional space. > > > > > > My answer, which you probably ain't going to like, is that > > probably the best > > thing to do is write a tool that allows artists to set > > interpolation splines > > or something between the points and then slide some > > parameters around as a > > test  if they can't find anything that looks right for an > > area, they have > > to add a model as a mid step. > > > > Conor Stokes > > > > > > > Say I have a bunch of samples of, say, a mesh (a human for > > example). And > > > they are examples of various characteristics that can be > > quantised, e.g. > > > height, weight, age, etc. These parameters all define an > > Ndimensional > > space > > > of possible meshes, and the artists have done actual > > examples of some of > > > them, e.g. they have done a skinny tall mesh, an fat short > > young mesh, a > > > midsized old mesh, etc. > > > > > > And I want to blend them together in a certain way  for > > example, I want a > > > 54 year old, 5'2" mesh weighing about 10 stone. Assume the > > problem of > > > actually blending a number of different meshes has been solved  the > > > question is, how do I find the weights to apply to each example mesh > > during > > > the blend? > > > > > > Naturally there's a paper on this already > > > (http://ftp.research.microsoft.com/pub/tr/tr200079.pdf > > for example), but > > > (a) the maths is fairly intimidating (I understand it, but > > not how to go > > > about the mechanics of solving it on a computer  my > > computational maths > > is > > > rubbish) and (b) it doesn't deal well with a sample space that is > > > irregularlypopulated. Each example has an influence only > > twice as far as > > > its nearest neighbour  beyond that you get the linear > > interpolation, > > which > > > is pretty much guaranteed to be terrible. So if two samples > > are close > > > together, their range of influence is tiny. > > > > > > I'm going to homebrew my own solution, but before I did I > > wondered if > > > anyone had any cunning ideas. By the way, when I say > > Ndimensional space, > > I > > > mean where N gets really quite big (25 or so), and it's also fairly > > sparsely > > > populated. We're expecting to have roughly 2N > 3N sample > > meshes, with > > more > > > examples inserted all over the place to fix up examples > > that don't look > > > human (inevitable). I did like the idea in the paper of > > pseudoexamples  > > > essentially a localised warping of parameter space :) > > > > > > I realise it's fairly unlikely, but if I don't ask, I'll > > never know... > > > > > > Tom Forsyth  Muckyfoot bloke. > > > > > > What's he up to now (and can I have a go)? > > > http://www.eidosinteractive.com/downloads/search.html?gmid=86 > > > > > > _______________________________________________ > > > GDAlgorithmslist mailing list > > > GDAlgorithmslist@... > > > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > > > > > > > > _______________________________________________ > > GDAlgorithmslist mailing list > > GDAlgorithmslist@... > > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > > > > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Martin Fuller <mfuller@ac...>  20010808 08:55:09

Sorry something else I meant to mention. I'm not sure for exactly what application you're asking "why use BSpline (or NURBS) over Bezier". Something I would ask is how important is C1 continuity to the artists, = and do they need to merge the patch with real geometry / pinch the surface = to a point. Doing to with BSpline requires placing 3 control points in the = same place which I would view as unneccesary memory / processing overhead to achieve something which can be done with a single Bezier control point. For games application I'd be far more tempted to go with Bezier and = instruct the artists how to achieve C1 continuity. Indeed when I was tinkering = with Softimage years ago I believe all Bezier control points were C1 = continous by default and you had to click to break the continuity and move the = tangents independantly. Of course if you're up for a bit of home brew fudging you can weld a = bezier and bspline patch by blending the verts along a which may actually be = more efficient than attempting to force a BSpline to weld to convential polyigonal environments. Just a thought, Cheers, Martin Original Message From: Martin Fuller [mailto:mfuller@...] Sent: Wednesday, August 08, 2001 9:38 AM To: 'gdalgorithmslist@...' Subject: [Algorithms] RE: [Algorithms] BSpline vs B=E9zier You certainly can maintain C1 continous Bezier curves as you've = described but you seriously limit your artist in doing so do you not? And yes it = works in 3 dimensions. My memory's failing but don't the tangents also have to be the same = distance apart to maintain C1? (Possibly not I can't remember) Cheers, Martin Original Message From: Philippe Beaudoin [mailto:Philippe.Beaudoin@...] Sent: Tuesday, August 07, 2001 9:43 PM To: gdalgorithmslist@... Subject: [Algorithms] BSpline vs B=E9zier Reading The NURBS Book I came across this strange explanation for the introduction of BSplines. The authors mention it would be hard to use piecewise B=E9zier while maintaining C1 continuity in interactive shape design. Now, I remember using Adobe Illustrator and the basic curve primitive = looked a lot like piecewise B=E9zier splines. In this software, C1 continuity = could be maintained during interaction by "locking together" two handles. = This way, when moving the tangent at the end of curve i, the tangent at the beginning of curve i+1 moved too in order to stay parallel and maintain continuity. This worked with 1D curves in a 2D space, but I don't see = why the process could not be extended to 2D patches in 3D space. My question therefore is: why use BSpline (or NURBS) over B=E9zier (or rational B=E9zier)? Philippe Beaudoin Matrox Graphics _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 
From: Martin Fuller <mfuller@ac...>  20010808 08:38:38

You certainly can maintain C1 continous Bezier curves as you've = described but you seriously limit your artist in doing so do you not? And yes it = works in 3 dimensions. My memory's failing but don't the tangents also have to be the same = distance apart to maintain C1? (Possibly not I can't remember) Cheers, Martin Original Message From: Philippe Beaudoin [mailto:Philippe.Beaudoin@...] Sent: Tuesday, August 07, 2001 9:43 PM To: gdalgorithmslist@... Subject: [Algorithms] BSpline vs B=E9zier Reading The NURBS Book I came across this strange explanation for the introduction of BSplines. The authors mention it would be hard to use piecewise B=E9zier while maintaining C1 continuity in interactive shape design. Now, I remember using Adobe Illustrator and the basic curve primitive = looked a lot like piecewise B=E9zier splines. In this software, C1 continuity = could be maintained during interaction by "locking together" two handles. = This way, when moving the tangent at the end of curve i, the tangent at the beginning of curve i+1 moved too in order to stay parallel and maintain continuity. This worked with 1D curves in a 2D space, but I don't see = why the process could not be extended to 2D patches in 3D space. My question therefore is: why use BSpline (or NURBS) over B=E9zier (or rational B=E9zier)? Philippe Beaudoin Matrox Graphics _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... http://lists.sourceforge.net/lists/listinfo/gdalgorithmslist 