gemvertexbuffer : glGetActiveAttrib

[jptrkz]

This is a continuation of this unresolved, old thread:
#72
I am unable to get gemvertexbuffer working on a later OSX. I have two laptops: an old 32-bit laptop with OSX10.6 that gemvertexbuffer was originally modded on, and a new laptop, 64-bit, with OSX10.11.

I have identical Pd-Vanilla, Gem, frag/vert files, example-patch running with each, so I started looking at line 538...

void gemvertexbuffer :: attribute(t_symbol*s, int argc, t_atom *argv)

... to see where 10.11 deviates.

At line 583, glGetAttribLocation returns a different ordering of locations with 10.11, but they still fall within slots 1-5, so I don't think there is an issue here. "1-5" comes from the 5 attributes in the help-example using brick.frag/brick.vert:

attribute vec3 LightPosition; 
attribute vec3 BrickColor, MortarColor;
attribute vec2 BrickSize, BrickPct;

At line 594, glGetActiveAttrib returns incorrect glEnums for the switch/case.
Here is the print_attributes output of 10.11. Bold shows correct output on OSX10.6

[gemvertexbuffer]: GLSL-ProgramID: 3
[gemvertexbuffer]: Attribute1: LightPosition
[gemvertexbuffer]: size: 48
[gemvertexbuffer]: dimen: 2 (dimen: 3)
[gemvertexbuffer]: program_index: 1
[gemvertexbuffer]: Attribute2: BrickColor
[gemvertexbuffer]: size: 48
[gemvertexbuffer]: dimen: 3
[gemvertexbuffer]: program_index: 4
[gemvertexbuffer]: Attribute3: MortarColor
[gemvertexbuffer]: size: 48
[gemvertexbuffer]: dimen: 3
[gemvertexbuffer]: program_index: 3
[gemvertexbuffer]: Attribute4: BrickSize
[gemvertexbuffer]: size: 32
[gemvertexbuffer]: dimen: 4 (dimen: 2)
[gemvertexbuffer]: program_index: 2
[gemvertexbuffer]: Attribute5: BrickPct
[gemvertexbuffer]: size: 32
[gemvertexbuffer]: dimen: 3 (dimen: 2)
[gemvertexbuffer]: program_index: 5

If I edit the attribute function with correct, predefined vbo_dimens (confirmed with print_attributes), the output is still 4 black squares on 10.11.

The added attribute code is very basic so I have no idea why it would work on the older computer only.

files.zip

[jptrkz]

Hi,
No issues with this simple color-changing shader program. The original problem was likely with the original Brick shader code, which also fails to work in a pure openGL program.
All of the source arrays in pd need the extra "0" at the start, though you likely know this.

Here is a new example patch w/ colortest.vert & colortest.frag.
gemvertexbuffer.zip

[umlaeute]

so does that mean that the problem was actually resolved?
i'm closing the ticket for now, please raise your voice if this is pre-mature (so we can open it again)

[jptrkz]

Yes. I remember not being able to find official documentation to confirm this, but the reserved GL_NORMAL_ARRAY seemed to have become obsolete at some point. Normals had to be defined as another attribute in the shader files. glEnableClientState(GL_NORMAL_ARRAY) glEnableClientState(GL_NORMAL_ARRAY)

…

On Wed, Dec 19, 2018 at 10:45 AM umläute ***@***.***> wrote: so does that mean that the problem was actually resolved? i'm closing the ticket for now, please raise your voice if this is pre-mature (so we can open it again) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIP5SaflLyvcyS7Xnq2EcFDiZhEaaWgSks5u6l8pgaJpZM4IqjrB> . On Wed, Dec 19, 2018 at 10:45 AM umläute ***@***.***> wrote: so does that mean that the problem was actually resolved? i'm closing the ticket for now, please raise your voice if this is pre-mature (so we can open it again) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#113 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIP5SaflLyvcyS7Xnq2EcFDiZhEaaWgSks5u6l8pgaJpZM4IqjrB> .