mesa3d-users

Re: [Mesa3d-users] Building a new libGL for XF86-4.0/DRI

[Brian P. <br...@pr...>]

"Curtis L. Olson" wrote:
> 
> Greetings,
> 
> I'd like to try to build a replacement libGL.so for my system to test
> some recent Mesa bug fixes related to some color/lighting problems.
> 
> I currently have a Voodoo-3 card, XFree86-4.0, GLX, DRI all running
> with acceleration in a window and all that nice stuff.
> 
> But, when I try to build a replacement libGL.so for this system I get
> software only rendering.  The configure script does find my glide.h
> and libglide3.so.

XFree86 doesn't use configure scripts.  I think there's some confusion
here.

1. Start with either the latest XFree86 or DRI CVS sources (at this
point, the two source bases are pretty much in sync).  Make sure
you can build and use that successfully.

2. If you want to upgrade the Mesa components within XFree86 you'll
have to get the latest Mesa sources out of Mesa's CVS tree.  Then, copy
them into the xc/extras/Mesa/src/ directory.  Specifically:
	cp Mesa-3.3/src/*.[ch] xc/extras/Mesa/src/
	cp Mesa-3.3/src/X86/*.[chS] xc/extras/Mesa/src/X86/
	cp Mesa-3.3/src/X/*.[chS] xc/extras/Mesa/src/X/

DO NOT copy the Mesa-3.3/src/FX files to xc/extras/Mesa/src/FX.

3. Recompile your XFree86/DRI tree.


> What other things do I need to do to get a XF86/DRI aware version of
> libGL.so?  I'm happy to read documentation and follow instructions,
> but so far I can find nothing on the net or in the Mesa docs related
> to this.  Can anyone provide any tips, or point me towards the
> appropriate documentation?

Mesa itself knows absolutely nothing about the DRI or XFree86.
It's XFree86 that pulls in Mesa and hooks it into the X server and
DRI (in simple terms).

-Brian

[Mesa3d-users] Building a new libGL for XF86-4.0/DRI

[Curtis L. O. <cu...@me...>]

Greetings,

I'd like to try to build a replacement libGL.so for my system to test
some recent Mesa bug fixes related to some color/lighting problems.

I currently have a Voodoo-3 card, XFree86-4.0, GLX, DRI all running
with acceleration in a window and all that nice stuff.

But, when I try to build a replacement libGL.so for this system I get
software only rendering.  The configure script does find my glide.h
and libglide3.so.

What other things do I need to do to get a XF86/DRI aware version of
libGL.so?  I'm happy to read documentation and follow instructions,
but so far I can find nothing on the net or in the Mesa docs related
to this.  Can anyone provide any tips, or point me towards the
appropriate documentation?

Thanks,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       Flight Gear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Mesa3d-users] help with "make"/"install" of mesa

[Mircea M. <mm...@ss...>]

On Tue, 27 Jun 2000, I'm Your Handiman -online- wrote:

> hi anyone..
> 
>   i use redhat 6.0/2.2.5-15
> 
> ./configure worked fine but make/make install
> giving following : ( is this error or normal for this package/my system)
> 
> [root@localhost Mesa-3.2]# make
> \make  all-recursive
> make[3]: Entering directory `/usr/local/Mesa-3.2/include/GL'
<snip>
> make[3]: *** No rule to make target `glut.h', needed by `all-am'.  Stop.
Did you downloaded MesaDemos package too? glut is in this package.
Please consider to uncompress it under the same source tree as MesaLib.

---
Mircea Mitu
mm...@ss...     http://web.ss.pub.ro/~mms
mir...@go...   http://mirceamms.go.ro (mirror)
...
Please ingnore spelling and punctuation - I did.

[Mesa3d-users] help with "make"/"install" of mesa

[I'm Y. H. -online- <le...@im...>]

hi anyone..

  i use redhat 6.0/2.2.5-15

./configure worked fine but make/make install
giving following : ( is this error or normal for this package/my system)

[root@localhost Mesa-3.2]# make
\make  all-recursive
make[1]: Entering directory `/usr/local/Mesa-3.2'
Making all in include
make[2]: Entering directory `/usr/local/Mesa-3.2/include'
Making all in GL
make[3]: Entering directory `/usr/local/Mesa-3.2/include/GL'
make[3]: *** No rule to make target `glut.h', needed by `all-am'.  Stop.

make[3]: Leaving directory `/usr/local/Mesa-3.2/include/GL'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/local/Mesa-3.2/include'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/Mesa-3.2'
make: *** [all-recursive-am] Error 2

thanks for any help

lee

Re: [Mesa3d-users] MesaOS triangle functions

[Brian P. <br...@pr...>]

Matt Campbell wrote:
> 
> I was wondering if someone could tell me which triangle functions would
> get called if I were rendering to an OSMesaContext.  For example, when
> rendering to a normal device context the functions in triangle.c get
> called but does this still remain the same when rendering to an OSMesa
> context??

What's a "normal device context"?

The OSMesa driver will use the triangle functions in src/OSmesa/osmesa.c
whenever possible.  Otherwise, the triangle functions in src/triangles.c
will be used.


> I need to modify the actual rendering functions but I'm not sure which
> ones to modify.

There are lots of different triangle functions for flat/smooth shading,
RGB/CI mode, textured/untextured, etc.  You may have to modify all of
them if you want your new feature to be pervasive.

-Brian

[Mesa3d-users] MesaOS triangle functions

[Matt C. <mca...@vt...>]

I was wondering if someone could tell me which triangle functions would
get called if I were rendering to an OSMesaContext.  For example, when
rendering to a normal device context the functions in triangle.c get
called but does this still remain the same when rendering to an OSMesa
context??

I need to modify the actual rendering functions but I'm not sure which
ones to modify.

Thanks in advance.

Matt Campbell
Undergraduate (Computer Science Department)
Virginia Tech
mca...@vt...

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[John S. <joh...@cr...>]

Brian, Stephen, and Robert;


I was using the Voodoo3 full screen drivers; have almost got
the DRI version working.

I'll see if that makes any difference...

Thanks guys;

John.

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[Brian P. <br...@pr...>]

Stephen J Baker wrote:
> 
> On Fri, 23 Jun 2000, John Stewart wrote:
> 
> > I maintain the FreeWRL VRML browser, and I have an
> > OpenGL quandry that I would like to investigate. Help
> > in getting me started would be great. I am *not* an
> > experienced opengl programmer.
> >
> > Color mappings are ok when using Mesa and software
> > rendering.
> >
> > When I go to hardware rendering (Voodoo 2 and 3, non DRI)
> > colours of some nodes are way off, and change depending
> > on what other elements are in the picture.
> 
> I believe there are at least two problems in the colour
> rendering path under Mesa for Voodoo 1/2/3.  The problem
> seems to relate to glColorMaterial's behavior under
> certain conditions.  Somehow, a change in colour does
> not get registered correctly - so whatever polygon
> that should get rendered in that new colour picks up
> the colour of the previously rendered polygon - which
> is why the incorrect colour depends on what other
> elements are in the picture.
> 
> I have seen this problem in several applications - and
> seen those same applications function perfectly both in
> software Mesa and on the nVidia OpenGL driver for Linux.
> 
> I have yet to be able to narrow the problem down enough
> to make a coherent bug report though - and I need to
> test it out with the latest Mesa because it may already
> be fixed.
> 
> There has been considerable discussion of this on the PLIB
> developers mailing list - which is archived here:
> 
>   http://www.geocrawler.com/lists/3/SourceForge/1868/0/
> 
> Search for colormaterial or color_material.
> 
> Another possibility (which is a common OpenGL programming
> error) is that you rendered a textured polygon and then
> rendered a non-textured polygon without doing a glDisable(GL_TEXTURE_2D).
> 
> The effect of that is that the last glTexCoord and glBindTexture
> remain in effect for the following polygon(s).  Since there are
> no new glTexCoord command, every vertex of the polygon gets textured
> with the same texel - infinitely stretched.
> 
> The result *looks* like a simple colour change - and obviously
> it depends on whatever polygon vertex was rendered immediately
> prior to this error.
> 
> It tends to look different (but rarely "correct") under software
> rendering because the texture math is considerably stressed by
> having to interpolate over zero change like that - and the
> roundoff errors that result are different in Software and Hardware
> Mesa.
> 
> I doubt that's the problem in your case - but it's certainly
> possible.
> 
> There are other similar errors you could have made with OpenGL
> state information being incorrectly set prior to rendering
> that would produce similar effects - but it's hard to think
> of one that's going to operate differently on software Mesa
> versus Voodoo-2/3.
> 
> If you are using glColorMaterial or two-sided lighting and
> glMaterial - then I *suspect* that you have the same problem
> as me.
> 
> If so - and especially if you can reduce it to a tiny test
> case - then we need to talk - every attempt I've made to
> reduce it to a program of manageable size has somehow tricked
> the bug into "going away".

OK, I've pretty much spent the day fixing lighting bugs in Mesa.
Since the 3.1 T&L optimizations specular highlights have been
mispositioned and material updates sometimes produced unexpected
results.

I think I've fixed all these problems.  I've checked in my changes
to the Mesa CVS trunk (3.3).  Please test and let me know if things
have improved.

John: unfortunately, I doubt these'll help with your problem.  I'm
still looking at that.

-Brian

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[Stephen J B. <sj...@li...>]

On Mon, 26 Jun 2000, John Stewart wrote:

> FYI, I have put up a fairly large gif of my colours problem.
> Don't look at this over a modem...
> 
> http://www.crc.ca/FreeWRL/my_whole_sequence.gif
> 
> It should look like (and does, sw emulation mode)
> 
> http://www.crc.ca/FreeWRL/animated_blimp.gif
 
OK - I take it all back.  This doesn't look like any of
the things that have been suggested so far.

I'd suspect an application bug.  Is it possible that
your per-vertex colours are coming from an array that's
been free()'d or something?   That could operate differently
in hard and software rendering because of different memory
allocation patterns and such like.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-users] NVidia GeForce/GeForce2 with XFree86 3.3.6 and Mesa 3.2

[Stephen J B. <sj...@li...>]

On Mon, 26 Jun 2000, Andrew C Aitchison wrote:

> Dave Reed wrote:
> > I'm not interested in playing games with it, but I am interested in
> > visualization (using VTK right now) so I'm interested in being able to
> > render lots of small shaded polygons and 3D texturing (for volume
> > visulization).
> > 
> > I'm planning to spend around $250-$350 and would rather closer to the
> > high end than spend $200 now and find myself wishing I'd spent more
> > and wanting to buy a new card a year from now.  Any recommendations?
> >
> >My current sytem is a 400 MHz Pentium II with an Asus P2B motherboard
> 
> If you are after shaded polygons and 3D texture, the CPU is likely to
> be the bottleneck, not the graphics card. The latest games cards and
> high-end "professional" cards (well out of your price range) can
> do the vertex calculations in a "geometry engine" and take the load
> off the cpu, but as far as I am aware the XFree86 drivers just
> aren't ready to take advantage of them (3.3.6 or 4.0).
> 
> It could be six months before you get XFree86 driving your card at
> full speed. In your position I would get a faster CPU now and a 
> new card later.
> 
> If I'm wrong about the latest drivers, will someone on the list
> please shout ?
 
*SHOUT*

The nVidia GeForce-256 and GeForce-2 chipsets (on various
boards) are both within the $200-$350 price range - and both
have kick-ass geometry engines that unload the vertex calcs
from the main CPU.  I'm not aware of *ANY* 3D graphics
engine at *ANY* price that can beat the 25M triangles/sec
that the GeForce-2 claims to be able to process.

You may still need a good CPU to get the most from the
card - just to feed the raw data fast enough to stop
it getting starved of data.

Using the nVidia OpenGL-for-Linux drivers and Xfree86 4.0.0,
you can drive either of those cards at speeds comparable
to the nVidia windoze driver.

However, actually getting 25M triangles/sec out of the
card will entail some pretty serious tweaking.  However,
with a decent CPU you ought to be able to manage 5Mtps
in a reasonably well written application.

I use this setup at home and at work - so I can assure you
that it works very well.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-users] NVidia GeForce/GeForce2 with XFree86 3.3.6 and Mesa 3.2

[Stephen J B. <sj...@li...>]

On Sun, 25 Jun 2000, Dave Reed wrote:

> I'm planning to get a NVidia graphics card and am a little overwhelmed
> by all the information out there and know I don't fully understand it,
> so I've got a bunch of questions:
> 
> First, according to the XFree86.org web site, 3.3.6, it says the
> GeForce chip is newly supported.  Does this mean 3D support when using
> Mesa or just that X will run, but not take full advantage of the card?
 
The *nVidia* OpenGL implementation certainly requires Xfree 4.0.0, I
understand that the Utah-GLX driver may work with 3.3.6.

Be careful what you read into statements on XFree86's site - they
often talk about "support" in terms of 2D support for X - not 3D
support for OpenGL with hardware accelleration.

> Does GeForce include GeForce2 also?

Yes - the nVidia driver (and probably the Utah-GLX) works just fine
with GeForce2 - I've done it so I know for sure.

>  From what I've read at
> tomshardware.com, it seems that GeForce2 is mainly just a faster
> GeForce...

Well, it's quite a bit more than that - but the current drivers don't
expose the new features of GeForce-2.  That's annoying - but
understandable in the short term.

>  And will it work faster
> when I get around to using XFree86 4.0?

GeForce-2 was only a little faster than GeForce-1 on my 450MHz box,
I think I need a faster CPU to take full advantage of the new card.

>  I probably won't get XFree86
> 4.0 until it comes with RedHat 7.x (currently have 6.2) unless the
> performance increase is huge in which case, I might tackle trying to
> install 4.0 myself.

You *NEED* 4.0 for the nVidia driver - and IMHO, the nVidia driver is
*FAR* faster and more stable than the Utah-GLX effort (although that
could change - I havn't tested the Utah-GLX driver for at least a
month).

> Can anyone explain the differences in plain English betwen SDR, DDR,
> and GTS (see http://www.G256.com/features/gfpricewatch.html).
 
Nope.   :-)

> I'm not interested in playing games with it, but I am interested in
> visualization (using VTK right now) so I'm interested in being able to
> render lots of small shaded polygons and 3D texturing (for volume
> visulization). 
 
Cool!

(Does 3D texturing work yet?  I havn't tried it.)

> I'm planning to spend around $250-$350 and would rather closer to the
> high end than spend $200 now and find myself wishing I'd spent more
> and wanting to buy a new card a year from now.  Any recommendations?
>
> My current sytem is a 400 MHz Pentium II with an Asus P2B motherboard
> (I believe it is only 1xAGP).  A year from now, I may get a new
> motherboard and faster chip (800 MHz PIII) so I don't mind buying a
> card now that is overkill for the PII 400 if it will work better with
> a 800 MHz chip.
 
I think that (in my experience) the GeForce-2 deserves a fast CPU.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[Stephen J B. <sj...@li...>]

On Fri, 23 Jun 2000, John Stewart wrote:

> I maintain the FreeWRL VRML browser, and I have an
> OpenGL quandry that I would like to investigate. Help
> in getting me started would be great. I am *not* an
> experienced opengl programmer.
> 
> Color mappings are ok when using Mesa and software 
> rendering.
> 
> When I go to hardware rendering (Voodoo 2 and 3, non DRI)
> colours of some nodes are way off, and change depending
> on what other elements are in the picture.
 
I believe there are at least two problems in the colour
rendering path under Mesa for Voodoo 1/2/3.  The problem
seems to relate to glColorMaterial's behavior under
certain conditions.  Somehow, a change in colour does
not get registered correctly - so whatever polygon
that should get rendered in that new colour picks up
the colour of the previously rendered polygon - which
is why the incorrect colour depends on what other
elements are in the picture.

I have seen this problem in several applications - and
seen those same applications function perfectly both in
software Mesa and on the nVidia OpenGL driver for Linux.

I have yet to be able to narrow the problem down enough
to make a coherent bug report though - and I need to
test it out with the latest Mesa because it may already
be fixed.

There has been considerable discussion of this on the PLIB
developers mailing list - which is archived here:

  http://www.geocrawler.com/lists/3/SourceForge/1868/0/

Search for colormaterial or color_material.

Another possibility (which is a common OpenGL programming
error) is that you rendered a textured polygon and then
rendered a non-textured polygon without doing a glDisable(GL_TEXTURE_2D).

The effect of that is that the last glTexCoord and glBindTexture
remain in effect for the following polygon(s).  Since there are
no new glTexCoord command, every vertex of the polygon gets textured
with the same texel - infinitely stretched.

The result *looks* like a simple colour change - and obviously
it depends on whatever polygon vertex was rendered immediately
prior to this error.

It tends to look different (but rarely "correct") under software
rendering because the texture math is considerably stressed by
having to interpolate over zero change like that - and the
roundoff errors that result are different in Software and Hardware
Mesa.

I doubt that's the problem in your case - but it's certainly
possible.

There are other similar errors you could have made with OpenGL
state information being incorrectly set prior to rendering
that would produce similar effects - but it's hard to think
of one that's going to operate differently on software Mesa
versus Voodoo-2/3.

If you are using glColorMaterial or two-sided lighting and
glMaterial - then I *suspect* that you have the same problem
as me.

If so - and especially if you can reduce it to a tiny test
case - then we need to talk - every attempt I've made to
reduce it to a program of manageable size has somehow tricked
the bug into "going away".

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[John S. <joh...@cr...>]

Hi all;

FYI, I have put up a fairly large gif of my colours problem.
Don't look at this over a modem...

http://www.crc.ca/FreeWRL/my_whole_sequence.gif

It should look like (and does, sw emulation mode)

http://www.crc.ca/FreeWRL/animated_blimp.gif


The Perl code to take a snap shot calls these functions:
(they map directly into the C functional equivs)

        glPixelStorei(&GL_UNPACK_ALIGNMENT,1);
        glPixelStorei(&GL_PACK_ALIGNMENT,1);
        glReadPixels(0,0,$w,$h,&GL_RGB,&GL_UNSIGNED_BYTE,
                $str);

Does the glReadPixels get values from a frame buffer on the 
card, or does it not go down that far?

Anyway, and help appreciated, even if it is only a virtual
prayer. :-)


-- 
John Stewart
joh...@cr...      http://www.crc.ca/FreeWRL/

If windows is the answer, it must have been a stupid question.

Re: [Mesa3d-users] NVidia GeForce/GeForce2 with XFree86 3.3.6 and Mesa 3.2

[Andrew C A. <A.C...@dp...>]

Dave Reed wrote:
> I'm not interested in playing games with it, but I am interested in
> visualization (using VTK right now) so I'm interested in being able to
> render lots of small shaded polygons and 3D texturing (for volume
> visulization).
> 
> I'm planning to spend around $250-$350 and would rather closer to the
> high end than spend $200 now and find myself wishing I'd spent more
> and wanting to buy a new card a year from now.  Any recommendations?
>
>My current sytem is a 400 MHz Pentium II with an Asus P2B motherboard

If you are after shaded polygons and 3D texture, the CPU is likely to
be the bottleneck, not the graphics card. The latest games cards and
high-end "professional" cards (well out of your price range) can
do the vertex calculations in a "geometry engine" and take the load
off the cpu, but as far as I am aware the XFree86 drivers just
aren't ready to take advantage of them (3.3.6 or 4.0).

It could be six months before you get XFree86 driving your card at
full speed. In your position I would get a faster CPU now and a 
new card later.

If I'm wrong about the latest drivers, will someone on the list
please shout ?


Andrew C Aitchison

Re: [Mesa3d-users] NVidia GeForce/GeForce2 with XFree86 3.3.6 and Mesa 3.2

[physic <ph...@te...>]

> First, according to the XFree86.org web site, 3.3.6, it says the
> GeForce chip is newly supported.  Does this mean 3D support when using
> Mesa or just that X will run, but not take full advantage of the card?

No.  Mesa does not, and will probably never support nvidia cards.  This is
according to nvidia's grand design.  NVidia does release their own drivers
so go to their website for information, or search linuxgames.com for
nvidia.

> Dave

--physic
ph...@te...

[Mesa3d-users] NVidia GeForce/GeForce2 with XFree86 3.3.6 and Mesa 3.2

[Dave R. <dr...@ca...>]

I'm planning to get a NVidia graphics card and am a little overwhelmed
by all the information out there and know I don't fully understand it,
so I've got a bunch of questions:

First, according to the XFree86.org web site, 3.3.6, it says the
GeForce chip is newly supported.  Does this mean 3D support when using
Mesa or just that X will run, but not take full advantage of the card?

Does GeForce include GeForce2 also?  From what I've read at
tomshardware.com, it seems that GeForce2 is mainly just a faster
GeForce so I'm guessing it will also work.  And will it work faster
when I get around to using XFree86 4.0?  I probably won't get XFree86
4.0 until it comes with RedHat 7.x (currently have 6.2) unless the
performance increase is huge in which case, I might tackle trying to
install 4.0 myself.

Can anyone explain the differences in plain English betwen SDR, DDR,
and GTS (see http://www.G256.com/features/gfpricewatch.html).

I'm not interested in playing games with it, but I am interested in
visualization (using VTK right now) so I'm interested in being able to
render lots of small shaded polygons and 3D texturing (for volume
visulization). 

I'm planning to spend around $250-$350 and would rather closer to the
high end than spend $200 now and find myself wishing I'd spent more
and wanting to buy a new card a year from now.  Any recommendations?

My current sytem is a 400 MHz Pentium II with an Asus P2B motherboard
(I believe it is only 1xAGP).  A year from now, I may get a new
motherboard and faster chip (800 MHz PIII) so I don't mind buying a
card now that is overkill for the PII 400 if it will work better with
a 800 MHz chip.

Thanks,
Dave

P.S. Feel free to e-mail me off list and I can put together a summary
since this isn't completely on topic for Mesa.

Re: [Mesa3d-users] Mesa-Glide killing system?

[Daniel V. <vo...@lo...>]

"J. Perkins" wrote:
> 
> I am trying to dynamically load Mesa under Linux using dlopen(), dlsym(),
> etc. On the software, RIVA, and TNT drivers, this works fine. The Glide
> driver runs fine, but on exit my desktop is completely frozen, locked up
> tight. If I statically link to the Mesa-Glide libGL.so, everything works fine.
> 
> I've had a look through the source code to try and pin down this behavior,
> but so far no luck. Does anyone have any idea why I would not be able
> to dynamically load Mesa-Glide? Is there some function that I need to
> call before shutting down that I am perhaps missing? (I am already
> releasing and destroying the context before unloading).
> 
> This is Mesa 3.2 on a more-or-less stock RH6.1 system.
> 
> Any help greatly appreciated,

Try "export MESA_FX_NO_SIGNALS=1" before starting or
putenv("MESA_FX_NO_SIGNALS=1") in your code before dlopen'ing. This will
force Mesa not to install its own signal and atexit handler. I guess the
problem in your case is that upon atexit your Mesa dll is already
unloaded.

-- 
Daniel Vogel
Programmer
Loki Entertainment Software

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[Robert M. W. Jr. <rm...@wo...>]

Hi,

I'm not, by far, an expert on the subject (OpenGL programming)
but I have noticed differences in the way "default" normals are
handled between different GL implementations.  That is to say,
when rendering points, lines, etc, and _not_ specifying a normal,
the actual display varies between GL implementations.  I have
not noticed problems with colors, but have noticed problems
with shading (colors or lack thereof?).

Just had to mention this when I noticed no 'glNormal' calls
amidst the 'glVertex' calls in the sample code.

Good luck.....

At 02:23 PM 6/23/00 -0400, you wrote:
>Hi Brian;
>
>Yes, downloaded earlier this week.
>
>As mentioned, it works with software-only rendering, but
>breaks when using a Voodoo[2,3] card.
...
>
>Brian Paul wrote:
>
>> Sounds like possible red/blue swapping.  This was fixed for Mesa 3.2.
>> Is that what you're using?
>> 
>> -Brian
>
>Thanks;
>
>John.
>
>_______________________________________________
>Mesa3d-users mailing list
>Mes...@li...
>http://lists.sourceforge.net/mailman/listinfo/mesa3d-users

Robert M. Wheat, Jr.
E-Mail: rm...@wo...

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[John A. S. <lu...@ma...>]

Hi Brian;

Yes, downloaded earlier this week.

As mentioned, it works with software-only rendering, but
breaks when using a Voodoo[2,3] card.

I just picked up the OpenGL Reference Manual, and will try to 
trace and understand what is happening in FreeWRL.

BTW - the code fragment also seems to be OK on our Onyx II,
that big purple dinosaur. :-|

Tuomas Lukka, the creator of FreeWRL, wrote pretty straight
OpenGL code; no glut here. (need own event loop, and I think that
that is not really possible with glut) It is possible that some
gl* call was missed that affects only hardware rendering on the
Voodoo platform. I guess...

Brian Paul wrote:

> Sounds like possible red/blue swapping.  This was fixed for Mesa 3.2.
> Is that what you're using?
> 
> -Brian

Thanks;

John.

Re: [Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[Brian P. <br...@pr...>]

John Stewart wrote:
> 
> Hello all;
> Hi Mesa people;
> 
> I maintain the FreeWRL VRML browser, and I have an
> OpenGL quandry that I would like to investigate. Help
> in getting me started would be great. I am *not* an
> experienced opengl programmer.
> 
> Color mappings are ok when using Mesa and software
> rendering.
> 
> When I go to hardware rendering (Voodoo 2 and 3, non DRI)
> colours of some nodes are way off, and change depending
> on what other elements are in the picture.
> 
> How are color mappings mapped? *why* would some things
> map perfectly between software and hardware rendering,
> (eg, Cones, Spheres) and other things (Backgrounds) not?
> 
> How do I "lock in" colour maps?
> 
> Some of the background is a simple sphere, which follows
> you wherever you go. It consists of a bunch of code like:
> 
> /* GL_QUADS begin */
> glColor3f(0.000000,0.000000,0.800000);
> glVertex3f(0.877201,0.480124,0.000000);
> glVertex3f(0.709319,0.480124,0.516089);
> 
> glColor3f(0.000000,0.000000,0.300000);
> glVertex3f(0.000000,1.000000,0.000000);
> glVertex3f(0.000000,1.000000,0.000000);
> 
> glColor3f(0.000000,0.000000,0.800000);
> ...
> 
> Help in pointing in the right direction would be very
> much appreciated.

