Comments inline... > -----Original Message----- > From: Bob Meyers [mailto:[EMAIL PROTECTED]] > Sent: Saturday, October 02, 1999 5:08 AM > To: 'Gareth Hughes' > Subject: Mesa 3.1 tesselation > > > I'm trying to integrate the Mesa 3.0 library into a floor plan > drawing package to replace our use of the default Windows OpenGL > implementation. However, both the 3.0 and 3.1 tesselators are > insufficient as-is for our needs, because we are coming from an > integer coordinate space with a point-equality/point-on-line > epsilon of three coordinate units. This is quite a bit larger than > the epsilon used in either the 3.0 or 3.1 tesselator. Yes, that's fair enough. It shouldn't be too hard to accommodate your needs - see below about GLU_TESS_TOLERANCE. > I've been playing around with yours (the 3.1 version) because > it appears to be more robust overall, and I was able to understand > the code better, so I thought I'd have a better chance at making > the necessary modifications within our extremely short timeline. > I've got some questions, however, and I'm wondering if you could > help me out a bit. I'd be happy provide you with a copy of my > changes if you find them useful. What sort of timeframe are we looking at here? I'm specifically working on some winding rule stuff for another group to help them meet a deadline, so I wouldn't mind fixing stuff for your project as well. It's just a matter of making it a priority. > Here's a few of the issues I've run into: > > - Some troubles in contour projection. I simplified it to > simply project to the best coordinate plane (XY, XZ, YZ) based on > the first contour's normal. Of course all contours use the same > projection. It seems to work fine. This is the way the 3.0 > tesselator did it. What sort of troubles were you having? I can't remember my projection scheme, but I seem to recall trying to make it more robust than the original 1.0 tessellator. > - Same epsilon value used for coordinates and normals. This is a > problem with a large coordinate epsilon like the one we need. I > defined NORMAL_EPSILON and use that when comparing normals. > > - Allow user to set coordinate epsilon via the defined > "GLU_TESS_TOLERANCE" property. This will be almost trivial to implement, I just haven't made it a priority yet. I will add the GLU_TESS_TOLERANCE support in today, and probably keep the current (default) epsilon value for normal comparisons. How does this sound? > - compute_orientations comment says it reverses the contours > if the largest is not CCW. It does not do this, so I added it. It > appears transform_build_bridges assumes this has occurred. My winding rule code should and will handle this properly. I haven't looked at compute_orientations in a while, but you'll have to remember I'm taking two separate alrogithms and morphing them into what we need. In the FIST algorithm, compute_orientations would handle this, but it makes more sense for the winding rule alrogithm to take care of it in our case. I'm working on that now. > - Triangle output for all but the last triangle was passing > the wrong params to the callback functions. Fixed them so they > match the callbacks for the last triangle (which was working > correctly). Yes, I discovered this and the fix should be in there now. > - point_line_test was returning a very large "angle" which > did not compare meaningfully with either a coordinate or normal > epsilon. I changed the function to return an approximate distance > and direction of p from the line segment u -> v. It's requires 8 > adds, 5 multiplies, and 1 divide and provides a distance that is > within about 30% (1 - sqrt(2)/2) of the exact distance. This brings > it into the realm of coordinate space so we can compare it to the > coordinate epsilon. This is probably a bad bit of variable naming on my part. Why do you want to do this? point_line_test should merely give a signed value to determine which side of a directed line a point is on. I'm not sure if this is the place to be doing this kind of comparison, but I'll have to take a closer look. > - I need the tesselator to be able to handle holes with edges that > are colinear with edges of the exterior contour. It does not > appear to handle this well yet, and I haven't figured out why. In > fact, I can't even get it to handle a single completely contained > hole at all. Okay, this is _bad_ - all my tests have been on contours with holes, and they work fine :) Are you using a CCW contour for the exterior and a CW contour for the interior? The winding rule code will orient them this way when I've finished, but if they are like this it should work, in fact it should work very well. That's why I chose the FIST algorithm - it's designed for these types of situations. > - The tesselator currently does not report edge flags. This appears > to be a fairly trivial task in the 3.0 tesselator -- they just > initially mark all the vertices as preceding an exterior edge, and > whenever they clip an ear off, I suppose they just clear the edge > flag for the vertex preceding the new edge. Does that sound > workable? Again, a matter of priorities. Should be trivial to implement. I can add it today if you like. > Any help would be greatly appreciated. This is good stuff -- > thanks for all your work on it. Hey, no worries. I'm kind of proud of (most) of this code, at least the stuff I've touched lately. I'd be more than happy to help you out by specifically targetting areas of the code that don't meet your requirements yet. Don't worry, they will in the end :) I'll bo working on this alot in the next few weeks, so keep in touch and I'll try and get all the fixes you need in ASAP. -- Gareth _______________________________________________ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
