I use the following code to enable normals to be used in a vertex shader.

    glEnableVertexAttribArrayARB(2);
    glVertexAttribPointerARB(2, 3, GL_FLOAT3, GL_FALSE, stride, (char*)0 + 
normalOffset);

This approach works correctly when running WGL (app running on MS Windows) 
and
GLX (app running on Fedora Linux).  However, it does not work correctly when 
running
AGL on Macintosh, whether a PowerPC or Intel Mac (with NVIDIA graphics 
cards).  Instead,
I have to use the following on the Mac

    glEnableClientState(GL_NORMAL_ARRAY);
    glNormalPointer(GL_FLOAT, stride, (char*)0 + normalOffset);

To my knowledge, glNormalPointer treats the input as 3-tuples, so it appears 
that if I have
a shader for which I want to provide 4-tuple normals, I am out of luck.

The question is why the generic vertex attribute approach does not work on 
Mac.  What
am I missing regarding my (limited) understanding of the OpenGL 2 approach? 
Thanks
for any help.

--
Dave Eberly
http://www.geometrictools.com
 

Dave Eberly wrote:

> To my knowledge, glNormalPointer treats the input as 3-tuples, so it
> appears that if I have a shader for which I want to provide 4-tuple
> normals, I am out of luck.

Indeed.
 
> The question is why the generic vertex attribute approach does not work on
> Mac.  What am I missing regarding my (limited) understanding of the OpenGL
> 2 approach?

> Thanks for any help.

I've no idea, too. Looks like a driver bug to me. Could you distill a 
working example program and publish the source? I got a Mac with Intel 
graphics, on which I could do a comparative test.


Wolfgang
-- 
OpenGL tip #42:
How to exactly map texture texels to screen pixels: 
<http://preview.tinyurl.com/cgndc8>

"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message 
news:hiv0h9$3u4$1@news.eternal-september.org...
> I've no idea, too. Looks like a driver bug to me. Could you distill a
> working example program and publish the source? I got a Mac with Intel
> graphics, on which I could do a comparative test.

Wolfgang, thank you for offering to look at this.

http://www.geometrictools.com/Temp/NormalsProblem.zip

The zip file expands to a folder NormalsProblem.  The folder contains a 
Microsoft Visual Studio 2008 project file, the test program 
(NormalsProblem.cpp), a few h/cpp files prefixed with Wm5 that are my OpenGL 
extension wrapper (you can remove and use any other), glut.h and 
glut32.{lib,dll}, Shaders.cg (a simple shader that has inputs of position 
and normal), vshader.txt and pshader.txt (the Cg-compiled output).  The 
project is self-contained.  You should be able to compile and run this on a 
Windows PC.

There is a subdirectory, NormalsProblem.xcodeproj, and a file in it called 
project.pbxproj.  Copy this to your Macintosh, after which you can open it 
using Xcode.  This project is also self-contained and uses the OpenGL and 
GLUT frameworks on the Mac.

I have a #define In NormalsProblem.cpp called USE_GENERIC_ATTRIBUTES.  It is 
enabled by default.  The vertex shader uses the input normal as the output 
vertex color.  On the PC, the displayed triangle has 3 vertices with 
different colors.  This is true regardless of the enabled/disabled status of 
USE_GENERIC_ATTRIBUTES.  On the Macintosh, the displayed triangle is BLUE. 
In my other applications where I noticed the failure, the normals input 
appears not to be enabled and the graphics system appears to default to 
(0,0,1) as the normal value (which is why the triangle is blue).  If you 
disable the #define of USE_GENERIC_ATTRIBUTES, the triangle is correctly 
displayed.

The problem occurs on a PowerPC Mac with an NVIDIA 6600 (driver 
NVIDIA-1.5.48) and on an Intel Mac with an NVIDIA 9400 (driver 
NVIDIA-1.6.6).

--
Dave Eberly
http://www.geometrictools.com
 

Dave Eberly wrote:

> The problem occurs on a PowerPC Mac with an NVIDIA 6600 (driver
> NVIDIA-1.5.48) and on an Intel Mac with an NVIDIA 9400 (driver
> NVIDIA-1.6.6).

I can confirm your results. And, probably unfortunately for you, this is 
perfectly within the specs (which I wasn't aware of until now):

http://www.opengl.org/registry/specs/ARB/vertex_program.txt - Section 2.7
"(...) Implementations may, but do not necessarily, use the same storage
    for the current values of generic and certain conventional vertex
    attributes. When any generic vertex attribute other than zero is
    specified, the current values for the corresponding conventional
    attribute in Table X.1 become undefined.  Additionally, when a
    conventional vertex attribute is specified, the current values for the
    corresponding generic vertex attribute in Table X.1 become undefined. 
    For example, setting the current normal will leave generic vertex
    attribute 2 undefined, and vice versa. (...)"

BTW: vertex/fragment_program are still ARB extensions, they never made it 
into an official OpenGL core spec.

If you change line 63
-    "MOV result.color.xyz, vertex.normal;\n"
+    "MOV result.color.xyz, vertex.attrib[2];\n"
then using generic attributes work, but no longer glNormalPointer.

See my changed version:
http://dl.wolfgang-draxinger.net/tmp/NormalsProblem.cpp

-- 
OpenGL tip #42:
How to exactly map texture texels to screen pixels: 
<http://preview.tinyurl.com/cgndc8>

"Wolfgang Draxinger" <wdraxinger@darkstargames.de> wrote in message 
news:hj7g35$hul$1@news.eternal-september.org...
> I can confirm your results. And, probably unfortunately for you, this is
> perfectly within the specs (which I wasn't aware of until now):
<snip>

I do not know the inner workings of OpenGL enough to understand why the 
specifications say what they do.  Manually modifying the program strings is 
clearly not my first choice.  I have a tool that takes a Cg *.fx file, 
compiles it for various profiles, and bundles the results into a binary file 
that my engine loads.  This binary file may be used whether OpenGL or 
DirectX.  The Cg compiler does not know whether I will use conventional 
attributes or generic attributes.  The fact that it compiles to 
"vertex.normal" appears to force me to use glNormalPointer, but then I 
cannot pass 4-tuples to the vertex shader.  How does GLSL deal with this 
issue?

> BTW: vertex/fragment_program are still ARB extensions, they never made it
> into an official OpenGL core spec.

Given that (1) I am using Cg (not GLSL), (2) I want to pass 4-tuples for 
standard attributes, and (3) I am using this ARB extension, the only 
solutions appear to be find a way to get Cg to compile to 
"vertex.attrib[num]" *or* modify my tool to make the appropriate changes to 
the program strings.

I really want (1) and (2), but I am willing to look at alternatives for (3) 
and that avoid the problems of my current approach.  What are my choices (if 
any)?

Thanks for your help and for looking at the sample program.

--
Dave Eberly
http://www.geometrictools.com