GL_FLOAT_PTR type for glVertexPointer

How about adding a GL_FlOAT_PTR to the glVertexpointer function. Currently to draw a cube properly (i.e. right normal per vertex) you need to specify an array of 72 floats, and thats just for the vertices. In a cube there will only be 6 unique floats. If we had a GL_FlOAT_PTR type for glVertexPointer we would be able to pass an array of float pointers instead of an array of floats. So for no matter how many cubes of different sizes you had to draw you would only need one array of 72 float pointers, and 6 floats. Each of the 72 float pointers holds the address of one of the six floats. To draw a cube you simply need to reaassign the six floats (x1,x2,y1,y2,z1,z2) and pass the pointer to the array of 72 float pointers to glVertexPointer. This logic works for normals, colors, and textures as well.

This can’t be that hard to add.

What would be the point? A pointer is the same size as a float on most current architectures, so your solution would take up slightly more memory than the original float array. And because you’re adding a layer of indirection it’s probably slower too. The increase in update speed wouldn’t make much difference except for dynamic geometry, and your proposal doesn’t really work for dynamic geometry anyway.

Slower. More bloated. Only works for (axis-aligned!) cubes and the like. Remind me again why this would be a good idea?

Side note: the inefficiency of vertex arrays for certain cube cases comes up over and over again in this forum. To be honest, I think it’s a red herring. Very few real-world applications spend much of their time drawing cubes or comparably simplistic geometry. For geometry on a serious scale the benefits of more complex data-reuse schemes are negligible to nil. (Or, as in this case, negative.)

[This message has been edited by MikeC (edited 07-25-2001).]

Sorry, but I have to disagree. Fundamental geometric primitives (cube,cylinder,sphere e.t.c) get drawn a lot. And remember not all of us use GL for writing games. I draw thousands of cubes and cylinders. All the buiness graphics people do as well. That adds up to a lot of GL programmers. Being able to rapidly assign a complex primitive with only a few variables makes sense, and saves processor time. It also saves masses amounts of memory.

As for the bloated function call and overhead - bollocks! Whether you reference a float through a pointer or from a dereferenced pointer to float is’nt going cause Mr. Pentium any fuss.

Anyway the benefits far outway any downside. Faster, cleaner, code which is more functional and definately re-usable. It must also be very easy to implement. There can be nothing wrong with a bit of choice.


I think that the use of an array of float pointers isn’t really a good generic solution (for example, the necessary data cannot be directly loaded/saved to a file, because pointers values are context dependant)

But, I think really that the proposition of Dirk (see the “glDrawElement with independant vertex, normal and texCoord indexes” thread on the same forum) is something that can easily resolve all this sort of problems.

In your case, the gl*Pointer functions can point to your array of floats, and the future “glDrawElementEXT” function that is discuted into the "“glDrawElement with independant vertex, normal and texCoord indexes” thread can easily handle your indirection by indexation (an index is very more generic that a context dependant pointer because you can directly load/save the index from/to a file, cf. it’s context independant).


Originally posted by vs:
Sorry, but I have to disagree.

Fair enough. If ya gotta disagree, ya gotta disagree.

Still not convinced though.

Current consumer architectures typically bottleneck on bus bandwidth, not CPU speed. If you have to transfer a float*, then the float itself, you’re potentially doubling your bandwidth requirement. Things are definitely moving in the direction of having GPUs pull large stretches of vertex data directly (e.g. from AGP), without any intervention from the CPU. This proposal - constantly switching backwards and forwards between the app and GL - is going in the opposite direction.

My main gripe, though, was that you seem to be sacrificing render performance for geometry update performance. This would be fine if you were talking about ROAM landscapes or skinned character animation, but for bunches of axis-aligned cubes it just doesn’t seem like such a good tradeoff.

Wanting a simpler solution is fine, but if that’s your only motivation - if you aren’t pushing performance or spangliness envelopes - a simple helper function would give you the same convenience and memory-saving benefits. Either by constructing vertex arrays on the stack, or just tweaking the modelview matrix and calling a dlist.

I just don’t see it happening. If you look at the ARB members, they’re mostly interested in gaming, CAD and vis-sim; from that perspective, this is an obscure corner case. Not to denigrate business gfx in any way, but most of the ARB are ultimately out to sell stuff, and people don’t buy geForce3 cards to display bar charts.

There can be nothing wrong with a bit of choice.

I’m not so sure. A huge amount on traffic on this board is already taken up with questions on the relative performance of different approaches, or dealing with odd combinations of features. Once you step outside the cosy you-know-it’s-going-to-be-optimized world of “what Quake does”, the existing GL feature set is already a minefield. Driver writers only have a finite amount of time; in many ways I’d prefer it if we could standardize on a few very general approaches. Adding special-case code paths all over the place just makes things worse.

Exactly how many cubes are you rendering and does it involve animation? How many FPS are you getting?

BTW, cubes don’t waste memory at all. All you need is one cube, then use glTranslate, glRotate and even glScale if you have to get the result you want. On a TnL hardware, it will be plenty fast.


This is clearly the case when ALLS cubes share the sames coordinates, colors, normals and texels coordinates and are only translated/moved/scaled.

But not when we want to update VERY FREQUENTLY each colors, coordinates, normals and texture coordinates on each vertex of each faces of each cube (because we have to reconstruct ENTIRELY the vertex array in this case).

With a TRUE indexation sheme, 3D data into the vertex arrays haven’t to be changed, only face’s indexation have to be updated.

This is certainly better that to systematicaly recreate a vertex array that is principaly composed with redondants copies of statics 3D datasets in this case


Good arguments, but not good enough. The only really good argument against float pointers is memory cost. I have 1 GiG of main memory on my PC. That means even if I have to draw 5000 cubes of various sizes and orientations and a 1000 cylinders I’m still only going to use an extra (4 * 5000 * 72) + (4 * 1000 * 120) = 2.0MB of memory. Peanuts, compared to different texture maps applied to every different face of each cube
( 25000 * 128k = 2.5 GB ). I am too used to constantly trying to conserve resources, I forget we have 1.8 GHZ processors with multiple gigs of memory. Suggestion retracted.

As for animation, yes I do. Via quaternions.


It is very, very unlikely that anyone will ever add any “deeper” indexing than what is provided today with OGL vertex arrays and DrawElements. That is, you’ll probably never see separate indices for different attributes. You’ll probably never see arrays of pointers. Etc.

The real-world performance gain possibilities are generally minimal, and the added API complexity is simply not worth it.

This is one of the most commonly-asked-for features, but in real apps, it turns out to be mostly useless.

  • Matt

<…2.0MB of memory. Peanuts, compared to different texture maps applied to every different face of each cube
( 25000 * 128k = 2.5 GB ).>

One small thing, sending a 2MB texture to OpenGL is much faster then sending 2MB geometry data.