Sounds like possible red/blue swapping.  This was fixed for Mesa 3.2.
Is that what you're using?

-Brian

[Mesa3d-users] Wierd colour mapping when switching to hw accelleration.

[John S. <joh...@cr...>]

Hello all;
Hi Mesa people;

I maintain the FreeWRL VRML browser, and I have an
OpenGL quandry that I would like to investigate. Help
in getting me started would be great. I am *not* an
experienced opengl programmer.

Color mappings are ok when using Mesa and software 
rendering.

When I go to hardware rendering (Voodoo 2 and 3, non DRI)
colours of some nodes are way off, and change depending
on what other elements are in the picture.

How are color mappings mapped? *why* would some things
map perfectly between software and hardware rendering,
(eg, Cones, Spheres) and other things (Backgrounds) not?

How do I "lock in" colour maps?

Some of the background is a simple sphere, which follows
you wherever you go. It consists of a bunch of code like:

/* GL_QUADS begin */
glColor3f(0.000000,0.000000,0.800000);
glVertex3f(0.877201,0.480124,0.000000);
glVertex3f(0.709319,0.480124,0.516089);

glColor3f(0.000000,0.000000,0.300000);
glVertex3f(0.000000,1.000000,0.000000);
glVertex3f(0.000000,1.000000,0.000000);

