Batching Verts?

[Baker]

I know the basics of vertex arrays ... but I've never done anything complex with them aside from throwing all the verts in a model frame into one and rendering it without multitexture.

1. The mechanics of the batching verts (and using texcoord array)
--- I need to allocate a buffer to store the triangles. Each entry is a float x 3 (verts) float x 4 (texcoords: texture s0, t0, s1, t1) and maybe a GLuint for the texture slot?
--- Do I allocate the memory in chunks I assume for best performance?
--- I fill the buffer with verts that use the same GL capabilities (i.e. same glBlend settings)
--- How does multi-texture fit into this? For instance, lightmaps or fullbright textures using a different TMU.
--- I should submit the verts when new settings kick in. If I need to change any rendering option, I need to submit the verts first as I understand it.

How do I handle vertex lighting, say for a player model? The traditional code changes the glColor for each vertex.

Is there even a way to do per vertex glColor in Open GL 1.x through an array?

2. Let's say I want to batch up the verts for a .bsp
--- Ideally, I would do this per vis leaf --- except that isn't practical because there can be incredible numbers of vis leafs.
--- I sure don't want to render the whole thing.
--- is there any intelligent way to handle the .bsp or does that have to be created on the fly any time the vis frame changes.

3. Models
--- The model verts are different per frame. Does each frame effectively need a vertex array?
--- For interpolating, is there a method to combine the middle of 2 frames or do I need to manually calculate the verts?

Many questions, I'm trying to develop an implementation plan ...

[Spike]

ditch gl 1.x
forget about it. it doesn't exist. its not worth using.
if it doesn't exist in gles2+ then you do NOT want to use it.
and if you're using it anyway, at least understand it in terms of gles2.

glVertexPointer(...)
glColorPointer(...)
glClientActiveTextureARB(GL_TEXTURE0_ARB)
glTexCoordPointer(...)
glClientActiveTextureARB(GL_TEXTURE1_ARB)
glTexCoordPointer(...)
glDrawRangeElements(...)

you need to use glEnableClientState to tell the drivers which arrays you have active otherwise it won't read from them.
you'll need to use glActiveTexture combined with glEnable and glBindTexture to actually use multiple textures. the above just shows how to specify the vertex attributes.

For best performance, you should try to ensure that your attributes are interleaved, supposedly not doing so is only a 5% performance hit, but really it depends how many verts you have. It helps the GPU cache.
Verticies are normally recommended to have 16-byte alignment or so.

Use VBOs so that you can avoid having to resubmit the exact same data to the hardware every single glDrawRangeElements call. Doing so normamly avoids any performance penalty from glDrawElements.
Use VAOs so that you can avoid having to call all your glVertexAttribPointer functions for every single draw call.

For vertex lighting on a player model, you build your static VBO with the vertex normals. You then set the lighting direction as a uniform in your vertex shader, and calculate the lighting there. This means that your C code can just specify the glsl to use and the raw attribute data, and your vertex shader can do the interpolation and lighting for you. Having the CPU loop through every single vertex for every single model for every single frame is a massive waste of CPU time when the GPU is much faster at doing it, and will be looping through them anyway. And there's no need to spam the cpu->gpu bus with attributes either because your VBOs are static.
As I said, ditch gl1.x - forget fixed function.

[Baker]

[Spike]

the stride should be the same for each attribute assuming they're interleaved in the same array.

[Baker]

I have interleaved working in a test. Thanks for the advice. Didn't even know it existed.

[ericw]

[Baker]

[mh]

[mh]

[revelator]

Sorry to drop in, at the darkmod forums we are pondering if it would be feasable to do batch processing in Doom3 ?
and since this seems related (vanilla still uses the same opengl 1.1 vertex array calls) i thought
i could maybe learn a few things about this, atm darkmod is hammering hard on the limits and suffers from considerable fps loss because its not optimized for todays gfx cards and uses cpu a lot.

[mh]

[revelator]

ack such a nice fix and then you cannot do it with ASM :S thats really unfortunate as we pretty much cracked the problem with accessing the depthbuffer and have a working implementation,
but atm its for ARB ASM shaders so it seems we have to go the GLSL way then if i understand correctly ?. Damn this means we are pretty much stuck with the option of porting darkmod to the BFG source or
rewrite vanilla completely to use GLSL. If you have other ideas for optimizing vanilla we are all ears.

[revelator]

Seems the darkmod devs disagree that vanilla would not benefit from batching,
atleast not there source which still uses code from before the source got free and could use some love .
id say it could be worth it just for updating the source for more modern opengl features to use vertex attribs and at a time i had pretty much replaced
the old opengl 1.1 vertex arrays with vertex attribs. Unfortunatly this feature was from that infamous engine o mine that broke on AMD cards and im a bit scared to
move it to my new codebase in case this was what broke it, so this time ill be sure to have a backup in case things go south.

[nbohr1more]

@ mh

Yeah, I think we're speaking on different terms here because the brush geometry in Doom 3 is poorly batched unless
done by the mapper (proper func_static setups, etc ) We've got game code that automates some of that process but
it could be made more efficient by tighter integration into the renderer. That said, I saw that you were thinking
about "Transform Feedback" for your VBO implementation and I guess that may be a good general way to solve
a few of these "instancing" type scenarios other than just giving up the ghost and using hardware instancing with GLSL.

One thing I was hoping you might shed light on as a general notion:

How close would you say is Doom 3's "Interaction Table to VBO" setup to a Forward+ renderer's "Light Index to G-Buffer".
I get the impression that BFG performs on par to a Forward+ renderer with regard to light count so perhaps we've already
got an analogous system (Tr3b at least claims his Forward+ vanilla Doom 3 version had the same performance profile as BFG).

Is it worth considering or feasible to change this part of the renderer?

[rec]

Hello to all,

I was wondering what is the difference between q3 and q1 bsp format, in terms of storing face vertices?
I made a very simple q3 bsp viewer in OpenGL 3.3, currently supports faces and textures.
I store each face in a separate VBO, and i have one huge index array for all the faces.
My intention is to continue as q1 bsp viewer, in the sources I saw that q1 bsp format stores edges instead of vertices, so im little bit confused.
Also, you cant have more than one texture per VBO, I was planning to separate the VBO by texture, but then you cant use vis culling.