Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  glDrawElements or glInterleavedArrays  (Read 5656 times)
0 Members and 1 Guest are viewing this topic.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Posted 2003-03-06 05:11:03 »

So I've kinda come to a dilema in my coding. Does it make sense to use glInterleavedArrays which would greatly reduce the JNI overhead since it requires a single function call to actually draw stuff, or do I use glDrawElements or similar since I can lock them which should give me faster drawing speed.

What are you guys doing? What has been the experience of folks drawing large numbers of triangles?

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline elias

Senior Member





« Reply #1 - Posted 2003-03-06 08:21:22 »

Something is not right here, glInterleavedArrays is shorthand for a bunch of calls to glVertexPointer, glNormalPointer etc. That is,  glInterleavedArrays only _specify_ vertex arrays, but doesn't actually draw anything... glDrawElements on the other hand does the drawing from the arrays specified.

Now here's what I do: Use glInterleavedArrays because
1. The jni overhead is smaller - only one call to specify all my arrays (almost)
2. There's a (theoretical) speedup according to the red book when using interleaved instead of separate arrays.
3. I change position, normal and color at the same time, so it won't help me to have arrays stored separately.

To draw I use glMultiDrawElements, because it enables you to draw many separate lists of triangles in one call. (only available as standard GL from OpenGL 1.4 though)

- elias

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #2 - Posted 2003-03-06 14:12:13 »

Oh man I was very tired, sorry it was late  Grin

The question should have been about drawing using glDrawElements with GL.TRIANGLES or GL.TRIANGLE_STRIPS. Given the processing that might be required to compute triangle strips, is the overhead of 'essentially' multiple calls to the driver by drawing multiple triangles a lot worse that generating triangle strips and rendering those (some of the geometry is dynamic).

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline elias

Senior Member





« Reply #3 - Posted 2003-03-06 14:15:16 »

Don't know really - the overhead is offset alot using glDrawMultiArrays as I said. In our stripifier a threshold is defined so every strip shorter than, say, 10 triangles is put in a separate list of single triangles.

- elias

Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2003-03-06 17:22:30 »

There is no need to send triangle strips any more. Because of vertex cacheing there is no performance advantage to using strips, and a great deal of hassle instead of working them out instead of just chucking triangles at the card.

(And don't use interleavedarrays any more, it's kinda obsolete)

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #5 - Posted 2003-03-06 18:23:48 »

No interleaved arrays  Huh What would I use as opposed to that? You have piqued my interest 10 fold because that's how I've always transmitted data to the card  Cheesy

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline elias

Senior Member





« Reply #6 - Posted 2003-03-06 18:35:23 »

Simply specify the arrays separately, i.e.:

glVertexPointer(...);
glNormalPointer(...);
...

each having their own buffer (and address).

- elias

Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2003-03-06 19:59:44 »

It goes without saying that they have to overlap to look like interleaved arrays Smiley Having said that I'm not sure it has any effect at all on AGP transfers.

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #8 - Posted 2003-03-06 20:23:17 »

Actually I left that approach for glInterleavedArrays. Why would I want to specify each type separately? A lot of extra work for no gain whereas I get flexible vertex format for free using glInterleavedArrays.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-03-06 20:50:43 »

Because the more advanced rendering techniques require some pretty strange combinations of vertex data, and often a vertex doesn't fit nicely into 32 bytes and so you have to go to 64 etc. IOW, glInterleavedArrays suits a small number of basic rendering operations for single-pass techniques which is rapidly becoming completely obsolete.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #10 - Posted 2003-03-06 22:54:11 »

I haven't run across these rendering techniques yet. At the moment I'm doing things with fragment shaders and vertex shaders and haven't run across any need to use any specialized techniques that requiredd me to do something funky to pack vertices. Again, my interest is greatly piqued  Huh Where can I find more info about these techniques?

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2003-03-07 12:01:34 »

Well, look up "bump mapping" for one. The terrain demo used between 5-7 passes to render, and ISTR it had a 96-byte stride for its vertices, each pass requiring a different set of normals, texture coordinates, colours and secondary colours specified (but of course, with the same coordinates).