glColor3f(0.000000,0.000000,0.800000);
...

Help in pointing in the right direction would be very
much appreciated.

-- 
John Stewart
joh...@cr...      http://www.crc.ca/FreeWRL/

If windows is the answer, it must have been a stupid question.

[Mesa3d-users] Mesa-Glide killing system?

[J. P. <ja...@37...>]

I am trying to dynamically load Mesa under Linux using dlopen(), dlsym(),
etc. On the software, RIVA, and TNT drivers, this works fine. The Glide
driver runs fine, but on exit my desktop is completely frozen, locked up
tight. If I statically link to the Mesa-Glide libGL.so, everything works fine.

I've had a look through the source code to try and pin down this behavior,
but so far no luck. Does anyone have any idea why I would not be able
to dynamically load Mesa-Glide? Is there some function that I need to 
call before shutting down that I am perhaps missing? (I am already 
releasing and destroying the context before unloading).

This is Mesa 3.2 on a more-or-less stock RH6.1 system.

Any help greatly appreciated,

Jason Perkins
379

Re: [Mesa3d-users] XFree86 4.0 and Mesa3d.

[Stephen J B. <sj...@li...>]

On Wed, 21 Jun 2000, Martin Olveyra wrote:

> question 2:
> What is exactly GLX? Why doesnt appears neither in XFree86 4.0 nor Mesa3D
> distributions? Does GLX works through DRI?
 
