Re: 10.2

[Dair G. <da...@re...>]

James W. Walker wrote:

>Would your idea work with the Apple OpenGL software renderer?  It's=20
>still OpenGL 1.1, but supports a bunch of extensions.

Vertex shaders will be processed on the CPU with any renderer from 10.2
upwards - so even an HW accelerated card that doesn't support HW vertex
shaders will be able to use them.

They're not present in any form on older systems though, so we will need
to make this optional (which is fine, was thinking it through last night
and I think that route is probably best anyway as there are a couple of
different languages for specifying vertex shaders - so we should keep
things as generic as possible at the Quesa level).

The main idea is threefold:

1. There's some kind of buffer object that can hold structured data, and
provide lock/unlock access to it.

This lets you put geometry data (vertices and indices) onto the card,
since the app has to let the card know when it wants to read/write the
data.


2. There's some kind of primitive geometry that takes a description of
the thing you're rendering (points, lines, triangles, tristrip, fans,
etc) and where to find the data for that object.

This lets us host the TriMesh on top of this, and means renderers only
need to support one geometry to be able to support anything (as point
and line support can then be optional).


3. There's some processing of the vertices before they reach the
rasterisation point.

Today this is done for us by OpenGL by pushing the vertices through the
GL lighting pipeline. Vertex shaders just give you a way to customise
this section, so that you write a mini-program that gets invoked on each
vertex to figure out what its final appearance should be.



The tie-in between points 2 and 3 is that the way things are exposed in
2 has to be in a way that lets you do everything you want to do from 3
if vertex shaders were there.

So we might find that to start with 2 exposes some stuff that has to be
set to NULL, with the plan being that a primitive geometry can have a
shader progam attached to it as well.

I.e., so that as well as saying "this is the type of thing I'm drawing,
and this is where to find the vertices" it also says "and this is how to
process the vertices (or do the default pipeline if NULL)".

Am just looking through the GL vs D3D interfaces to see what the common
requirements are, and who has the simpler API.


-dair
___________________________________________________
mailto:dair+refnum.com       http://www.refnum.com/