Help with NT4 + OpenGL + 3D Hardware Accel

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Brad C Star » Tue, 18 Feb 1997 04:00:00



Hi all,
        Can anyone help with a problem under NT 4 using OpenGL with a MCD that
supports hardware 3D acceleration? When no hardware acceleration (ie old
srivers) are used, everything renders fine. When hardware accelerated MCD
are used ( I have tries the latest Matrox Millenium and Diamond Stealth 3D
2000 drivers), several rendering problems are apparent.

- intersections of polygons are no longer sharply defined and appear to be
randomly 'crinkle cut' , wavy, or undefined at the join.
- some gourard shaded surfaces render with (seemingly randomly) thick
horizontal lines through them which remain horizontal when the object is
translated, rotated or scaled.
- some solid surfaces have parts of the object behind them showing through,
again this changes as the object is moved, rotated or scaled.

Has anyone else seen this problem? Is it just a bug with the Opengl32.dll
that comes with NT 4 or am I setting up the Opengl context incorrectly?

Any help would be great!

Thanks in advance,
                    Brad Stark.


 
 
 

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Angus Dorbi » Tue, 18 Feb 1997 04:00:00



> Hi all,
>         Can anyone help with a problem under NT 4 using OpenGL with a MCD that
> supports hardware 3D acceleration? When no hardware acceleration (ie old
> srivers) are used, everything renders fine. When hardware accelerated MCD
> are used ( I have tries the latest Matrox Millenium and Diamond Stealth 3D
> 2000 drivers), several rendering problems are apparent.

> - intersections of polygons are no longer sharply defined and appear to be
> randomly 'crinkle cut' , wavy, or undefined at the join.

This is lack of depth buffer precision, maybe your software renderer
had more zbuffer precision than the matrox.

Quote:> - some gourard shaded surfaces render with (seemingly randomly) thick
> horizontal lines through them which remain horizontal when the object is
> translated, rotated or scaled.

Could be zbuffer related, I've also seen this with values in glPolygonOffset
which are too large.

Quote:> - some solid surfaces have parts of the object behind them showing through,
> again this changes as the object is moved, rotated or scaled.

Depth buffer precision again.

Quote:

> Has anyone else seen this problem? Is it just a bug with the Opengl32.dll
> that comes with NT 4 or am I setting up the Opengl context incorrectly?

> Any help would be great!

Push the near clip plane out if you can, would a lower resolution give you
more zbuffer bits?
Then again maybe the card or driver has some depth buffer bug.

Cheers,
Angus.

 
 
 

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Blair MacIntyr » Tue, 18 Feb 1997 04:00:00





> > Hi all,
> >       Can anyone help with a problem under NT 4 using OpenGL with a MCD that
> > supports hardware 3D acceleration? When no hardware acceleration (ie old
> > srivers) are used, everything renders fine. When hardware accelerated MCD
> > are used ( I have tries the latest Matrox Millenium and Diamond Stealth 3D
> > 2000 drivers), several rendering problems are apparent.
> > ..

> Just a follow up to this - we are using GLUT to control the OpenGL
> environment so GLUT is in charge of setting up our PixelFormatDescriptor.
> Some of the replies to this article indicate that it may be a z-buffer
> precision problem. If so, does anybody with some intimate knowledge of
> GLUT's win32 code know what might be going wrong when hardward drivers are
> used? I suspect the offending code should be in GlutInitDisplayMode?.

I agree with Angus and the other replies.   This has all the sounds of
being a zbuffer problem.

Intuitively, that the acuracy of the z buffer is related to the
difference in precision between the near and far clipping planes, and
is weighed more heavily to the nearer values.  I had problems as you
describe when I tried to set my near planes to something like 0.1 or
0.01 and the far to something close to 1000.  When I increased the
near value to something nearer 1 or so, things got much better.

--

smail: Dept. of Computer Science, 1214 Amsterdam Ave, Mail Code 0401
       Columbia University, New York, NY 10027-7003

 
 
 

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Ashley Herrin » Wed, 19 Feb 1997 04:00:00




Quote:> Hi all,
>    Can anyone help with a problem under NT 4 using OpenGL with a MCD that
> supports hardware 3D acceleration? When no hardware acceleration (ie old
> srivers) are used, everything renders fine. When hardware accelerated MCD
> are used ( I have tries the latest Matrox Millenium and Diamond Stealth
3D
> 2000 drivers), several rendering problems are apparent.
> ..
> ..
> ..

