PDA

View Full Version : What happened to...



CarstenT
09-25-2015, 12:35 AM
Hi all,
I've spent wasted time on getting glLineWidth to work on a core profile.
I think that I was fooled by GL_TRIANGLE vs. GL_TRIANGLES too,
but I'm passed that.

glDrawElements(..) is another case.
It's an obvious function to use in many situations,
and "The OpenGL Programming Guide for opengl 3.0 & 3.1" (ver. 7)
describes how to use it. I've not found any hints that it should be deprecated.
It will not work on my pc, so I looked through the opengl-extensions viewer
and found no mentioning of it. ..
That gives sense to all my vane attemts, but how can it not be present
and yet not throw a glError? And why is it not present? My driver is ver 3.3.

cheers

>more squabble<
I've got the "OpenGL SuperBible" 5.th.
It includes the OpenGL Man Pages for (core) OpenGL 3.3
The glDrawElements() family of functions has what looks like
a disclaimer. I don't understand.
quote
Vertex attributes that are modified by glDrawElements have an
unspecified value after glDrawElements returns. Attributes that
aren't modified maintain their values.
unquote
??? My thinking goes along the lines of:
I modify something by say writing to a buffer. That's not
my impression of what I do when I Draw.
What does this 'disclaimer' mean?

mhagain
09-25-2015, 04:14 AM
glDrawElements won't show up in the extensions viewer because it's not an extension; it's part of core OpenGL 1.1, has never been deprecated, and if something isn't working with it on your PC, then the most likely explanation is that you're doing something wrong yourself.

The disclaimer refers to interaction between vertex array/VBO drawing and the old immediate mode (glBegin/glEnd). With immediate mode if you call, for example, glColor, then the "current color" is modified; subsequently calling glVertex will send the current color to the GPU for drawing (simplified explanation). What this interaction means is that if you use a color array with glDrawElements (or glDrawArrays) then the current color becomes undefined: you can no longer rely on it having either it's default value or the value set by the last glColor call.

It only applies if you're mixing vertex array/VBO drawing with immediate mode. If you're not mixing theswe drawing types you can ignore it.

GClements
09-25-2015, 04:27 AM
glDrawElements(..) is another case.
It's an obvious function to use in many situations,
and "The OpenGL Programming Guide for opengl 3.0 & 3.1" (ver. 7)
describes how to use it. I've not found any hints that it should be deprecated.

glDrawElements() still exists in OpenGL 3+ core profile.

You can easily tell which functions aren't deprecated by looking at the reference pages for OpenGL 3 (http://www.opengl.org/sdk/docs/man3/) or OpenGL 4 (http://www.opengl.org/sdk/docs/man4/). Those pages list only the functions which exist in the core profile.



It will not work on my pc, so I looked through the opengl-extensions viewer
and found no mentioning of it. ..
That gives sense to all my vane attemts, but how can it not be present
and yet not throw a glError? And why is it not present? My driver is ver 3.3.

glDrawElements() is part of the core OpenGL 1.1 specification. It isn't part of any extension, so it won't show up in an extension viewer.

If it doesn't work, it's because you're doing something wrong. glDrawElements() is the most fundamental rendering command which OpenGL has. If it didn't work, almost nothing would work, as that's what most OpenGL-based software uses for drawing.



The glDrawElements() family of functions has what looks like
a disclaimer. I don't understand.
quote
Vertex attributes that are modified by glDrawElements have an
unspecified value after glDrawElements returns. Attributes that
aren't modified maintain their values.
unquote

Vertex attributes other than the position have a current value.

When using the legacy glBegin() and glEnd() mechanism, vertices are generated by setting the current value of each attribute using glColor(), glTexCoord(), glNormal(), glVertexAttrib(), etc, then calling glVertex() to generate a vertex whose position is given by the arguments to glVertex() and whose other attributes are given by the current value of each attribute.

When using vertex arrays (glDrawArrays(), glDrawElements(), etc), for each attribute which is set from an enabled attribute array (glEnableClientState(), glEnableVertexAttribArray()), the current value of that attribute is in an unspecified state after the draw call. It may be left unchanged, it may be set to the value used for the last vertex generated, it may be set to the value for some other vertex, or it may be something else.

So after executing the code


glVertexAttrib1f(1, 1.0f);
glVertexAttrib1f(2, 2.0f);
glEnableVertexAttribArray(1);
glDisableVertexAttribArray(2);
glDrawArrays(...);

vertex attribute 1 will have an undefined value, while attribute 2 will still have the value 2.0f.

CarstenT
09-25-2015, 08:14 AM
If any of you know a good site with example-code of this function, please put it forward. Both books mentioned are scant about complete code with these functions. I'm having drawRangeElementsBaseVertex() and drawElementsBaseVertex() working in other situations. I've never managed to get DrawElements() itself Work .. in spite of persistent trying.
I'm making a dynamic write to the ELEMENT_ARRAY_BUFFER before the draw-calls .. it would be a place to fail. Reading the buffer shows that indices are where anticipated. I'm making other draw-calls in the same program, using the same position-attributes, and there is nothing out of the ordinary, they Work. The indices are for fans, subdivided from a more complex polygon. I can see the polygon-contour, count the points on the screen and see the indices-arrays on the console. There is not any doubt, that the indices are correct .. but they draw only a few split or overlapping triangles on the polygon.
Unfortunately my public library has turned their pc's in to just client screens, I cannot pop code (without..writing it myself;/) or images.

