OpenGL ES Software Renderer / 2300 discussion

[Dan East]

[Kzinti]

[hm]

[Digby]

[hm]

[drgoldie]

well, what would be great is something like "per attribute indexed arrays".

standard opengl vertex arrays just allow one index for all attributes of a vertex (position, normal, texcoord, etc.). for a software renderer it would be great to supply different indices for each of these, so that coords can be shared even when normals and/or texcoords are not, etc.

anyway it makes sense to cache transformed vertices of vertex arrays such as mesa does...

Daniel

[Dan East]

[Digby]

[Dan East]

[Digby]

[hm]

[bluescrn]

I don't really see the point of OpenGL ES any more. I was expecting something cut-down enough to be implemented efficently in software. Amongst other things, this would include not relying on depth buffers...

As it is, it's fairly clearly *not* aimed at software implementations. So why not just use bog standard OpenGL, ? Or a 'MiniGL/QuakeGL' type implementation, as proved so successful on the PC?

I though fixed-point maths may be the main issue - but is it even an issue if it's aimed at hardware implementations that will almost inevitably get T+L (if not complete shaders support) in a couple of generations time.

And doesn't regular OpenGL support the likes of glVertex3i() anyway? and transformations could probably be implemented in fixed point internally?

[Dan East]

One of the primary differences of OpenGL ES is to force passing of data by array, thus doing away with the glBegin and glEnd paradigm (which I never liked anyway - why in the world would I want the overhead of a function call for every single vertex I want to pass?).

So OpenGL ES in a large way represents a lean and mean OpenGL that no longer has to be backwards compatible. In other words, a lot like what OpenGL would look like if it were done right in the first place without so many redundant layers.

I know I'm starting to sound like a broken record (because I've said this a couple times in the past). When it comes to hardware rendering, where all transformations and projections are done in hardware with high accuracy, including a texture matrix, there is no need at all for a fixed point type. You can simply use full blown integers, and scale the matrix to affect fixed point against the type. For example, if you are using 16.16 on the software side, then you can pass those verts as GL_INT, and scale the matrix by 1/(1<<16).

Of course all of that is completely out of the question for software rendering, especially when we talk about also using a texture matrix which allows the same technique with texture coords.

However OpenGL ES does have Fixed Point types, although they did not end up being used at all in MotoGP and ES Quake. We decided it was far more important to reduce the data size and go with shorts and use the above technique than to treat them as formal fixed point . So at this point I do feel that the Fixed Point types were included specifically for software renderers.

Dan East

[Digby]

[Dan East]

Vertex Buffer Objects allow you to copy the geometry to the VRAM once and reuse it, assuming your geometry is static.

Dan East