Just a follow up to this - we are using GLUT to control the OpenGL
environment so GLUT is in charge of setting up our PixelFormatDescriptor.
Some of the replies to this article indicate that it may be a z-buffer
precision problem. If so, does anybody with some intimate knowledge of
GLUT's win32 code know what might be going wrong when hardward drivers are
used? I suspect the offending code should be in GlutInitDisplayMode?.

Thanks all,


 
 
 

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Michael I. Gol » Wed, 19 Feb 1997 04:00:00


| I agree with Angus and the other replies.   This has all the sounds of
| being a zbuffer problem.

I checked the GLUT code - it requests 64 bits of Z, so probably gets the
deepest available depth buffer.  I suspect the hardware accelerator has
only 8 or 16 bits of Z while the software renderer supports 32; this would
explain the discrepency.
--
Michael I. Gold     Silicon Graphics Inc.     http://www.veryComputer.com/
And my mama cried,  "Nanook a no no! Don't be a * eskimo! Save your
money, don't go to the show!"  Well I turned around and I said, "Ho! Ho!"

 
 
 

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Brandon Van Ever » Wed, 19 Feb 1997 04:00:00





> > - some gourard shaded surfaces render with (seemingly randomly) thick
> > horizontal lines through them which remain horizontal when the object
is
> > translated, rotated or scaled.

> Could be zbuffer related, I've also seen this with values in
glPolygonOffset
> which are too large.

This also sounds like the wrong values are being put into the Matrox's RGB
registers, i.e. a bug.  I created a really BEAUTIFUL bug one time, with
lovely plaid patterns all over my drawing surfaces.  It was as though the
colors were completely wrapping around, and I was seeing the color modulo.

You could always keep your Matrox card and trade in your Intel box for an
Alpha workstation.  Then you could use our drivers, which probably don't
have this problem.  :-)

Cheers,
--
Brandon J. Van Every     | Seattlites!  The Northwest *artists want YOU
                         | to help build their artsy-fartsy electro-tech
DEC Commodity Graphics   | virtual worlds stuff!  If interested, contact
me.

 
 
 

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Hock San L » Thu, 20 Feb 1997 04:00:00



says...



>> Hi all,
>>       Can anyone help with a problem under NT 4 using OpenGL with a MCD
that
>> supports hardware 3D acceleration? When no hardware acceleration (ie
old
>> srivers) are used, everything renders fine. When hardware accelerated
MCD
>> are used ( I have tries the latest Matrox Millenium and Diamond Stealth
>3D
>> 2000 drivers), several rendering problems are apparent.
>> ..
>> ..
>> ..

>Just a follow up to this - we are using GLUT to control the OpenGL
>environment so GLUT is in charge of setting up our PixelFormatDescriptor.
>Some of the replies to this article indicate that it may be a z-buffer
>precision problem. If so, does anybody with some intimate knowledge of
>GLUT's win32 code know what might be going wrong when hardward drivers
are
>used? I suspect the offending code should be in GlutInitDisplayMode?.

>Thanks all,



The Matrox Millennium card only accelerates 16-bit depth buffers.  If you
need more than 16-bit z values, you will lose hardware acceleration.

You can write your own ChoosePixelFormat function to pick the best pixel
format descriptor that works for your application.

Hock San Lee
Microsoft

 
 
 

Help with NT4 + OpenGL + 3D Hardware Accel

Post by Sting » Fri, 21 Feb 1997 04:00:00


Here are the first four modes supported by the
Millennium. These are, according to Ron Fosner's Pixel
format utility, the only modes which support the mini-client
driver.

Stingo

=================================================
Microsoft Diagnostics Report For \\ONO
----------------------------------------------------------------------

Video Display Report
----------------------------------------------------------------------
BIOS Date:      10/28/96
BIOS Version:   VGA/VBE BIOS, Version V2.3
                Revision: 0.39

Adapter:

   Setting:     1024 x 768 x 65536
                90 Hz
   Type:        mga64 compatible display adapter
   String:      MGA Millennium
   Memory:      4 MB
   Chip Type:   MGA-2064W R1
   DAC Type:    TI TVP3026, 220 MHz

Driver:

   Vendor:      Matrox Graphics Inc.
   File(s):     mga64.sys, mga64.dll
   Version:     2.33, 4.0.13

================================================================
Current Pixel Format: 1 of 28

