[Mesa-dev] GLU tessellation
(yes, I really do love this stuff :) I spent a lot of time on the weekend looking into all the problems that have been reported, and have discovered the source of the majority of these - tess_clip.c is only slightly broken :) I based my implementation of a scanbeam approach to polygon clipping on the Generic Polygon Clipping library, which had the basic stuff in there but didn't have the required capabilities to do the winding rules. I've added in the winding rule operations, but it isn't as clean as I would have liked and I was planning on rewriting it after 3.2 went out. However, to fix the current bugs I will have to rework the whole clipping part now rather than later. An example of a case that is not handled at the moment is: 1 __58__ 4 | || | | || | | 6||7 | |__| 23 The major change I added was to keep track of the original orientation of the edges after they are broken up in the scanbeam table. Now, I will have to keep track of the winding number of the current region as I am clipping, instead of calculating it after the contours are extracted, to correctly handle cases like the one above. This will make the whole process simpler and should shorten the main clipping function considerably. So, I'm working on this now. I'm designing the new clipping algorithm at the moment, and it should be cleaner and simpler than the current implementation. Thanks again for your patience, and I will keep you up to date with my progress. Things are a lot quiter for me now than over the holiday period, so I should be able to devote a lot of time to fixing this problem quickly. -- Gareth PS - Yes, my aim is to make the Mesa tessellator better than the SGI one (I know of at least one case where the SGI tessellator fails). And, it will be good to have an open-source ANSI C implementation of the GLU tessellator. == Gareth Hughesmailto:[EMAIL PROTECTED] Bell Labs Australiaph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Permission from SGI to implement extensions
I will contact SGI about getting permission to implement these extensions today. I will keep the list informed of my progress. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Status of EXT_fragment_lighting and EXT_light_texture?
Any news/updates on the Mesa implementations of these specs? I was under the impression someone was implementing EXT_fragment_lighting, but haven't really heard or seen anything about this lately. If no one is currently working on these extensions, I will (targetted at a 3.4/5 timeframe if 3.3 is going out with XFree86 4.0). -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] Bell Labs Australiaph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] More tessellation bug fixes
Howard Luby of Mediascape Corp (http://www.mediascape.com) has given me a beta copy of their Artstream app, which enabled me to track down a segfault in the tessellation code. Thanks, Howard! For some reason, the global vertex count (used to sort the vertices from left to right) was getting too large and thus the sort array was having problems. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] Bell Labs Australiaph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] New GLU conformance?
I've just added the ability to do boundary-only tessellation, ie. just output the final contours as line loops. What are the chances of running the new tessellation code through the OpenGL conformance tests? Can we still do that? I've run pretty much every test app I have that uses the tessellator and they all seem to work pretty well. There may still be a slight problem with the edge flag settings, so I'll be investigating this over the next day or two. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Even more tessellation fixes
I've _really_ fixed the CW/CCW orientation issues and tessellation plane normal calculations this time :) The text3d screensaver should be in much better shape now. Clockwise input contours are being handled much more robustly now. There is one last problem - some letters like 'B' have their inner loops classified as OUTSIDE instead of INSIDE and are thus ignored in the winding rule output. I've tracked this bug down and know how to fix it, so I'll commit this tonight when I have it working. Can people please bash on the text3d screensaver? I'm pretty sure it works okay now. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Text3D screensaver
I have it running in front of me now, with correct text. A lot easier than I was expecing, that's for sure. I have to work out why the contours are being reversed when they shouldn't, as the output contours are being clipped incorrectly. At least the tessellation is happening correctly now. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] New GLU
I just checked the performance of the new GLU with the text3d demo in xlockmore. (why is the new version only in the 3.2 branch and not in the 3.3?) A lot of letters in the demo are not correctly processed (=look awfull!!!) Right, I have a 10MB dump of what's going on in the first two frames of the animation, so I should be able to work out what the problem is. It might take a while... The code has been left on the 3.2 branch for now so I can concentrate on getting it finished. I'll merge it to the main branch when 3.1 goes out. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Lock on Win32/Rules
I'm committing an update to the Win32 makefiles so they build GLU correctly with the changes I've done lately. There seems to be a lock hanging around on Win32/Rules... -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] demos/tessdemo
I've added a combine callback to this demo, and converted the coords from ints to floats accordingly. I couldn't commit it as it was locked earlier today. I'll try again tonight. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Scanbeam clipping done
I finished the last of the intersection handling last night, so it now seems to work correctly in all cases. I still have to sort out the horizontal edge stuff, but that is handled by the algorithm and I just have to see why my edges aren't being handled correctly. Contour extraction works well, even with the self-intersecting spiral. All that is left is to make sure the contours are being output with the correct orientation, and then I'm done. Code needs some cleaning up, but I'll finish that off tonight. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] tests of GLU with xlockmore's text3d
I run some tests with the latest glu-code. I used the text3d demo of xlockmore to do this. I think Gareth is converging to a workin version. Many rotating characters are correct. Some of them are wrong (they are correct using the "old" GLU-code). The crash rate is going down (Today I noticed a floating invalid operation in transform_build_bridges (line 15609 (included in the count are all include files))). Yep, getting there... It's already Friday again here so I'll be pretty much spending the whole weekend working on the new and improved scanbeam approach to the winding rule operations. The best part of this is I have a working implementation of the algorithm to work from, as the original paper skimmed over some of the more important parts. I was going to initially base my implementation very closely on this (GPC at http://www.cs.man.ac.uk/aig/staff/alan/software/index.html for those that are interested), but after closer inspection of how all the tables work I'm going to have to do it a little differently. This is mainly due to the fact that I have to store contours as linked lists instead of arrays of vertices. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] New and improved winding rules (version 3?)
I've got all the necessary tables set up correctly now (local minima, scanbeams etc), so I'll start the scanbeam sweep code tonight. Hopefully I'll have something committed today or tommorrow. I tested the GPC implementation of the algorithm (it comes with a nice drawing tool) and it does correctly handle the self-intersecting cases that were causing problems. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] Macros with variable length arguments?
MSVC 6 SP3 definitely does NOT like varargs macros. ;^( I tried about as many combinations as I could think of, no go. Okay, I'll change them to straight function calls. Sorry. Hey, it ain't your fault :) -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] Macros with variable length arguments?
Is the logging code only enabled when building in debug mode? I'd say the warnings are OK then. But when the end user builds with optimizations I'd rather not see a bunch of warnings. Yes, the logging code is only built in debug mode. I'll have to see if the compiler still complains about the empty macro definitions with variable length argument lists when doing a normal build. I'll look at your code later and see if I can suggest more. Thanks, I should be committing a whole heap of stuff this weekend. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] Macros with variable length arguments?
I don't know how your macros are implemented, but variable length
may not be at all supported on MSVC variants, in fact it may not
even treat it as a warning but treat it as a compile-time error.
Here's what they kinda look like now (from memory):
#ifdef DEBUG
#ifdef _WIN32
#define DEBUG_STREAMstdout /* allow redir to file */
#else
#define DEBUG_STREAMstderr
#endif
#define MSG( level, format, args... ) \
if ( level = tess_dbg_level ) {\
fprintf( DEBUG_STREAM, format, ## args ); \
fflush( DEBUG_STREAM ); \
}
#else
#define MSG( level, format, args... )
#endif
You can now set tess_dbg_level with an environment variable
GLU_TESS_DBG_LEVEL at runtime. I'll be committing this stuff on the weekend
(or changing it now if required).
-- Gareth
___
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Tessellation winding rules
I've re-organized the way the winding rules are calculated, now that things are almost complete it makes more sense to do things the way I'm doing them now. Any intersected contours are handled first, so that the winding numbers of a set of non-intersecting contours can be calculated. The contours can then be labelled inside or outside. Once all contours are labelled, the resulting set can be extracted. Sounds good, mostly works, except for a slight problem in the intersected contour handling code that picks the wrong edge to follow in the big self-intersecting loop in book/tesswind.c - I'm tracking it down now. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Some more tessellation updates
I've received some test polygons from the ECMWF and have been working with them for a week or so. I've added GLU_TESS_TOLERANCE handling and initial contour-within-contour handling. I'm currently getting a segfault in a glVertex2dv call, but it's getting through a whole lot more than it used to. Things are progressing well. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] RE: Mesa 3.1 tesselation
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
[Mesa-dev] RE: 1.3 winding rules
Arne Jorgensen followed your progress last week until Friday 17 September where he every day during last week said when running simple tests that more and more was working. However, he could not successfully run any of our complicated polygons. However, Arne is on leave this week but will continue testing Monday 27 September. He can then use your latest version and give you feedback. If necessary, we can make available to you some of our huge polygons (simple printout of coordinates on a file?). Sorry for the delay, I've been pretty seriously ill for the last week but am back at work again today. How is the schedule looking for your demos? I committed a lot of fixes over the weekend, including the second initial winding rule code. Again, having a simple coordinate dump of some of your larger polygons would help me immensely. If I have the polygons, I can fix any bugs that arise straight away. We appreciate all the work you are doing. Again, no worries, I'm glad I can help. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] new winding rules for GLU
Nasty :) I'll track this down - I've had this problem before, so I probably broke the fix when I removed my debugging memory allocation on the weekend. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, October 04, 1999 6:16 PM To: [EMAIL PROTECTED] Subject: [Mesa-dev] new winding rules for GLU Hi All, My VMS compiler choked on all the CR in the tess_winding.h. So I commited a patch to remove them all. However the new GLU seems not to work with the text3d demo (using libGLTT). I get the following crash just after starting: olka-jj) xlock -inwindow -nice 0 -modelist allgl %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=1372 4033, PC=0091349C, PS=001B %TRACE-F-TRACEBACK, symbolic stack dump follows imagemoduleroutine line rel PC abs PC LIBMESAGLU TESS_HEAP heap_insert 10631 025C 0091349C LIBMESAGLU TESS_FIST add_ear_to_heap 11571 120C 009128CC LIBMESAGLU TESS_FIST determine_ears 11453 LIBMESAGLU TESS_FIST fist_recovery_process 11268 0D80 00912440 LIBMESAGLU TESS_FIST tessellate_contours 11402 LIBMESAGLU TESS_FIST cleanup 11717 0368 00911A28 LIBMESAGLU TESS_FIST fist_tessellation 10742 LIBMESAGLU TESS gluTessEndPolygon10931 06F8 00910908 XLOCK GLTTGLYPHPOLYGONIZER polygonize 5999 0660 0020D080 XLOCK GLTTGLYPHTRIANGULATOR triangulate 2480 0258 0020C918 XLOCK TEXT3D Draw30280 0DA8 00208178 XLOCK TEXT3D draw_text3d 30947 22D0 002096A0 XLOCK MODE call_callback_hook19953 02A8 00129BA8 XLOCK MODE call_change_hook 20024 03A4 00129CA4 XLOCK XLOCK justDisplay 32804 3598 00123598 XLOCK XLOCK main 33798 6038 00126038 XLOCK XLOCK __main 0 0070 00120070 XLOCK 0 0021E354 0022E354 Access violation normally means that is tries to use values that are not initialized/allocated. Jouk Ceterum censeo tertium millennium post Christum natum anno MMI incepturum esse - - Jouk Jansen [EMAIL PROTECTED] Technische Universiteit Delfttt uu uu ddd Nationaal centrum voor HREM tt uu uu dddd Rotterdamseweg 137 tt uu uu dd dd 2628 AL Delfttt uu uu dd dd Nederlandtt uu uu dddd tel. 31-15-2781536 tt uuu ddd - - ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] book/tess demo
Hooray! I got a nice, smoothly shaded star at around midnight last night with this demo. Just had to clean up my memory allocation (actually, do some deallocation...) and we now have support for self-intersecting polygons. The other demos require me to fix the island-inside-an-island case, which I know how to do, and will code up tonight. I'll spend some time making sure I'm deallocating all of my dynamic data, but a "final" commit should happen this week. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Updates to tessellation
I've committed some bug fixes to the tessellation code that should fix a _lot_ of the previous problems. Winding rule code bugs have been fixed, and I'm finalizing those changes now. Looks good for a beta 3 release... -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Tessellation fixes
I've committed some fixes to the macro calls I'm using, which should at least allow the demos to display something (the winding rules are still not in there yet). As I suspected, I had the src and dst parameters around the wrong way for several COPY_3V calls :) -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] Win32 directory in CVS?
Man, Win32 development really annoys me at times :) Oh, to be at home working on my Linux box... I'm not sure if anyone has tried this in a while, but the src-glut/ directory basically won't compile under Windows. Maybe it's just the use of the old DSP files from 3.0, but even starting from scratch was a nightmare. I've hacked up a project file that will build the thing (Brian, I had to take out your changes to src-glut/glutint.h), but of course I get debug assertions with each event complaining about different calling conventions. Ted, have you had a chance to look at putting the win32/ directory back into CVS? Has anyone else had more luck? I'd really like to get the tessellation code working before the next beta release, so any help would be _greatly_ appreciated. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] Win32 directory in CVS?
Well I have compiled glut succesfully using the makefile.fx (in src-glut). (Compiled with VisualStudio 97 == VC++ 5.0) I had to do two changes: 1) clean the makefile.fx line endings (I used GNUEmacs on windows and deleted the ^M characters) Done. 2) Applied the attached patch to glutint.h Done. I'll try this out now - although I'm just about to head home and work under Linux again :) -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] double lines in makefiles.
In any case as the problem is as common as Microsoft (or Apple) operating systems I strongly suspect that things like CVS are supposed to hide these kind of things, serving ASCII files to different clients with "correct" line-ends. The problem seems to be fixed now, I just got a clean copy of the file from the CVS, and "od" seems to think that line-ends are of the "Microsoft" style. (and nmake is happy) I am also pretty sure that Unix users see the line-ends as single characters. Yep, I fixed this file yesterday. Win32 seems happy, as does UNIX. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] RE: GLU 1.3 tessellation is now in CVS
When you output triangles, so you make any effort to make them strips or fans? If they come out in order, then we can use a simple greedy algorithm to build strips and fans out of arbitrary polygon sets. I don't know if your algorithm does that or could do it easily. (Having you do any stripping on your own probably isn't worth it, but if it happens naturally from the algorithm, that's a win.) Unfortunately it doesn't output the triangles in strip order at the moment, as I'm currently using a priority queue of potential ears and clipping the first triangle in the queue each time. Kind of a way to get "better" triangles, ie. not sliver triangles. However, I have thought about this and will be taking a look at it when I've finished everything else. I guess it would be better to output in strip order and have a few sliver triangles, if possible. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] GLU 1.3 tessellation is now in CVS
Okay, you may have to bear with me a little, I'm without a Linux box at the moment :) The src-glu/ directory now contains my tessellation code, basically contained in tess*.[ch] (I've kept a copy of the old tess.[ch] for now). I've attempted to adjust the makefiles to reflect this, but if I've messed up I'd appreciate any help. Before uploading the code from my NT box at work, it ran fine under Linux but now seems to have problems running the demos under NT. I'll try and track down the cause of this, but I'd also really appreciate someone doing a quick build/test of the tessellation demo in book/tess.c (the star will not work until I fix the winding rule code, which is not in CVS yet. I'll be working on this over the next few days for the beta 3 release). I've defined GLU_VERSION_1_2 in GL/glu.h, but this may cause problems with the lack of NURBS support until someone (me?) updates these functions. Feel free to email me with any comments, questions, problems etc. The final winding rule code should be in by Monday or so. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] RE: GLU 1.3 tessellation is now in CVS
In a few .h files I had to change your //-style comments to /* */ style. Sorry about that. I was sure I'd stopped using those quite a while ago. When I run book/tess it prematurely exits. Here's the stack trace: ... #1 0x400655a3 in fist_recovery_process (tobj=0x8073d28) at tess_fist.c:179 ... If this gets called, something bad has happened. This is one of the fancy things about the FIST algorithm, but I haven't gotten around to implementing it yet. I'll fix this now so the error callback gets called and exits gracefully. Another note: I've just remembered my triangle output hasn't been updated, so will leave the last one out. Also, my calls to the begin/end callbacks are really inefficient, so I'll update this now as well. Thanks for this, Brian. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] RE: GLU 1.3 tessellation is now in CVS
Okay, I've hopefully fixed those problems. When I get home from work tonight I'll be installing Linux on my new machine, so I'll be able to continue testing and debugging then. I assume RedHat 6.0 will hate my brand new ATA-66 HD on a BP6, right? -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] Win32 directory in CVS?
I can update the DSP files, but that would move them over to DevStudio 6 as I no longer have DevStudio 5, and I don't know how that would affect the user base at all (they DSP/DSW files are NOT compatible across versions, although 6 will load -and convert- 5's). Opinions? I'm using 6 at work and home, so that would suit me fine. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] beta 3 release
I'd like to make a 3.1 beta 3 release by the end of next week. There have been quite a few bug fixes since beta 2 but I'm not quite confident enough that a final release is appropriate yet. I'd like to do more conformance testing and get more end user feedback. Fellow developers, any concerns? I'll upload the 1.3 tessellation code so it can be go out with this release. Are there good conformance tests for the GLU tessellation? I'd be interested to see the output of those. I guess it will be several late nights to fix the winding rule bug before Friday week :-) -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] Polygon tessellator
I started working from a copy of Mesa-3.0, so integrating the code back into the 3.1 codebase has taken a little longer than I would have hoped. I'm basically finished cleaning everything up and getting it to the stage that it will compile and run some sanity tests. Of course, in the process of doing this I found a nasty bug in the winding rule code. Had to spend the whole weekend fixing that, but I'll keep working on things during the week. It'll be merged Real Soon Now, I swear :-) Just out of curiosity, what's the general feeling of using C++ code for parts of Mesa, in particular Mesa's GLU implementation? Most of my time over the weekend was spent implementing/fixing some pretty standard storage data structures, as well as some other things that would be considerably easier in C++. Brian? Any comments? My plan is to finish it off this week, but in the future I might do a rewrite in C++ if this is acceptable. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] GLU 1.3
Gareth Hughes ([EMAIL PROTECTED]) has been working on a GLU 1.2 polygon tessellator and I just recently had someone express interest in implementing GLU 1.2 NURBS. As per my previous email, I'm doing some final testing of the code - in particular the winding rules/booleand operations. I plan on merging my changes pretty soon. In the mean time, does anyone have a particularly nasty polygon that I could test with? For instance, I'm getting a polygon-based map of Nth America which breaks SGI's GLU tessellator :-) When I've merged the code, I'd appreciate any testing/feedback etc. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] Lucent Technologies ph: +61 2 9352 8608 Bell Labs Australia mob: 0414 831 018 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] ECMWF samples for tessellation
I just received 5,000 or so polygons from the guys at the ECMWF to test with, so I'll spend this weekend making sure they all tessellate correctly. Once this is done, and once I've fixed up the intersected contour stuff, I'd be pretty confident that the code is done (at least for Mesa 3.1). Mesa 3.3 will be general optimizations I think, as once it all works correctly I can make it run really fast :) Ted, I'm in at work at the moment on a Windows box, so I'll look at soem of the compiler warnings while I'm at it. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
RE: [Mesa-dev] ECMWF samples for tessellation
Cool, much appreciated, not going to have too much time to look at the code myself until Sunday (working 6-day weeks right now). ;^( Me too, that's why I'm working on a Windows box :) I'll be posting new warning logs in the morning, with the "conditional expression is contant" warning disabled and with CVS files as of 11/5/99 21:33 Central Time in the build. I'll disable that warning in my copy now if you haven't committed that fix already. -- Gareth ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] ECMWF sample almost completes
I've checked in some rather significant changes to the tessellation code. The winding rule code has evolved a lot, and all three tessellation demos should work correctly - except the self-intersecting parts of book/tesswind. The first half is okay, but I'm tracking down problems in the segment intersection and selection code now that causes the second half to fail. The new tessdemo is in as well. Arne, all the sample contours you sent me exept one tessellate correctly now. There's one that seems to be rather degenerate (lots of zero-area triangles inside) so I'll update the recovery process code and we should be fine. It might be time to send me the next batch of contours so I can work with them over the weekend. Brian, I fixed a slight bug in the root Makefile.X11 - there was an instance of ($MAKE) instead of $(MAKE) in the cleanup parts. And finally Ted, I just built Mesa on Win32 and got several thousand warnings. This does seems a little high... Are we still trying to fix this? -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
[Mesa-dev] New tessdemo
I've found that your new tessdemo stops working if the lines self intersect. Is this a requested behavior? The self-intersecting code is still under development at the moment. It works in some instances (ie. the star in book/tess), but I'm still ironing out the implementation of contour extraction. The edge picking code gets lost and we end up with a dangling contour (ie. not a closed loop). This will be fixed as a rather high priority, as this and the recovery process are the only things that need work at this stage. Thanks for the mail, I appreciate your testing efforts. -- Gareth == Gareth Hughesmailto:[EMAIL PROTECTED] DEFINITY® Site Administration Project Lucent Technologies, Bell Labs Australia ph: +61 2 9352 8608 ___ Mesa-dev maillist - [EMAIL PROTECTED] http://lists.mesa3d.org/mailman/listinfo/mesa-dev