GLX is two (confusingly similarly named) things:

1) The glX API which has the necessary hooks to allow applications
   to connect X windows and OpenGL rendering contexts.

   eg
        glXChooseVisual
        glXCreateContext
        glXSwapBuffers

   glX isn't portable outside of X-windows - so under M$-windoze you
   have 'wgl' calls like 'wglSwapBuffers'.  Under MacOS you get 'agl'
   ...and so on.  This usage of the term "glX" is present in all OpenGL
   implementations under X-windows, including Mesa/XFree4.0.

2) A protocol layer that theoretically exists between the application
   and the underlying renderer to pass rendering commands to the renderer
   and results back to the application.

   I say "theoretically exists" because DRI's objective is eliminate
   the GLX layer and let you do "Direct Rendering" (the 'DR' in 'DRI').

   However, GLX is still important when (for example) you are running
   your program on a remote host machine and your local machine is
   simply acting like an X-terminal.  The OpenGL commands made by the
   program on the host are sent via the GLX protocol (like other X
   commands) to the machine on your desk that does the rendering.

   Theoretically, GLX allows this to work even when one machine is
   (say) an SGI box running IRIX and SGI's own OpenGL and the other
   a PC running Linux and Mesa.  In practice that doesn't work all
   that well (yet).

   Some OpenGL implementations (eg Utah-GLX) use GLX even on a
   single machine - which is why they are (currently) slower than
   DRI.  The idea is to merge the two and have OpenGL use DRI when
   it can - and fall back on GLX when it can't.

   I don't think other (non-X-windows-based) OS's have an equivelent
   to the GLX protocol.

