Thread: RE: [Algorithms] Bicubic normals for a bicubic world
Brought to you by:
vexxed72
Menu
▾
▴
gdalgorithms-list
|
From: Tom F. <to...@mu...> - 2000-08-04 10:40:51
|
I was under the impression that interpolating normals of an order-n polynomial surface only required an (n-1) order polynomial, i.e. a biquadratic Bezier patch in this case. But it's entirely possible I was wrong. Even if it's not strictly correct, I bet it would make a superb approximation in most cases. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: John Sensebe [mailto:jse...@ho...] > Sent: 04 August 2000 01:02 > To: gda...@li... > Subject: [Algorithms] Bicubic normals for a bicubic world > > > Hi! I'm new to this list, but already I'm asking questions... ;-) > > Does anyone here know how I can approximate the normals > across a bicubic > surface (i.e.: a Bezier patch) using another bicubic? I want > to use normals > for backface removal, and a simpler interpolation doesn't > help much. On the > other hand, an exact biquintic solution would be too > expensive to compute. > > Thanks. > > John Sensebe > jse...@ho... > Quantum mechanics is God's way of ensuring that we never > really know what's > going on. > > Check out http://members.home.com/jsensebe to see prophecies > for the coming > Millennium! > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Tom F. <to...@mu...> - 2000-08-10 14:58:26
|
No - in the S shape, each component of the normal goes from value A to value B and back to value A, which can be described by a quadratic. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: John Sensebe [mailto:jse...@ho...] > Sent: 04 August 2000 14:41 > To: gda...@li... > Subject: Re: [Algorithms] Bicubic normals for a bicubic world > > > Actually, an (n-1) order polynomial can describe the tangent > vectors in one > direction, so the normals would be the cross product of two > (n-1) order > polynomials, one being the tangents in u and one in v. > > Approximating the normals of a bicubic with a single > quadratic would lead to > problems, however. Consider the 2D case, where a bicubic > curve can make an > 'S' shape, but a quadratic can't. > > John Sensebe > jse...@ho... > Quantum mechanics is God's way of ensuring that we never > really know what's > going on. > > Check out http://members.home.com/jsensebe to see prophecies > for the coming > Millennium! |
|
From: John S. <jse...@ho...> - 2000-08-12 00:08:06
|
Ok, maybe reducing it to 2D wasn't such a good idea. What we really want is a curve that descibes the surface normal of a bicubic surface. This normal is the cross product of two tangents, one in u and one in v. Each of these tangent surfaces is a partial derivative, so while it's a quadratic in one parameter, it's a still cubic in the other. If you can fit that into a biquadratic surface, I'd like to see it, 'cause I can sure use it! ;-) John Sensebe jse...@ho... Quantum mechanics is God's way of ensuring that we never really know what's going on. Check out http://members.home.com/jsensebe to see prophecies for the coming Millennium! ----- Original Message ----- From: "Tom Forsyth" <to...@mu...> To: <gda...@li...> Sent: Thursday, August 10, 2000 9:55 AM Subject: RE: [Algorithms] Bicubic normals for a bicubic world > No - in the S shape, each component of the normal goes from value A to value > B and back to value A, which can be described by a quadratic. > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > |
|
From: Conor S. <cs...@tp...> - 2000-08-12 02:50:23
|
Actually, if you think about it - The normals are totally quadratic. And
if you do a derivitive in 2
directions (across S, and across T) you do get 2 quadratics. Not only that,
the cross product is
resiliant to transforms - So it remains the same. However, normalisation
still needs to occur.
This is why I precalc my normals and reference them from a map in most
cases.
Conor Stokes
> Ok, maybe reducing it to 2D wasn't such a good idea.
>
> What we really want is a curve that descibes the surface normal of a
bicubic
> surface. This normal is the cross product of two tangents, one in u and
one
> in v. Each of these tangent surfaces is a partial derivative, so while
it's
> a quadratic in one parameter, it's a still cubic in the other.
>
> If you can fit that into a biquadratic surface, I'd like to see it, 'cause
I
> can sure use it! ;-)
>
> John Sensebe
> jse...@ho...
> Quantum mechanics is God's way of ensuring that we never really know
what's
> going on.
>
> Check out http://members.home.com/jsensebe to see prophecies for the
coming
> Millennium!
>
>
> ----- Original Message -----
> From: "Tom Forsyth" <to...@mu...>
> To: <gda...@li...>
> Sent: Thursday, August 10, 2000 9:55 AM
> Subject: RE: [Algorithms] Bicubic normals for a bicubic world
>
>
> > No - in the S shape, each component of the normal goes from value A to
> value
> > B and back to value A, which can be described by a quadratic.
> >
> > Tom Forsyth - Muckyfoot bloke.
> > Whizzing and pasting and pooting through the day.
> >
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>
|
|
From: John S. <jse...@ho...> - 2000-08-12 03:39:37
|
How are the normals biquadratic? And the two tangent surfaces can't be biquadratic, because you're only derivating in one parameter, leaving the other as-is. You derive in u, it's still cubic in v, and vice-versa. I really want to have a good solution to this, so please bear with me. Thanks. John Sensebe jse...@ho... Quantum mechanics is God's way of ensuring that we never really know what's going on. Check out http://members.home.com/jsensebe to see prophecies for the coming Millennium! ----- Original Message ----- From: "Conor Stokes" <cs...@tp...> To: <gda...@li...> Sent: Friday, August 11, 2000 9:58 PM Subject: Re: [Algorithms] Bicubic normals for a bicubic world > Actually, if you think about it - The normals are totally quadratic. And > if you do a derivitive in 2 > directions (across S, and across T) you do get 2 quadratics. Not only that, > the cross product is > resiliant to transforms - So it remains the same. However, normalisation > still needs to occur. > > This is why I precalc my normals and reference them from a map in most > cases. > > Conor Stokes > > |
|
From: Conor S. <cs...@tp...> - 2000-08-12 12:49:58
|
As I said - In both directions. Not that hard. > How are the normals biquadratic? And the two tangent surfaces can't be > biquadratic, because you're only derivating in one parameter, leaving the > other as-is. You derive in u, it's still cubic in v, and vice-versa. > > I really want to have a good solution to this, so please bear with me. > > Thanks. > > John Sensebe > jse...@ho... > Quantum mechanics is God's way of ensuring that we never really know what's > going on. > > Check out http://members.home.com/jsensebe to see prophecies for the coming > Millennium! > > > ----- Original Message ----- > From: "Conor Stokes" <cs...@tp...> > To: <gda...@li...> > Sent: Friday, August 11, 2000 9:58 PM > Subject: Re: [Algorithms] Bicubic normals for a bicubic world > > > > Actually, if you think about it - The normals are totally quadratic. > And > > if you do a derivitive in 2 > > directions (across S, and across T) you do get 2 quadratics. Not only > that, > > the cross product is > > resiliant to transforms - So it remains the same. However, normalisation > > still needs to occur. > > > > This is why I precalc my normals and reference them from a map in most > > cases. > > > > Conor Stokes > > > > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: Tom F. <to...@mu...> - 2000-08-12 09:45:44
|
Sorry - I wasn't suggesting that the normals _are_ biquadratic. But I was suggesting that a biquadratic approximation was going to be pretty close in most cases. Good enough to fool the eye, which really only _needs_ G0 for lighting, and even a very rough-and-ready C/G1 reduces Mach banding to very tolerable levels. So all you need is a curve that can be reliably G0, and get pretty rough G1 at vertices, and not too far out on edges in non-extreme cases. Biquadratic seems to fit the bill well. Renormalisation is a pain, but you'd have to do that whatever function you used (unless you used some astonishingly high-power function and use enough control points to match the ideal curve, which is probably more expensive than renormalisation). Oh hang on - since _rational_ biquadratic surfaces can describe conic sections (including spheres and sections of spheres), could you maybe use them for your normals, and thus not have to renormalise - or at least get close enough that the eye won't notice? Or maybe my brain can't visualise the spacial equivalent of a unit-length normal well enough to see that a rational biquadratic isn't good enough. Well, just a thought. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. > -----Original Message----- > From: John Sensebe [mailto:jse...@ho...] > Sent: 12 August 2000 04:39 > To: gda...@li... > Subject: Re: [Algorithms] Bicubic normals for a bicubic world > > > How are the normals biquadratic? And the two tangent surfaces can't be > biquadratic, because you're only derivating in one parameter, > leaving the > other as-is. You derive in u, it's still cubic in v, and vice-versa. > > I really want to have a good solution to this, so please bear with me. > > Thanks. > > John Sensebe > jse...@ho... > Quantum mechanics is God's way of ensuring that we never > really know what's > going on. > > Check out http://members.home.com/jsensebe to see prophecies > for the coming > Millennium! > > > ----- Original Message ----- > From: "Conor Stokes" <cs...@tp...> > To: <gda...@li...> > Sent: Friday, August 11, 2000 9:58 PM > Subject: Re: [Algorithms] Bicubic normals for a bicubic world > > > > Actually, if you think about it - The normals are > totally quadratic. > And > > if you do a derivitive in 2 > > directions (across S, and across T) you do get 2 > quadratics. Not only > that, > > the cross product is > > resiliant to transforms - So it remains the same. However, > normalisation > > still needs to occur. > > > > This is why I precalc my normals and reference them > from a map in most > > cases. > > > > Conor Stokes > > > > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: John S. <jse...@ho...> - 2000-08-12 18:34:02
|
Well, as I've said in a previous post, I need to fool more than the eye, since I want to cull backfacing subpatches (at least, as well as possible). Therefore, since my patches are bicubic, I wanted to use a bicubic approximation for the normals. It should be better than biquadratic, and it fits well into my patch subdivision algorithm. Having decided on the method, I'm having trouble figuring out what the parameters should be. Should I just take the two tangent vectors at each control point of a Bezier patch, cross them, and use the resulting vectors as the control points of a Bezier patch describing the normals of the first? BTW, I plan on letting D3D handle the normalization for me, so at least I can let the hardware do it if it's doing T&L. John Sensebe jse...@ho... Quantum mechanics is God's way of ensuring that we never really know what's going on. Check out http://members.home.com/jsensebe to see prophecies for the coming Millennium! ----- Original Message ----- From: "Tom Forsyth" <to...@mu...> To: <gda...@li...> Sent: Saturday, August 12, 2000 4:42 AM Subject: RE: [Algorithms] Bicubic normals for a bicubic world > Sorry - I wasn't suggesting that the normals _are_ biquadratic. But I was > suggesting that a biquadratic approximation was going to be pretty close in > most cases. Good enough to fool the eye, which really only _needs_ G0 for > lighting, and even a very rough-and-ready C/G1 reduces Mach banding to very > tolerable levels. > > So all you need is a curve that can be reliably G0, and get pretty rough G1 > at vertices, and not too far out on edges in non-extreme cases. Biquadratic > seems to fit the bill well. > > Renormalisation is a pain, but you'd have to do that whatever function you > used (unless you used some astonishingly high-power function and use enough > control points to match the ideal curve, which is probably more expensive > than renormalisation). > > Oh hang on - since _rational_ biquadratic surfaces can describe conic > sections (including spheres and sections of spheres), could you maybe use > them for your normals, and thus not have to renormalise - or at least get > close enough that the eye won't notice? Or maybe my brain can't visualise > the spacial equivalent of a unit-length normal well enough to see that a > rational biquadratic isn't good enough. Well, just a thought. > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > |
|
From: Tom F. <to...@mu...> - 2000-08-12 19:44:47
|
Hmmmm... OK. Tricky. Incidentally, I would question whether you want to bother with BFC of subpatches. I would go with the philosophy that since most patches will be wholly rejected or wholly accepted, the borderline cases are few in number. However, if you're doing a BFC calculation + test per sub-patch, that seems like a fair amount of work for _all_ visible patches, just to save a bit on borderline patches. My instincts would be to BFC a top-level patch, then set up your Difference Engine to the required tesselation level and just draw the whole thing, letting the hardware do tri-level BFC. The edges where different levels of tesselation meet require a bit of thought. "Cheating" by simply stitching them together with slim tris after drawing each patch at different levels is a possible option, and very quick (it's a second forward-difference engine, but only in one direction, along the crease). But you tend to get lighting differences between the two patches, which can be visible. You can also special-case the edges of the patch drawer so that it fans the edge tris to match adjacent patches, which looks quite good. And it's pretty good for speed, since you can do this by shrinking the full speed tesselation by one on each edge that needs higher tesselation (fewer than half the edges of the scene will need extra fanning(*)), then doing the fanned edges with special case (but exceeding similar-looking) code. Anyway, there's probably some very good reason why you're doing it recursively, so I've probably just been ranting. Sorry! Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. (*) Ah - almost true. True if you don't BFC the patches :-) Close enough for performance considerations though. > -----Original Message----- > From: John Sensebe [mailto:jse...@ho...] > Sent: 12 August 2000 19:34 > To: gda...@li... > Subject: Re: [Algorithms] Bicubic normals for a bicubic world > > > Well, as I've said in a previous post, I need to fool more > than the eye, > since I want to cull backfacing subpatches (at least, as well > as possible). > > Therefore, since my patches are bicubic, I wanted to use a bicubic > approximation for the normals. It should be better than > biquadratic, and it > fits well into my patch subdivision algorithm. > > Having decided on the method, I'm having trouble figuring out what the > parameters should be. Should I just take the two tangent > vectors at each > control point of a Bezier patch, cross them, and use the > resulting vectors > as the control points of a Bezier patch describing the > normals of the first? > > BTW, I plan on letting D3D handle the normalization for me, > so at least I > can let the hardware do it if it's doing T&L. > > John Sensebe > jse...@ho... > Quantum mechanics is God's way of ensuring that we never > really know what's > going on. > > Check out http://members.home.com/jsensebe to see prophecies > for the coming > Millennium! > > > ----- Original Message ----- > From: "Tom Forsyth" <to...@mu...> > To: <gda...@li...> > Sent: Saturday, August 12, 2000 4:42 AM > Subject: RE: [Algorithms] Bicubic normals for a bicubic world > > > > Sorry - I wasn't suggesting that the normals _are_ > biquadratic. But I was > > suggesting that a biquadratic approximation was going to be > pretty close > in > > most cases. Good enough to fool the eye, which really only > _needs_ G0 for > > lighting, and even a very rough-and-ready C/G1 reduces Mach > banding to > very > > tolerable levels. > > > > So all you need is a curve that can be reliably G0, and get > pretty rough > G1 > > at vertices, and not too far out on edges in non-extreme cases. > Biquadratic > > seems to fit the bill well. > > > > Renormalisation is a pain, but you'd have to do that > whatever function you > > used (unless you used some astonishingly high-power function and use > enough > > control points to match the ideal curve, which is probably > more expensive > > than renormalisation). > > > > Oh hang on - since _rational_ biquadratic surfaces can > describe conic > > sections (including spheres and sections of spheres), could > you maybe use > > them for your normals, and thus not have to renormalise - > or at least get > > close enough that the eye won't notice? Or maybe my brain > can't visualise > > the spacial equivalent of a unit-length normal well enough > to see that a > > rational biquadratic isn't good enough. Well, just a thought. > > > > Tom Forsyth - Muckyfoot bloke. > > Whizzing and pasting and pooting through the day. > > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: John S. <jse...@ho...> - 2000-08-12 20:05:11
|
Actually, I hadn't thought of simply rejecting whole patches that are backfacing, and leaving the rest up to the driver... That may be the wisest solution. Thanks. I am "cheating" for different tesselation amounts right now, and the results are very good. With the algorithm I've written, the edge match up almost exactly, so the slim triangles are very slim indeed. They simply cover tiny holes that would show up due to floating-point inaccuracies. And hey, if your ranting gives me more insight into what I'm doing, go right ahead and rant! ;-) John Sensebe jse...@ho... Quantum mechanics is God's way of ensuring that we never really know what's going on. Check out http://members.home.com/jsensebe to see prophecies for the coming Millennium! ----- Original Message ----- From: "Tom Forsyth" <to...@mu...> To: <gda...@li...> Sent: Saturday, August 12, 2000 2:42 PM Subject: RE: [Algorithms] Bicubic normals for a bicubic world > Hmmmm... OK. Tricky. > > Incidentally, I would question whether you want to bother with BFC of > subpatches. I would go with the philosophy that since most patches will be > wholly rejected or wholly accepted, the borderline cases are few in number. > However, if you're doing a BFC calculation + test per sub-patch, that seems > like a fair amount of work for _all_ visible patches, just to save a bit on > borderline patches. > > My instincts would be to BFC a top-level patch, then set up your Difference > Engine to the required tesselation level and just draw the whole thing, > letting the hardware do tri-level BFC. > > The edges where different levels of tesselation meet require a bit of > thought. "Cheating" by simply stitching them together with slim tris after > drawing each patch at different levels is a possible option, and very quick > (it's a second forward-difference engine, but only in one direction, along > the crease). But you tend to get lighting differences between the two > patches, which can be visible. > > You can also special-case the edges of the patch drawer so that it fans the > edge tris to match adjacent patches, which looks quite good. And it's pretty > good for speed, since you can do this by shrinking the full speed > tesselation by one on each edge that needs higher tesselation (fewer than > half the edges of the scene will need extra fanning(*)), then doing the > fanned edges with special case (but exceeding similar-looking) code. > > Anyway, there's probably some very good reason why you're doing it > recursively, so I've probably just been ranting. Sorry! > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > > (*) Ah - almost true. True if you don't BFC the patches :-) Close enough for > performance considerations though. > |
|
From: John S. <jse...@ho...> - 2000-08-14 13:44:57
|
OK, here's an update. I commented out the culling routines I had in the recurvsive portion of my patch splitter and added some simple culling to the patch setup routine and got a 40% drop in frame rate! Granted, the culling routines I had weren't filling the bill and would have to be slower to be correct, and my test data is optimal, consisting of spheres built from six patches (like a cube). Anyway, the problem with this seems to be that I've written my routine specifically to build up the edges of objects to reduce faceting, so I end up with a lot of "borderline" subpatches. So I either eat the loss in frame rate, or I'm back to square one. :-( John Sensebe jse...@ho... Quantum mechanics is God's way of ensuring that we never really know what's going on. Check out http://members.home.com/jsensebe to see prophecies for the coming Millennium! ----- Original Message ----- From: "Tom Forsyth" <to...@mu...> To: <gda...@li...> Sent: Saturday, August 12, 2000 2:42 PM Subject: RE: [Algorithms] Bicubic normals for a bicubic world > Hmmmm... OK. Tricky. > > Incidentally, I would question whether you want to bother with BFC of > subpatches. I would go with the philosophy that since most patches will be > wholly rejected or wholly accepted, the borderline cases are few in number. > However, if you're doing a BFC calculation + test per sub-patch, that seems > like a fair amount of work for _all_ visible patches, just to save a bit on > borderline patches. > > My instincts would be to BFC a top-level patch, then set up your Difference > Engine to the required tesselation level and just draw the whole thing, > letting the hardware do tri-level BFC. > > The edges where different levels of tesselation meet require a bit of > thought. "Cheating" by simply stitching them together with slim tris after > drawing each patch at different levels is a possible option, and very quick > (it's a second forward-difference engine, but only in one direction, along > the crease). But you tend to get lighting differences between the two > patches, which can be visible. > > You can also special-case the edges of the patch drawer so that it fans the > edge tris to match adjacent patches, which looks quite good. And it's pretty > good for speed, since you can do this by shrinking the full speed > tesselation by one on each edge that needs higher tesselation (fewer than > half the edges of the scene will need extra fanning(*)), then doing the > fanned edges with special case (but exceeding similar-looking) code. > > Anyway, there's probably some very good reason why you're doing it > recursively, so I've probably just been ranting. Sorry! > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > > (*) Ah - almost true. True if you don't BFC the patches :-) Close enough for > performance considerations though. > |
|
From: Tom F. <to...@mu...> - 2000-08-12 20:30:09
|
I wasn't thinking of artifacts from any holes - they'll be fine - but of the abrupt changes in lighting. I too started off cheating this way, but you have a T-junction in terms of lighting shades, even if the actual few tiny pixels in the T-junction are filled, and if your tesselation is not fine enough, the eye can spot these changes in lighting. Which is why I moved to fanning the edge tris - the lighting change is spread over the width of the fan (which is usually a decent number of pixels, i.e. not 1), and it is far less noticeable. Tom Forsyth - Muckyfoot bloke. Whizzing and pasting and pooting through the day. P.S. John - we need to talk about that home page - that's going to get a nomination from me on http://www.uglyinternet.com/ I'm afraid. Gotta be cruel to be kind. > -----Original Message----- > From: John Sensebe [mailto:jse...@ho...] > Sent: 12 August 2000 21:05 > To: gda...@li... > Subject: Re: [Algorithms] Bicubic normals for a bicubic world > > > Actually, I hadn't thought of simply rejecting whole patches that are > backfacing, and leaving the rest up to the driver... That may > be the wisest > solution. Thanks. > > I am "cheating" for different tesselation amounts right now, > and the results > are very good. With the algorithm I've written, the edge > match up almost > exactly, so the slim triangles are very slim indeed. They > simply cover tiny > holes that would show up due to floating-point inaccuracies. > > And hey, if your ranting gives me more insight into what I'm > doing, go right > ahead and rant! ;-) > > John Sensebe > jse...@ho... > Quantum mechanics is God's way of ensuring that we never > really know what's > going on. > > Check out http://members.home.com/jsensebe to see prophecies > for the coming > Millennium! > > > ----- Original Message ----- > From: "Tom Forsyth" <to...@mu...> > To: <gda...@li...> > Sent: Saturday, August 12, 2000 2:42 PM > Subject: RE: [Algorithms] Bicubic normals for a bicubic world > > > > Hmmmm... OK. Tricky. > > > > Incidentally, I would question whether you want to bother > with BFC of > > subpatches. I would go with the philosophy that since most > patches will be > > wholly rejected or wholly accepted, the borderline cases are few in > number. > > However, if you're doing a BFC calculation + test per > sub-patch, that > seems > > like a fair amount of work for _all_ visible patches, just > to save a bit > on > > borderline patches. > > > > My instincts would be to BFC a top-level patch, then set up your > Difference > > Engine to the required tesselation level and just draw the > whole thing, > > letting the hardware do tri-level BFC. > > > > The edges where different levels of tesselation meet > require a bit of > > thought. "Cheating" by simply stitching them together with > slim tris after > > drawing each patch at different levels is a possible > option, and very > quick > > (it's a second forward-difference engine, but only in one > direction, along > > the crease). But you tend to get lighting differences > between the two > > patches, which can be visible. > > > > You can also special-case the edges of the patch drawer so > that it fans > the > > edge tris to match adjacent patches, which looks quite > good. And it's > pretty > > good for speed, since you can do this by shrinking the full speed > > tesselation by one on each edge that needs higher > tesselation (fewer than > > half the edges of the scene will need extra fanning(*)), > then doing the > > fanned edges with special case (but exceeding similar-looking) code. > > > > Anyway, there's probably some very good reason why you're doing it > > recursively, so I've probably just been ranting. Sorry! > > > > Tom Forsyth - Muckyfoot bloke. > > Whizzing and pasting and pooting through the day. > > > > (*) Ah - almost true. True if you don't BFC the patches :-) > Close enough > for > > performance considerations though. > > > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
|
From: gl <gl...@nt...> - 2000-08-12 22:04:20
|
> P.S. John - we need to talk about that home page - that's going to get a > nomination from me on http://www.uglyinternet.com/ I'm afraid. Gotta be > cruel to be kind. Funky. Hey Tom, maybe you could do a VIPM 3D dancing mesh for yours... who cares about the art? Feel the technology! ;) -- gl |
|
From: John S. <jse...@ho...> - 2000-08-04 13:42:44
|
Actually, an (n-1) order polynomial can describe the tangent vectors in one direction, so the normals would be the cross product of two (n-1) order polynomials, one being the tangents in u and one in v. Approximating the normals of a bicubic with a single quadratic would lead to problems, however. Consider the 2D case, where a bicubic curve can make an 'S' shape, but a quadratic can't. John Sensebe jse...@ho... Quantum mechanics is God's way of ensuring that we never really know what's going on. Check out http://members.home.com/jsensebe to see prophecies for the coming Millennium! ----- Original Message ----- From: "Tom Forsyth" <to...@mu...> To: <gda...@li...> Sent: Friday, August 04, 2000 5:35 AM Subject: RE: [Algorithms] Bicubic normals for a bicubic world > I was under the impression that interpolating normals of an order-n > polynomial surface only required an (n-1) order polynomial, i.e. a > biquadratic Bezier patch in this case. But it's entirely possible I was > wrong. > > Even if it's not strictly correct, I bet it would make a superb > approximation in most cases. > > Tom Forsyth - Muckyfoot bloke. > Whizzing and pasting and pooting through the day. > > > -----Original Message----- > > From: John Sensebe [mailto:jse...@ho...] > > Sent: 04 August 2000 01:02 > > To: gda...@li... > > Subject: [Algorithms] Bicubic normals for a bicubic world > > > > > > Hi! I'm new to this list, but already I'm asking questions... ;-) > > > > Does anyone here know how I can approximate the normals > > across a bicubic > > surface (i.e.: a Bezier patch) using another bicubic? I want > > to use normals > > for backface removal, and a simpler interpolation doesn't > > help much. On the > > other hand, an exact biquintic solution would be too > > expensive to compute. > > > > Thanks. > > > > John Sensebe > > jse...@ho... > > Quantum mechanics is God's way of ensuring that we never > > really know what's > > going on. > > > > Check out http://members.home.com/jsensebe to see prophecies > > for the coming > > Millennium! > > > > > > > > > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > > > > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X