Even with shaders you're still going to have to use multitextuyre coordinates and that's not supported by interleaved arrays either.

I suspect once upon a time a software driver could have made some reasonable optimisations with interleaved arrays but now it's more of a hindrance than a help.

Cas Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #12 - Posted 2003-03-07 12:26:18 »

Hmph.  Does anyone know any sites which parts of OpenGL aren't worth bothering with and those that are A Good Thing? Huh

Trial and error goes some way to making things fast, but you can never guarantee that you're doing the best you can or that you haven't just hit a fast rendering path through your particular accelerator.  I recently discovered that setting the GL.TEXTURE_ENV_MODE to anything but GL.MODULATE on my S3 will cause the program to run like a slug in treacle.  Why?  No idea.  Couldn't find any info on the web about it either.  I would have thought GL.DECAL would be the fastest, but no.

Everything used to be about triangles.  Triangles triangles triangles.  Now Quads are acceptable, even recommended?  gl.color3fv isn't worth it, stick to gl.color3f?  A textured quad is better than a call to gl.bitmap?  Lighting is slow?  Next I'm expecting to hear to glPushMatrix() shouldn't be used anymore or something... Roll Eyes

Hellomynameis Charlie Dobbie.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #13 - Posted 2003-03-07 19:52:27 »

Quote

Well, look up "bump mapping" for one. The terrain demo used between 5-7 passes to render, and ISTR it had a 96-byte stride for its vertices, each pass requiring a different set of normals, texture coordinates, colours and secondary colours specified (but of course, with the same coordinates).


Interesting. I don't have 5-7 passes for my rendering - just 2 and each pass used the same set of normals, texture coordinares and colors. It may be that I have not run across a situation where using glInterleavedArrays was a disadvantage. In the Cg stuff I've done so far all of my in parameters ewere single sets of vertex or texture coords and the register combiners were used to generate any additional coordinates from the maps provided.

There isn't a lot of work in not using glInterleavedArrays - just gets around the JNI overhead.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2003-03-07 20:31:15 »

There's nowt wrong with interleavedarrays, it's just getting obsolete. Might not even be in OpenGL2.0, can't remember if it is or not.

Charlie - don't use quads, because the driver just turns them into triangles anyway. What's more you can multipass triangles on top of triangles without troubles but try drawing quads and then triangles on top and you'll get z-buffer problems. So better start off with triangles and then you've only got 1 kind of primitive to worry about. Use bytes for colours, not floats, to avoid a costly float->byte conversion on the client end. And avoid glPushMatrix() like the plague - use it only when necessary, to shove large pieces of geometry somewhere, like trees - not sprites - because it stalls the GPU pipelines and flushes the vertex caches. There you go.

Cas Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #15 - Posted 2003-03-08 12:45:33 »

Quote
Charlie - don't use quads, because the driver just turns them into triangles anyway.

