(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
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
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
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
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
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
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.
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
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
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®
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
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
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
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 -
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
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
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
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
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
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
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
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,
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 Hughes
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
39 matches
Mail list logo
