object programs

[phook]

Ok, here goes with another suggestion:

How about a object program extension?

As pixel shaders & vertex shaders allows substitiution of certain functionality in the pipe, I propose a higher level programmability for programming things such as N-patches, tesselators, procedural objects etc.

Why?

I would like to implement a level-of-detail (LOD) system that allowed artists to generate high quality objects without having to go too much into detail ("too much" is of course a subjective term).

Lowpoly versions could be tesselated with a displacement/bump map in respect to the "closeness" to the camera. Tesselation could be adjusted with perlin noise, fractal or other functions to allow high degree of zoom.

These objects micro structure would be dictated by materials (read: combination of programs and shaders).

As for the implementation they should replace whatever streams the vertex arrays to the vertex programs (or they can generate the vertices on the fly).

[Korval]

Not enough power.

Give me full control of the Command Processor. It is given the index array and the particular vertex attribute arrays. It can, also, be given some kind of constant data and has a pool of temporary registers.

From that, you can build a tesselator as well. Or, you can build n-patch support by taking each triangle and splitting it appropriately. But, one can also get the ability to build triangles from vertex arrays in any way I want. If I want to index my vertex arrays from two index arrays. so be it; I just bind a "attribute" array that just happens to hold indices that I use to index another array.

[ScottManDeath]

Originally posted by Korval:
Give me full control of the Command Processor. It is given the index array and the particular vertex attribute arrays. It can, also, be given some kind of constant data and has a pool of temporary registers.

Hi

I thought a while about it and came to a similiar solution. I would call it a "primitve program". It would get just pointers to vectors, integers ... ( for compatibility they should be the possibility to map conventional vertex and element arrays)
It should have the possibility to render any primitive (point, line, triangle, the others like trifan,quads, strips...) can be easily assembled from them) in any order. Looping, branching, texture access(for displacement mapping) would give the possibility to near everything on the card.

The output would be vertex attributes for fixed function or vertex programs

One could replace NV_point_sprite, NV_primitive_restart, ... easily

If in compatibility mode there should the possibility for notificationof a glBegin and glEnd, so we could do for example triangle fans by ourself.


Bye
ScottManDeath

[Korval]

I thought a while about it and came to a similiar solution. I would call it a "primitve program". It would get just pointers to vectors, integers ... ( for compatibility they should be the possibility to map conventional vertex and element arrays)

These arrays are already being copied to AGP memory prior to being rendered, anyway. There's no problem with making this look just like a VBO buffer, a VAO one, or a piece of VAR memory. All the CP knows is that there's a pointer to a location with a stride and so-forth that corresponds to an expected per-vertex attribute.

It should have the possibility to render any primitive (point, line, triangle, the others like trifan,quads, strips...) can be easily assembled from them) in any order.

That, I don't (necessarily) agree with. Having the CP actually change fundamental GL state could cause serious problems. I don't think it would be too limitting for the CP to be restricted to using only the primitive type it was given. Now, the CP should be able to issue primitive-list restart commands, so it can convert strips or fans into lists by restarting frequently.

Also, changing the primitive type may well induce a stall in the post-T&L triangle setup engine (the thing that uses the concept of strips/fans/lists/etc to figure out what is a triangle). Simply changing this type may not be a reasonable thing to do for a CP, from a performance standpoint.

BTW, point-sprites, as I understand it, are not converted to quads until after the vertex program/T&L pipe. If you write a vertex program for point sprites, it does not get quads.