dwFlags
-------
DRAW_TO_WINDOW
SUPPORT_GDI
SUPPORT_OPENGL
GENERIC_FORMAT
GENERIC_ACCELERATED

Current Pixel Format Implementation: Mini-Client Driver

ColorBits       16
AccumBits       32
DepthBits       0
AuxBuffers      0
StencilBits     8

        Color Bits      Shift Value     Accum Bits
Red     5               11              11
Green   6               5               11
Blue    5               0               10
Alpha   0               0               0

iPixelType      RGBA
================================================================
Current Pixel Format: 2 of 28

dwFlags
-------
DRAW_TO_WINDOW
SUPPORT_OPENGL
GENERIC_FORMAT
GENERIC_ACCELERATED
DOUBLEBUFFER
SWAP_COPY

Current Pixel Format Implementation: Mini-Client Driver

ColorBits       16
AccumBits       32
DepthBits       0
AuxBuffers      0
StencilBits     8

        Color Bits      Shift Value     Accum Bits
Red     5               11              11
Green   6               5               11
Blue    5               0               10
Alpha   0               0               0

iPixelType      RGBA

================================================================
Current Pixel Format: 3 of 28

dwFlags
-------
DRAW_TO_WINDOW
SUPPORT_GDI
SUPPORT_OPENGL
GENERIC_FORMAT
GENERIC_ACCELERATED
SWAP_COPY

Current Pixel Format Implementation: Mini-Client Driver

ColorBits       16
AccumBits       32
DepthBits       16
AuxBuffers      0
StencilBits     8

        Color Bits      Shift Value     Accum Bits
Red     5               11              11
Green   6               5               11
Blue    5               0               10
Alpha   0               0               0

iPixelType      RGBA

================================================================
Current Pixel Format: 4 of 28

dwFlags
-------
DRAW_TO_WINDOW
SUPPORT_OPENGL
GENERIC_FORMAT
GENERIC_ACCELERATED
DOUBLEBUFFER
SWAP_COPY

Current Pixel Format Implementation: Mini-Client Driver

ColorBits       16
AccumBits       32
DepthBits       16
AuxBuffers      0
StencilBits     8

        Color Bits      Shift Value     Accum Bits
Red     5               11              11
Green   6               5               11
Blue    5               0               10
Alpha   0               0               0

iPixelType      RGBA

======================================================



: Hi all,
:       Can anyone help with a problem under NT 4 using OpenGL with a MCD that
: supports hardware 3D acceleration? When no hardware acceleration (ie old
: srivers) are used, everything renders fine. When hardware accelerated MCD
: are used ( I have tries the latest Matrox Millenium and Diamond Stealth
3D
: 2000 drivers), several rendering problems are apparent.
:  
: - intersections of polygons are no longer sharply defined and appear to
be
: randomly 'crinkle cut' , wavy, or undefined at the join.
: - some gourard shaded surfaces render with (seemingly randomly) thick
: horizontal lines through them which remain horizontal when the object is
: translated, rotated or scaled.
: - some solid surfaces have parts of the object behind them showing
through,
: again this changes as the object is moved, rotated or scaled.
:
: Has anyone else seen this problem? Is it just a bug with the Opengl32.dll
: that comes with NT 4 or am I setting up the Opengl context incorrectly?
:
: Any help would be great!
:
: Thanks in advance,
:                   Brad Stark.
:

:
:  
:

 
 
 

1. Slow OpenGL, how to enable hardware accel?

Hi there,

Why while programming OpenGL (even with GL_POINTS Modelview) in a large
window the image is quite slow, even with a G400 Matrox?

I mean, if you reduce the window size, it becomes a lot faster but the
amount of points to calculate hasn't changed.

Can anybody explain to me how to enable hardware acceleration if this would
solve my problem?

Thanks

2. Draping image maps with no stretching?

3. OpenGL hardware accel - how?

4. from sun illumination [newbie]

5. How to determine hardware accel in OpenGL

6. Moving Images Around in Pictureboxes...

7. SGI release OpenGL window / GLX API as Open Source to bring hardware accel to Linux

8. Phos Monte Carlo Renderer has been updated

9. Howto disable hardware accel OpenGL

10. MGA Millenium hardware OpenGL accel

11. Fullscreen hardware accel in Delphi via OpenGL

12. opengl 3d accel with windows

13. Linux/OpenGL/PC with 3D accel. card