I tend to use triangle fans as a matter of course (less undefined operations if your vertices aren't quite in-plane Wink).  But didn't you mention that quads fit nicely into current-generation vertex caches?  Maybe I imagined it...

Quote
Use bytes for colours, not floats, to avoid a costly float->byte conversion on the client end.

Hrm, okay, that makes sense.  I much prefer thinking in the range 0.0..1.0, but if I have to start thinking in 0..255 that's okay!

Quote
And avoid glPushMatrix() like the plague - use it only when necessary, to shove large pieces of geometry somewhere, like trees - not sprites - because it stalls the GPU pipelines and flushes the vertex caches.

GHA!  That was supposed to be a joke!  Angry Shocked

Fortunately my current project-of-the-minute (it's changed a lot recently  Grin) is single screen and 2D so I should be able to avoid them pretty easily.  Is manipulating the matrix stack really a no-no now?  I'm amazed!

Quote
There you go.

Cas Smiley


Much appreciated!  I really wish this kind of knowledge was published somewhere.  I know it depends very much on platform-dependent features, but there should be a Good Practice guide at least.


Cheers,
Charlie.

Hellomynameis Charlie Dobbie.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #16 - Posted 2003-03-09 03:58:31 »

Quote

There's nowt wrong with interleavedarrays, it's just getting obsolete. Might not even be in OpenGL2.0, can't remember if it is or not.


In the latest iteration of the specification it is there. It doesn't really matter how the vertices are staged - to the vertex or fragment program, the vertices or texture coordinates appear as a steady stream of data so whether or not you've interleaved your arrays or specified them seperately they will just appear in the in parameter to your shader. No biggie. I now have two vertex buffer types, one that handles interleaved data that I use for everything and another one that has it all seperated out for when I get to something that can't handle it. Currently I haven't had any issues with register combiners with interleaved arrays. My current bump mapping is now done in one pass using register combiners on GeForce4 caliber hardware.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2003-03-09 10:35:41 »

Ah, you lucky people with big fast video cards :/

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #18 - Posted 2003-03-09 19:45:14 »

Heh, if you will 'code for hardware' I'm sure I can arrange to get you a GeForce FX for a certain special piece of rendering code  Wink

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #19 - Posted 2003-03-10 17:47:01 »

Quote
Use bytes for colours, not floats, to avoid a costly float->byte conversion on the client end.


Sorry, just been wondering about this.

Doesn't the OpenGL pipeline usually use floats for colour values already?  Won't this just cause the conversion to be done in the driver?  Wouldn't using floats from the start avoid this?

If you're using bytes for colours, are you then only using values from 0 to 127 and passing them to OpenGL as (signed) GL.BYTEs, or doing something much more devious? Wink


I'm still trying to get my head around all these signed/unsigned conversions...  I accept now that it's better they're not in there, but it don't half give me a headache... Angry  After many years of programming complex software in Java, I'm finding I'm having to go back to the beginning and work out exactly how a cast works... Grin

Hellomynameis Charlie Dobbie.
Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #20 - Posted 2003-03-10 20:54:43 »

Okay, thinking logically it's a lot better to leave OpenGL to do byte-float conversions as necessary.  It knows what's best and will do it as fast as humanly (computerly?) possible anyway. Grin  Doesn't need me slowing it down.  Still not sure of the best way to store colour data in bytes though.  There must be a better solution than just using [0..127]?

I've done a lot more learning about signed/unsigned now, and am beginning to get the hang of it.  Whatever you want to do, the first thing you seem to have to do is promote everything to int anyway... why'd they even bother with byte? Roll Eyes Wink

Hellomynameis Charlie Dobbie.
Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2003-03-10 22:50:21 »

Because the hardware deals in values 0..255 internally the GL drivers are almost certainly sending them in the range 0..255 as well. It takes a quarter of the bandwidth as well which is a very significant saving.

I use 0..255 for my bytes eg: gl.color4ub((byte)255, (byte)255, (byte)255, (byte)255)

Cas Smiley

Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #22 - Posted 2003-03-11 00:34:43 »

I've had to leave mine as floats because dealing with colors as unsigned bytes appears to be unsupported in most of the shader languages going forward. Just about all of them define color as a float3 or float4. In fact the smallest datatype that they deal with in most drivers going forward with respect to any new features is a int (32 bit) or a half (16bit float).

Before anyone starts wondering what this has to do with OpenGL2.0 - glslang takes its input the same as Cg. In fact unless you're very API knowledgable, you could *easily* mistake the shader language in OpenGL2.0 for Cg.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (39 views)
2014-07-18 06:55:21

Zero Volt (36 views)
2014-07-17 23:47:54

danieldean (29 views)
2014-07-17 23:41:23

MustardPeter (32 views)
2014-07-16 23:30:00

Cero (47 views)
2014-07-16 00:42:17

Riven (48 views)
2014-07-14 18:02:53

OpenGLShaders (38 views)
2014-07-14 16:23:47

Riven (37 views)
2014-07-14 11:51:35

quew8 (33 views)
2014-07-13 13:57:52

SHC (70 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!