> question 3:
> Does glut works through DRI?
 
GLUT uses the glX API (under X-windows) or wgl (under M$-windoze) and
OpenGL - so if those use DRI, so will GLUT.   If they use the GLX
protocol then GLUT will too.

GLUT is nothing really magical - it's just a chunk of application
code provided for convenience.

Try to say 'glX' when you mean the API and 'GLX' when you mean
the protocol and that'll minimise confusion.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

[Mesa3d-users] XFree86 4.0 and Mesa3d.

[Martin O. <mo...@Im...>]

I have tried to understand the interaction between the different GL libraries,
the glide driver, the video hardware (based on 3Dfx) and XFree86 4.0. I think
the mechanism is as follows:

First we have the video hardware with the 3Dfx chipset.
Then we have the glide driver, which is a set of C functions that performs the
basic hardware capabilities of that chipset. Next, we have the DRI, a kind of
parallel "X server" which makes posible a direct access to the driver without
using the slow services of xlib and x toolkits.
Then comes the high level libraries: GL, an API for 3D programming
primitives. Then, GLU and glut, which are builded using that primitives; the
former implements higher level utilities and the second the basic interaction
to the X system.

question 1:
Is that true? (please confirm or reject this and expand my knowledge):

question 2:
What is exactly GLX? Why doesnt appears neither in XFree86 4.0 nor Mesa3D
distributions? Does GLX works through DRI?

question 3:
Does glut works through DRI?

Thanks.

Re: [Mesa3d-users] (no subject)

[Stephen J B. <sj...@li...>]

On Mon, 19 Jun 2000, david besnard wrote:

> I want to know if it is possible to use a image in the format jpg or bmp
> for texturing .
> if it is possible how can I do this
 
It's certainly possible.

Mesa (and OpenGL) have no special functions for loading images, you
have to do that yourself - or find a support library to do it for you.
Hence, there is no special image format for OpenGL programs. Dunno about
BMP - but for JPEG, you need to use libjpeg to pull the image into memory
and then add jour own code to stuff it into texture memory.

Personally, I try to avoid JPEG (because it *sucks*) and BMP (because
it's Microsoft *and* it sucks) and instead I support PNG (because it's
*wonderful*) and SGI's RGB format (because it's *simple*).

For PNG images, check out 'glpng' (just do a Google search and you'll find
it) - for RGB images, you can write your own loader in about 10 minutes
from the spec:

  ftp://sgi.com/graphics/SGIIMAGESPEC

...or steal one from one of the Mesa sample programs.

My anti-JPEG *rant* is here:

  http://web2.airmail.net/sjbaker1/jpegs_are_evil_too.html

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@li...           http://www.link.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1