RE: [Algorithms] Bicubic normals for a bicubic world
Brought to you by:
vexxed72
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 > |