I appreciate your explanations

Alfonse Reinheart
09-25-2015, 08:20 AM
If any of you know a good site with example-code of this function, please put it forward. Both books mentioned are scant about complete code with these functions. I'm having drawRangeElementsBaseVertex() and drawElementsBaseVertex() working in other situations.

... glDrawElements is exactly equivalent to calling glDrawElementsBaseVertex with 0 as the base vertex. So write some code that works with glDrawElementsBaseVertex with a base vertex of 0. Then change the function to be glDrawElements.

CarstenT
09-25-2015, 01:00 PM
Reinheart, I did try.

I've just hurried out of the door to write you about my conserns about the Man Pages of bible 5 -- and I grabbed the wrong book. So' I'll try to memorize. I've been testing glDrawRangeElements(), and the Man Pages writes, that "start, end and count" is just like glDrawElements(). Problem is that glDrawElements() only has 'count', no 'start' or 'end'. Further it expresses something like "..drawing 'count' consecutive primitives..". That cannot be true unless he specificly talks about points - I'm drawing a fan (a geometric primitive) and using 'count' elements. And more: under glDrawElements() is written some confusing stuff about elements and arrays .. mixing thoroughly attribute-arrays and (the one and only) index-array without specifing what is what.
It's on this background that my ordeal with glDrawElements() rests. It's meaning is straight-forward.
On my recent tests, it looks as if the 'pointer' to indices (glVoid*) is failing. I use it like:
GLuint var; // put to some value. Then I use this as the pointer-argument:
,(glVoid*) + var,
It points to the wrong indices ..
When I read the indices-buffer, there is no doubt about the proper order of the indices.
Should I consider it 'something' that counts in mashine-units? .. naa, but I'll try.
The only thing that the glDrawRangeElements() call respects is the 'count' value.
The indices that are drawn on the screen belongs to a part of the array that lies earlier than what I (think) that I point to ..
Library closes ..have to go

cheers

Alfonse Reinheart
09-25-2015, 01:57 PM
I've been testing glDrawRangeElements(), and the Man Pages writes, that "start, end and count" is just like glDrawElements(). Problem is that glDrawElements() only has 'count', no 'start' or 'end'. Further it expresses something like "..drawing 'count' consecutive primitives..".

... I was going to tell you that you shouldn't rely on documentation you find in a book, since it can be wrong and can't be corrected. That for reference docs, it's better to look online.

So I did. And even the most up-to-date version says the same thing (https://www.opengl.org/sdk/docs/man/html/glDrawRangeElements.xhtml). :doh:

Bug filed (https://www.khronos.org/bugzilla/show_bug.cgi?id=1392). Let's see how long it takes to get fixed.

Of course, it was fixed 4 years ago on the OpenGL wiki (https://www.opengl.org/wiki/GLAPI/glDrawRangeElements) ;)

In fact, if you want to understand how vertex specification (https://www.opengl.org/wiki/Vertex_Specification) and vertex rendering (https://www.opengl.org/wiki/Vertex_Rendering) work, you should use the Wiki. Or, if that's unavailable, stop looking at the "man pages" part of the Superbible and start looking at the rest of it. It's job is to teach you how these things work.

Trying to understand OpenGL purely from reference documentation wouldn't be viable even if the reference documentation were properly comprehensive.

GClements
09-25-2015, 04:54 PM
I've been testing glDrawRangeElements(), and the Man Pages writes, that "start, end and count" is just like glDrawElements(). Problem is that glDrawElements() only has 'count', no 'start' or 'end'.

glDrawElements() is equivalent to glDrawRangeElements() with start equal to zero and end equal to 232-1.



Further it expresses something like "..drawing 'count' consecutive primitives..". That cannot be true unless he specificly talks about points - I'm drawing a fan (a geometric primitive) and using 'count' elements.

The count/i] parameter is the number of indices used. The number of points, lines, triangles or quads follows from this. E.g. for a triangle strip or triangle fan, the number of triangles is [i]count-2; for discrete triangles, the number is count/3.



On my recent tests, it looks as if the 'pointer' to indices (glVoid*) is failing. I use it like:
GLuint var; // put to some value. Then I use this as the pointer-argument:
,(glVoid*) + var,
It points to the wrong indices ..

If a buffer is currently bound to GL_ELEMENT_ARRAY_BUFFER, the indices parameter should be the offset (in bytes) into the buffer, cast to GLvoid*. If no buffer is bound, it should be a pointer to the indices in client memory.

CarstenT
09-26-2015, 03:38 AM
hi Again,
Reinheart, I'll try to remember the OpenGL wiki, thanks. I use the docs for quick references, and as a last line of defense. As mentioned, the functions are fairly easy to 'comprehend'.
Clements gets to the point: I ought to have realized, that the index-pointer was counting in bytes and not GLuints. On suspicion, I went home and tested the idea and .. Bulls-eye, right on target!

Thank you all for standing by.