> Well overdraw happens greatly in filled mode, too. So I don't think that's
> the reason. Besides two lines instead of one filled leads to this
> tremendous speed loose? I could think that the OpenGL driver for the GTS2
> is not well optimized for line drawing. >>
There is more overhead in drawing the wireframe, if you think about it as
drawing 3 lines instead of drawing one triangle for example. Most game cards
these days are built to draw big polygons but with a lot of texture detail
(high fill rate). And actually, in my Dos programming days when you had to
create your own raster drawing functions, I found the overhead setting up a
line and triangle to draw (using memset to do fast fills), that a line was
only slightly faster, but when you say you are drawing 3 lines instead of a
triangle then the overhead of the setting up the lines to be drawn can out
weigh setting up a single triangle.
> I don't know what you actually want to hear, but it works. Of course it
> only works properly for solid surfaces, the known problems with BFC. So no
> Hidden Line Removal if you thought about that.
Well I was worried that maybe the edges would have problems with
disappearing. You see if they optimized the drawing of wireframes by not
overdrawing them, I was curious how they determined normals for lines. In the
case of OpenGL it probably draws every poly as a wire frame, so a line in
reality has 2 normals (one for each poly) and will never disappear as an edge.
The reason why I was worried though, is I had created a function that created
NPR (NonPhotoRealistic) outlines by duplicating a mesh, inverting its face
culling and making it a black wireframe. I was worried that in D3D some of
the edges would disappear.
Leyland Needham
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
