PDA

View Full Version : does gl back face culling have anything to do with the passed normal ie glNormal3fv()



wildeyedboyfromfreecloud
03-13-2002, 05:30 PM
sorry for the simplicity but at at least it is opengl related this time. i seem to get alternating back face culling for my triangle meshes even though i know the normals are dead on. any thoughts are apreciated

SirKnight
03-13-2002, 07:17 PM
This is a very beginner question but i wont be an ass (this time, hehe http://www.opengl.org/discussion_boards/ubb/wink.gif)and ill answer you. http://www.opengl.org/discussion_boards/ubb/smile.gif OpenGL looks at the winding order of a poly to determine if its front for back facing. Now im not sure exactly how opengl does it, but im betting it takes 3 of the points of your poly and generates a normal and checks that to determine if its front or back facing. But i could be wrong. At least thats how i would do it if i wrote an api or softare engine.

Oh ya, so it doesnt matter what you pass to glNormalXX. It does its own stuff to determine facingness.

-SirKnight

[This message has been edited by SirKnight (edited 03-13-2002).]

Diapolo
03-13-2002, 07:20 PM
Backface Culling occurs to a primitive, that is not facing the "viewer".
You can tell OpenGL which draw order for primitives specifies a front-facing one (that donīt getīs culled, if Backface Culling is enabled).

You can tell OGL, that the front facing primitives are build of vertices in the counterclockwise order with this command:
glFrontFace(GL_CCW);

If you would like OGL to consider the primitives, that are build of vertices in the clockwise order, you use this command:
glFrontFace(GL_CW);

Which side should be culled is specified with:
glCullFace(GL_BACK);
glCullFace(GL_FRONT);

And you can enable Face Culling with:
glEnable(GL_CULL_FACE);

I hope that sounds clear, because it was not that easy to explain for me (Iīm german *g*) http://www.opengl.org/discussion_boards/ubb/smile.gif.

Diapolo

[This message has been edited by Diapolo (edited 03-13-2002).]

wildeyedboyfromfreecloud
03-13-2002, 07:24 PM
yeah i realize how beginner it is. i meant to say that in the post. but it slipped my mind. it just seems so counter intuitive. if you are passing normals... why calculate them. seems like a waste too me anyway you cut it. i just don't want to get tangled up in the beginners board. and what is a beginner. i'm not comfortable with that. generally a beginner in my mind would be a naive person who thinks they want to make games or something no offense. may a masters forum or a middle weight forum would be in order. i just wonder if i would get an intelligible answer in a beginners forum. i duno maybe i should give it a go. but i won't. not worth the confusion of sorting my questions into categories. if i had one of the books i'd give it a go. if anyone wants to let some go for like $2.00 or less i'll take you up on it.

wildeyedboyfromfreecloud
03-13-2002, 07:27 PM
i apreciate the advice. hope it was a good english exercise. i give you an A. but don't stress yourself over my dumb questions. i will have to pay attention to my ordering. i alway get confused when i have to calsulate normals. i draw them all on paper so i can figure out which way is clock wise.

Tom Nuydens
03-14-2002, 12:28 AM
Backface culling has nothing to do with the normal. It's done by calculating the signed area of the triangle in window coordinates. The equation used for this is in the GL1.3 specification, section 2.13.1, top of page 50. The sign of the result is used to determine if the triangle is backfacing or not.

-- Tom

Robbo
03-14-2002, 04:01 AM
Moreover, often the normals passed into OpenGL are lighting normals, which are per-vertex and usually averaged over facets sharing that vertex. Not the same as the plane normal for the facet.

wildeyedboyfromfreecloud
03-14-2002, 06:31 AM
yes, i figured that much. but i still through it up in the air hoping someone would provide a concise answer. well my textbook suggested back face culling via determining whether there was 90 degrees between the view normal and face normal. presumably if any vertex light normal is in that position then it is back facing. but i suppose calculating the angle between normals is relatively expensive. on the off note. i spun my triangle verticies around in every position i could imagine. actually i thought about it once then flipped them around about 5 times. which should've done it. still every other triangle is culled. i'm sure there is a good reason. but i gave up. maybe another day. thanks btw for the input

michael

Relic
03-15-2002, 12:44 AM
>>but i suppose calculating the angle between normals is relatively expensive<<

Not really, the facing information is just the sign of the dotproduct of the two vectors (which is cos(angle)).

Devulon
03-15-2002, 03:09 AM
I know where you guys are coming from. In many of my applications, depending on the lighting model, I will actually maintain a normal on both a per vertex and per face/triangle basis. The normal for the vertex is obviously for smoother lighting of poorly tesselated objects. The normal for the face/tri's are really just the plane equation. Which is useful for everything but lighting. Maintaining normals for both verts and faces seems like a waste but if you have a lot of objects calculating them every frame is definately gonna be a waste. Its just something I have come to expect that I have to do.

wildeyedboyfromfreecloud
03-15-2002, 09:25 AM
Originally posted by Relic:
>>but i suppose calculating the angle between normals is relatively expensive<<

Not really, the facing information is just the sign of the dotproduct of the two vectors (which is cos(angle)).

i know but thats not terribly free. thats probably why i said relatively. i guess i'm a stickler for keeping things sooper simple. my programs tend to work in mysterious ways if i can help it.

wildeyedboyfromfreecloud
03-15-2002, 09:27 AM
btw i got the gl backface culling to work. can't imagine why it didn't before. i'm bad about getting directions flipped i'm afraid.

wildeyedboyfromfreecloud
03-15-2002, 09:44 AM
heres another way to do it. by coincidense today i happened to need this functionality.
dot the difference of the eye point and any point on the face by the normal of that face. if that result is greate than zero it is a back face.

Bob
03-15-2002, 12:30 PM
Yepp, thats the way everybody did the backface culling in the old days.

Some might have used the view direction instead of the vector between the viewpoint and the vertex. It's less calculation (that is, faster), but less acurate. In some cases, triangles are culled even though they shouldn't, and vice versa.

wildeyedboyfromfreecloud
03-15-2002, 12:34 PM
yeah i went for the view vector. i've yet to notice any inaccuracies. would it not be faster than passing all the verts projecting them and getting the sign of their area???

zeckensack
03-15-2002, 01:00 PM
Are you doing that yourself? OpenGL can handle that and it will perform much better than anything you can come up with, regardless of normals. Just a simple glEnable(GL_CULL_FACE) and you're set.
That of course requires you to have consistent winding on all triangles but that shouldn't be too much of a problem.

As a rule of thumb, two triangles sharing an edge should run down the edge in opposite directions, eg
Vertices A,B,C,D, two triangles share edge (B-C)
Triangle 1: A,B,C
Triangle 2: D,C,B

The default setting is that counter-clockwise winding means front facing.

If your current geometry qualifies as all backfaces under this rule, either reverse your geometry winding or call glFrontFace(GL_CW) for clockwise front face winding.

wildeyedboyfromfreecloud
03-15-2002, 01:06 PM
well personally i am culling a triangular region that encloses a heightfield; but i think the mentioned technique would be faster than gl maybe. i mean by that time gl has done everything but fill the region. that would stop gl from even considering the face. gl isn't necesarrily fast. just easy. but personally i get bogged down with all the syntax. so if i can easilly avoid using gls extra stuff i usually do.

zeckensack
03-15-2002, 01:22 PM
If you're talking about some larger scale backface culling, ie not per triangle, just disregard my blabbering http://www.opengl.org/discussion_boards/ubb/smile.gif


Well, I don't think you'd lose any performance with gl's culling. The calculations going on behind the scenes are required for the triangle setup anyway.

Given a perspective correction, are you really convinced that you can do that faster than gl?

You need to
have face normals in addition to vertex normals (wasting storage) always keep a copy of gl's matrices transform the face normals yourself take care of perspective division dot product transformed face normal*forward vector

Gl will
shortcut the face normal with a simple cross product between transformed vertices dot product result*forward vector

Most of the stuff is happening somewhere down the line anyway, why not take opportunity of that?

[This message has been edited by zeckensack (edited 03-15-2002).]

[This message has been edited by zeckensack (edited 03-15-2002).]

wildeyedboyfromfreecloud
03-15-2002, 01:31 PM
Originally posted by zeckensack:
[B
You need to
have face normals in addition to vertex normals (wasting storage) always keep a copy of gl's matrices transform the face normals yourself take care of perspective division dot product transformed face normal*forward vector

B]


why wouldn't you have any of that stuff. unless you are just doing pictures with no physical interaction all of that stuff is required or unecesarry anyhow. there is no cure all solution. depends on the context. i'm just saying that i wouldn't bet that gl can out perform every backface culling algorithm in every situation. but what do i know.

besides i do all that stuff myself and give it to gl for drawing. thats all i use gl for.



[This message has been edited by wildeyedboyfromfreecloud (edited 03-15-2002).]

wildeyedboyfromfreecloud
03-15-2002, 02:52 PM
yeah basically i'm culling a coarser triangle on a subdivided surface where you can as well assume that if the larger triangle is not visible then all its children are not visible. so you can't really pass that down the gl pipeline