Revised glDrawRangeElements() question.

[zahl2001]

Thanks to others advice, I now have my program up and running.  The code excerpts below show (hopefully) the key parts of what I am currently doing, but now I am interested to see if someone can show me a more EFFICIENT way to do the same task.  I read something from Cas talking about the pointers to the vertex arrays working at top efficiency when they have a stride of 32 bytes, but I never got that off the ground.  

So...anyone is welcome to give me some code, OR, to tell me that they think the way I'm doing this is acceptable.

You'll notice I only have vertex data and color data, and this is due to the fact that I am only a beginner, so if someone wants to offer a solution that uses vertex, texture, and normal data that would be great.

This program draws a 3 sided pyramid with no bottom.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51   52   53   54   55   56   57   58   59   60   61

// "global" arrays float[] vertexArray = {0, 0,  1,                        1, 0, -1,                       -1, 0, -1,                        0, 1,  0}; float[] colorArray = {0, 0, 1,                       0, 0, 1,                       0, 0, 1,                       1, 0, 0}; int[] geometryArray = {3, 0, 1,                        3, 2, 0,                        3, 1, 2}; FloatBuffer vertexBuffer; FloatBuffer colorBuffer; //------------------------------------------- public void init (...) {     //...     gl.glEnableClientState(GL.GL_VERTEX_ARRAY);     gl.glEnableClientState(GL.GL_COLOR_ARRAY);     ByteBuffer buffer =         ByteBuffer.allocateDirect( vertexArray.length * 4) ;     buffer = buffer.order(ByteOrder.nativeOrder());     vertexBuffer = buffer.asFloatBuffer();     buffer =         ByteBuffer.allocateDirect( colorArray.length * 4) ;     buffer = buffer.order(ByteOrder.nativeOrder());     colorBuffer = buffer.asFloatBuffer();     vertexBuffer.put(vertexArray);     colorBuffer.put(colorArray);     vertexBuffer.position(0);     gl.glVertexPointer(3, GL.GL_FLOAT, 0, vertexBuffer);     colorBuffer.position(0);     gl.glColorPointer(3, GL.GL_FLOAT, 0, colorBuffer);   //------------------------------------------- public void display(...) {     //...    gl.glDrawRangeElements(GL.GL_TRIANGLES,                           0,                           3,                           9,                           GL.GL_UNSIGNED_INT,                           geometryArray);

Thanks much for the help on this and everything else folks...if not for input from Cas and others I would never have gotten even THIS little program off the ground!

[HamsterofDeath]

i'm currently working on an allrounder-class for vertex arrays, vertex buffer objects and whatever there is.

so far, it's able to use vertex data, normals, colors, vertex fog, and up to 4 textures, convert it into a static vbo, strip triangles, build an indexed array, and draw everything by using the good old gl*-commands.
it's still a bit buggy, but the vbos are working already.

if someone could explain the difference between vars and vbos (and show me how to use them), i'd maybe implement a vertexarray -> vertex array range conversion.

the only difference i see so far is that i allocate the vbos via glBindBuffer and genBuffer, while zahl2001 is using bytebuffers (where are they stored ? vbos are stored in the grapic cards ram, which makes them faster. does the bytebuffer something similar ?)

i'll post the source somewhere when it's done.

[tom]

vbos are more efficient than vars. There is a vbo whitepaper on nvidia: http://www.nvidia.com/object/using_VBOs.html

Storing the data in a bytebuffer just means it is on the native side of java. I guess it has to be that way because glVertexPointer creates a real point to the data. And it can't point into the java heap.

Games published by our own members! Check 'em out!

[HamsterofDeath]

with gl4java, you can use java float arrays...
but i think you're right.

btw i just implemented a gl***-renderer for my vertexarray (to make a conversion into a displaylist possible):
the difference between optimized vbos and unoptimized gl-calls + getting vertex data out of floatbuffers per get() is extremely high.

i didn't measure it excactly, but i'd say vbo's are about 5-6 times faster

[tom]

What did you compare against? Did you use glVertex3f(), glTexCoord2f() etc, or vertex arrays? Would be interesting to compare it against display lists.

[HamsterofDeath]

glvertex, glNormal, gl(multi)Texcoord(arb)
i'll run some benchmarks soon

[zahl2001]

Are the VBOs specific to any one type of card?  Or will they work with any modern card?

[tom]

It's an ARB extension and is not vendor specific. Although I would think new cards will have the extension, you should check for it and provide a fallback.

[jeickmann]

This page usually helps, if you want to know about extension support in different graphics-cards:

http://www.delphi3d.net/hardware/index.php

Here's the page for the VBO's:
http://www.delphi3d.net/hardware/extsupport.php?extension=GL_ARB_vertex_buffer_object

[quintesse]

@HamsterOfDeath: how's the "all-rounder class" coming along? Writing one myself so I'm mighty interested in comparing it to yours (yours seems to support a lot more functionality so I might prefer using that one over mine anyway)

Games published by our own members! Check 'em out!

[elias]

Tom: There's no reason all cards couldn't support VBO, so it's more a question of how recent your drivers are. VBOs work fine on plain old geforce 1, and probably all back to the tnts (but I don't have one of those).

- elias

[tom]

Yes. I found that out after checking out the excellent delphi3d.net link. According to it the TNT support vbos with new drivers, but a radeon 9500/9700 with old drivers do not have it.