PDA

View Full Version : feature request: indexing per attribute



overlay
10-16-2009, 10:19 AM
Hello,

Right now (from my understanding, correct me if I'm wrong), array indexing assumes all the attributes are defined per vertex. It is suitable for a mesh with no discontinuities (for example, at a given position, the normal is unique and the texture coordinate is unique).

As soon as there is a discontinuity in any attribute, all the attributes and positions have to be duplicated. For example, if a vertex is shared by two primitives with different normals but has a unique texture coordinate, the positions and texture coordinates have to be duplicated.

This is a really big issue with huge meshes.

Adding indexing per attribute would solve this memory footprint problem.

It could also allow fast switching between normal per vertex and normal per face visualization of a mesh without much memory footprint.

Let's assume we have a mesh of triangles with texture coordinates per vertex positions, face normals and vertex normals.

The required arrays (of data) will be:
1. an array for the vertex positions
2. an array for the texture coordinates
3. an array for the face normals
4, an array for the vertex normals

Case 1. To visualize the mesh with normal per vertex, you will need:
the same index array for the vertex positions, texture coordinates and normals per vertex. That's what happens right now with the single index array.

Case 2: To visualize the mesh with normal per face, you will need:
the index array used above for the vertex positions and texture coordinates and an additional index array on the face normals

The index array on face normals will look like:

0 0 0 1 1 1 2 2 2

It will be the only array with duplication. In addition, duplication is necessary only on indexes not an normal coordinates.

kRogue
10-16-2009, 11:14 AM
Admittedly I am not at all neutral in this, being a big fan of it, but there is an extension that you can use: GL_NV_shader_buffer_load, which allows for you to do exactly what you are asking, and is more general. The horrible big catch is that it is nVidia only, and not lot of hope of it becoming an EXT extension much less ARB or to be adopted into the spec.

Ilian Dinev
10-16-2009, 04:45 PM
(captain obvious)
A) It's easily possible via geom-shaders and buffers. Just sub-optimal.
2) You can have per-face normals.. by recalculating them inside the frag-shader:


vec3 ilTriangleNormal(in vec3 varPos){
return normalize(cross(dFdy(varPos),dFdx(varPos)));
}

Without passing any normals, tangents/bitangents, one can have normal-mapping with such code ^^ .

Jan
10-17-2009, 03:46 AM
"Without passing any normals, tangents/bitangents, one can have normal-mapping with such code"

You mean dFdx as Tangent and dFdy as Bitangent ??

Does that really work properly? Is the precision any good? When you have a smoothed normal, can you use it to smooth tangent and bitangent in the shader too?

And what about performance? Does using the derivatives incur any overhead?

That would be a nifty trick that could save me lots of bandwidth.

Jan.

kRogue
10-17-2009, 04:06 AM
There is one nasty bit about using dFdx and dFdy to calculate normals, tangents and biTangnets (having done it myself): it will be horribly faceted. There is another part that is ungood: you will be computing the normal, tangent and biTangent per fragment, so even if you wanted faceted values, you are recomputing it per fragment. On the other hand if you use a geometry shader then you can get that per primitive calculation done, additionally, you can even get _some_ smoothing (at cost of additional calculation) if you use the neighbor aware input for the geometry shader (the smoothing would be to the 3 neighbor triangles, which is typically not the same as most smoothing is done).

Brolingstanz
10-17-2009, 07:02 AM
Yep, with compute kicking into high gear I'd be tempted to run the vertex pile through a T&L(&Clip&Amplify) compute kernel, then send the whole shooting match through to the VS for bindless indexing, and relegate the incoming attribute stream to a channel for the various bindless attribute indices. Talk about your bandwidth savings days, and just in time for Christmas. ;-)

Ilian Dinev
10-17-2009, 09:51 AM
//=================[[ Create tangent and binormal ]]==========================================[
// gotten from http://www.pouet.net/topic.php?which=6266
// Use like this:
// mat3 TBN = computeTangentFrame(gl_Normal, varPos,texCoord);
// normal = normalize(TBN * normalFromTexture);


mat3 computeTangentFrame(vec3 normal, vec3 position, vec2 texCoord){
vec3 dpx = dFdx(position);
vec3 dpy = dFdy(position);
vec2 dtx = dFdx(texCoord);
vec2 dty = dFdy(texCoord);

vec3 tangent = normalize(dpx * dty.t - dpy * dtx.t +0.001);
vec3 binormal = normalize(-dpx * dty.s + dpy * dtx.s + 0.001);

return mat3(tangent, binormal, normal);
}


I haven't optimized it yet, but is fast enough for me.
I don't notice blockyness when the normal-texture is not blocky (RGB8):
http://dl.getdropbox.com/u/1969613/auto_TBN.png
When it's a DXT1, of course this is expected:
http://dl.getdropbox.com/u/1969613/auto_TBN_dds.png
Both screenshots are at:
- CSAA 16x4, GTX275;
- 4 dynamic specular lights, a bunch of trig-algebra in the FS, albedo disabled;
- active unoptimized mirror+glGenMipmaps;
- generally stays above 700fps but right now I'm running other heavy software in parallel.
- ZCull passes

Of course, having the TBN in the vtx-shader is better - this auto-TBN in the frag-shader is just nifty when you can't have the TBN beforehand. I bet it'll also save some bandwidth if geom in frustum is 1+ mil tris.

P.S removing the TBN calc makes the app run at 590fps instead of 580fps

overlay
10-17-2009, 10:47 AM
To kRogue:

I will look at this new nVidia extension, thanks.

To Ilian Dinev:

I just pick normals for illustration purpose.

An other example would be to visualize a scalar value constant per primitive. you want to send the scalar as a 1D texture coordinate and use a 1D texture to map the scalar value to a RGB color (while using normals per vertex).

Jan
10-17-2009, 11:43 AM
Interesting!

But the blockiness comes from the blocky normal-map, the calculations don't change. When you said the result is "horribly faceted" in the previous post, i thought this might come from the GPUs 4x4 pixel-block processing, but it makes sense that that should not introduce any problems.

I intended to put the TBN calculation into the GS for a long time, but so far i never had time to try it.

Jan.

Ilian Dinev
10-17-2009, 11:59 AM
An other example would be to visualize a scalar value constant per primitive.
"flat" input option :) . It can still require some vertex-unwelding to be done in offline preprocess, but not as much as before.
Also, there's gl_PrimitiveID. Anything else that isn't geom-shader based needs explicit unwelding by disabling the vertex-cache - something not supported on half the GL3 cards, I guess.

overlay
10-17-2009, 02:05 PM
I can see how the "flat" qualifier in the output of a vertex or geometry shader can allow combining normals per vertex and texture coordinate per primitive. (ref: OpenGL 3.2 spec page 96/GLSL 1.50.09 pages 29 and 42)

However, I really don't get how it would save any memory footprint at all. Can you elaborate, please?

Ilian Dinev
10-17-2009, 04:52 PM
When the tri-winding is clockwise and the "flat" modifier selects the first vertex's data, this is an example mesh:
http://dl.getdropbox.com/u/1969613/openglForum/flat.png

9 verts, 7 tris ^^

Right-click ->View Image in Firefox, it's 1024x1024

overlay
10-19-2009, 10:54 AM
To Illian Dinev:

Dealing with the flat qualifier requires to add the constraint that each vertex will be attached to a unique face. Starting from a mesh without this constraint (for example a mesh coming from a file) requires to write a non-trivial algorithm to solve this issue (re-ordering indices). In addition this algorithm has a computational overhead and may not have a trivial solution.

Imaging the mesh is just a tetrahedron (so, a closed mesh).


http://upload.wikimedia.org/wikipedia/commons/2/25/Tetrahedron.png

On the image, vertex 0 is on left-side, vertex 1 is in the front, vertex 2 is on the back and vertex 3 on the top.

Let's start with the triangles described by a list of vertices in counter clockwise order and for which the first vertex is the one with lowest index.

face 0: 0 1 3 (front face)
face 1: 1 2 3 (right face)
face 2: 0 3 2 (back face)
face 3: 0 2 1 (bottom face)

Now, in order to use flat modifier with the provoking vertex being the first vertex, I have to rotate some of the lists.

Let's assume the following algorithm: iterate over faces, pick the available vertex with lowest id still not used by any previous faces. At the beginning all vertices are marked unused.

face 0: pick vertex 0. mark X on faces where vertex 0 cannot be used anymore as the first vertex:

face 0: 0 1 3
face 1: 1 2 3
face 2: X 3 2
face 3: X 2 1

face 1: pick vertex 1.

face 0: 0 1 3
face 1: 1 2 3
face 2: X 3 2
face 3: X 2 X

face 2: pick vertex 2, re-order the face list to be

face 2: 2 0 3

face 0: 0 1 3
face 1: 1 2 3
face 2: 2 0 3
face 3: X X X


face 3: Ooops, no more vertex available to be a good candidate as the first vertex.

Yes, I could have picked vertex 3 for face 2, then vertex 2 would be available for face 3, with another kind of algorithm. But the point is, this processing is not trivial and not guaranteed to succeed.

Ilian Dinev
10-19-2009, 11:07 AM
Uhm, I did mention that some unwelding will still be necessary, but that it's far not as much as NumVerts=NumTris*3.
The algorithm to do a non-optimized version of synthesizing such an ordered+semiunwelded mesh is not rocket science (mark first available, if not available then unweld). The maximum-optimized version could be a complex greedy-algo, but looking at real-case models, the optimization isn't worth it at all.

P.S.
I already deal with vertex-unwelding all the time in my offline preprocessing tools, so it doesn't look like rocket science to me.

Ilian Dinev
10-19-2009, 12:54 PM
Ookay, as the thing is quite easy to make in basic form, I wrote the code to do the reordering+unwelding.
Have fun:








void* Flattenize(int NumVerts,const void* VertsData,int VtxSize,
int NumTris,int* inoutTriVtxIndices,const void* TrisData,int TriSize,
int &outNumVerts,int &outVtxSize // write-only, updated on success
){

struct FVTX{
const char* var_data;
const char* flat_data;
};

if(NumVerts<=0 || NumTris<=0)return null;

FVTX* verts = new FVTX[NumTris>NumVerts ? NumTris*3 : NumVerts*3]; // worst-case size, including precaution if some verts are not being used originally
int FNumNewVerts = NumVerts;

const char* inVertsData2 = (const char*)VertsData; // utility pointering
const char* inTrisData2 = (const char*)TrisData; // utility

int i;
for(i=0;i<NumVerts;i++){
verts[i].var_data = &amp;inVertsData2[i*VtxSize];
verts[i].flat_data=null;
}

int* pVtxIndex = inoutTriVtxIndices; // to allow easy change to per-primitive-numVerts
for(i=0;i<NumTris;i++){
int FirstOpenSlot = -1;
int* pTriVtxIndex = pVtxIndex; pVtxIndex+=3;
const char* triFlatData = &amp;inTrisData2[i*TriSize];

for(int j=0;j<3;j++){
if(verts[pTriVtxIndex[j]].flat_data!=null)continue;
FirstOpenSlot=j;
break;
}
if(FirstOpenSlot==-1){ // uhoh, unweld first vertex
int oldIdx = pTriVtxIndex[0];
int newIdx = FNumNewVerts++;
pTriVtxIndex[0] = newIdx;
verts[newIdx].var_data = verts[oldIdx].var_data;
verts[newIdx].flat_data = triFlatData;
}else{
//-----[ note: there is a possibly easy optimization: ]----------[
// instead of blindly picking the first vertex, smartly pick
// the most suitable one. The most suitable one is the one
// that is used in the least number of triangles.
// Thus, have the FVTX struct keep track of how many times
// it has been used.
//---------------------------------------------------------------/

while(FirstOpenSlot--){ // rotate indices
int fstidx = pTriVtxIndex[0];
pTriVtxIndex[0] = pTriVtxIndex[1];
pTriVtxIndex[1] = pTriVtxIndex[2];
pTriVtxIndex[2] = fstidx;
}
verts[pTriVtxIndex[0]].flat_data = triFlatData;
}
}

//--------[ now compose result verts array ]------------------[
int NewVtxSize = VtxSize + TriSize;
char* pResult = new char[FNumNewVerts*NewVtxSize];
memset(pResult,0,FNumNewVerts*NewVtxSize);

char* edi=pResult;
for(i=0;i<FNumNewVerts;i++){
memcpy(edi,verts[i].var_data,VtxSize); edi+= VtxSize;
if(verts[i].flat_data){
memcpy(edi,verts[i].flat_data,TriSize);
}else{
memset(edi,0,TriSize);
}
edi+= TriSize;
}
delete[] verts;

outNumVerts = FNumNewVerts;
outVtxSize = NewVtxSize;
//------------------------------------------------------------/
return pResult;
}



Now, your test-case:



// ************************* TESTING AREA. WEAR HELMETS ***************************************




struct VVV1{
int test1;
float pos[3];
float norm[3];
float data1[7];
};
struct TTT1{
int test2;
float clr[3];
};


VVV1 origVerts[4];
TTT1 origTris[4];

int origIndices[4*3] = {
0, 1, 3,
1, 2, 3,
2, 0, 3, // ****** I had to reorder this to match your problem-scenario
0, 2, 1
};


struct RES_VTX{ // resulting vertex
VVV1 v; // varying data
TTT1 t; // flat triangle data
};


void DO_FLATTENIZE(){ // main() for test
int resultNumVerts,resultVtxSize;

for(int i=0;i<4;i++){
origVerts[i].test1 = i + 100;
origTris[i].test2 = i + 10000;
}

RES_VTX* data1 = (RES_VTX*)Flattenize(4,origVerts,sizeof(VVV1),4,or igIndices,origTris,sizeof(TTT1),resultNumVerts,res ultVtxSize);

print(resultNumVerts);
print(resultVtxSize);


for(int i=0;i<resultNumVerts;i++){
trace("vtx[%d]= %d , %d",i,data1[i].v.test1,data1[i].t.test2);
}

for(int i=0;i<4;i++){
trace(" tri %d: %d, %d, %d",i,origIndices[i*3+0],origIndices[i*3+1],origIndices[i*3+2]);
}


}


And the debugging output for it:


resultNumVerts = 5
resultVtxSize = 72
vtx[0]= 100 , 10000
vtx[1]= 101 , 10001
vtx[2]= 102 , 10002
vtx[3]= 103 , 0 ***** NOTICE
vtx[4]= 100 , 10003
tri 0: 0, 1, 3
tri 1: 1, 2, 3
tri 2: 2, 0, 3
tri 3: 4, 2, 1

Ilian Dinev
10-19-2009, 01:13 PM
Idea on optimization:
in your scenario, each vertex is used by the same number of tris. In one pass that looks like the reordering+unwelding pass, do no unwelding, instead mark a boolean in the vertex "bool isProblematic" = true. Clear all vertices' pFlatData and start reordering again, but not picking problematic verts if possible.
That way, your problem-case will not unweld any vertex.

overlay
10-20-2009, 07:45 AM
This is definitely a very interesting approach with the current capabilities of OpenGL. This thread is now in my bookmarks, thanks!

I still believe that "indexing per attribute" would be a nice feature to have in a future OpenGL version.

Thanks again!

Y-tension
11-03-2009, 07:58 AM
Excellent post! This has been bugging me for some time. There is just one downside to using per-attribute indices as suggested: cache misses. However this is all extremely flexible, actually, it's flexible enough for me to want to implement it :)!

Yann LE PETITCORPS
11-21-2009, 08:58 AM
This is generally the new method with OpenGL now ... MAKE IT YOURSELF !!!! :)


@+
Yannoo

Jan
11-21-2009, 10:33 AM
Get your facts straight, before posting some rubbish.

Yann LE PETITCORPS
11-21-2009, 10:51 AM
My last post was corrected :)

But the reality remain unfortunately the same ... :(

For example, where can we find goods and completes tutorials, that work on the big majority of OS and computers, that explain really for new beginners that begin with OpenGL how to use OpenGL 2.x and that come with a lot of examples for to handle basics operations such as the rotated cube, simple texture use and others stippling things ?


@+
Yannoo

Yann LE PETITCORPS
11-21-2009, 11:41 AM
Thank to Dorbie for this wiki :)


http://www.opengl.org/wiki/Tutorials

It's clear that this was now really OS independant and that OpenGL 3.x is only one invention of me :)


@+
Yannoo

Alfonse Reinheart
11-21-2009, 01:25 PM
Just because nobody likes your idea, and everyone thinks its trivial to do on your own, that doesn't give you the right to throw a temper tantrum on other people's ideas.

Yann LE PETITCORPS
11-21-2009, 02:01 PM
Ok, all my apologies about this involuntary temper tantrum :(

But, **PLEASE**, note that I have already proposed this type of "indexing by attribute" since a very very long time before ... for the same type of response : "no possible, make it yourself" ... and I have make this myself :)

If OpenGL is now used by a lot of persons it's because it was in the past relatively simple to use and was **really** OS independant => this seem to be loose with lastest versions of OpenGL :(

If we have to make all by ourself, I don't think that this was on the interrest on a API (that in theory is make for to simplificate things and permit to not reinvent always the wheel ... certainly not the contrary)


@+
Yannoo

Yann LE PETITCORPS
11-21-2009, 03:48 PM
#include <gl\gl.h>
#include <gl\glu.h>
#include <gl\glut.h>


static void redraw(void);
int main(int argc, char **argv);

int main(int argc, char **argv)
{
glutInit(&amp;argc,argv);
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH);
glutCreateWindow("My first GLUT program");

glutDisplayFunc(redraw);

glMatrixMode(GL_PROJECTION); //hello
gluPerspective(45, //view angle
1.0, //aspect ratio
10.0, //near clip
200.0);//far clip
glMatrixMode(GL_MODELVIEW);

glutMainLoop();

return 0;
}


static void redraw(void)
{
glClear(GL_COLOR_BUFFER_BIT);

glPushMatrix();
glTranslatef(0,0,-100);
glBegin(GL_TRIANGLES);
glColor3f(1,0,0);
glVertex3f(-30,-30,0);

glColor3f(0,1,0);
glVertex3f(30,-30,0);

glColor3f(0,0,1);
glVertex3f(-30,30,0);
glEnd();
glPopMatrix();
glutSwapBuffers();

}

and the makefile in Linux :

gcc -o myProg myProg.c -lglut -lGL -lGLU -lX11 -lm


Normaly this was the basic method for to display a single triangle with OpenGL.
This was extremely simple and can be very easily understand by all the world.

Where can I find a thing that is equivalent but with the use of the lastest OpenGL and OpenGL ES APIs and that can work in more that one or two years ???


@+
Yannoo

Alfonse Reinheart
11-21-2009, 05:04 PM
Where can I find a thing that is equivalent but with the use of the lastest OpenGL and OpenGL ES APIs and that can work in more that one or two years ???

You won't. What you wrote above was "extremely simple", but it was also a pretty good example of how the hardware actually worked back in those days.

Nowadays, that code is nothing like how hardware works. The effort that driver developers have to spend to make that code work on a modern GPU is massive.

The modern equivalent of that code, with manually building shaders, buffer objects and VAOs, etc, may look more complicated, but it's a lot simpler to implement. It's closer to how the hardware sees the world, and it is much easier to make functional and fast.

Making driver developers jump through hoops to implement things that are perfectly doable by us isn't helping make OpenGL more stable. They have plenty to do, what with exposing new functionality in new hardware, fixing driver bugs, etc. Why should they work on some minor convenience feature for us when they're already busy making the next generation of hardware work?

ZbuffeR
11-21-2009, 05:23 PM
If you want something simple to use for high level features, try a high level engine or scenegraph which hides the GL details and even cast shadows are easy :
http://www.openscenegraph.org/projects/osg

Yann LE PETITCORPS
11-21-2009, 10:59 PM
Thanks, it's was exactely what I have wanted to hear :)

This is now very more difficult for the beginner point of view because the OpenGL API was now make for simplificate the drivers devellopments (it's the world in upside down ...).

Please, why was invented OpenGL, for simplify the life of develloppers of OpenGL implementations or "only" for simplify the life of the final user that can use a very simple API and haven't to know how work really very various hardwares that work on very various OS and is really difficult to drive directely in asm (cf. hide the complexity of the hardware) ???

So, I suggest for the next versions of OpenGL to have an API that work exclusively with hexadecimal and assembler (so without C/C++ code support of course) because it's too hard to implement with the new hardware :)

And I note that this was already and unfortunely beginned with the use of shaders :)


@+
Yannoo

Alfonse Reinheart
11-21-2009, 11:49 PM
Please, why was invented OpenGL, for simplify the life of develloppers of OpenGL implementations or "only" for simplify the life of the final user that can use a very simple API and haven't to know how work really very various hardwares that work on very various OS and is really difficult to drive directely in asm (cf. hide the complexity of the hardware) ???

Neither. It was made to be a hardware abstraction API that allows user code to work without changes on multiple hardware platforms.

For example, take Intel's current line of embedded graphics cards. Their OpenGL implementations are terrible. Awful. Their Direct3D implementations are decent enough to run games on. But you can't write any decent modern OpenGL code and expect it to run on Intel's embedded graphics cards.

What good then is a cross-platform API if you can't use it to write code for one of the major platforms?

Yann LE PETITCORPS
11-22-2009, 02:08 AM
So are you ok with me that an very old OpenGL program (for example a very basic 1.0 OpenGL code) have obligatory to work on a alls news opengl implementations, yes ?

If no, this new opengl implementation isn't a true OpenGL implementation (because it can't pass the OpenGL tests), true ?

I have really problems to understand why a decent (software only perhaps) OpenGL implementation can't be done on the PocketPC platform for example, when this Pocket PC is certainly more fast than a old 386 where I have already can to make a lot of basics things with OpenGL on ...

And don't understand why we have to be obligatory aligned with the badest standard (that isn't standard for others hardware/OS that itself ...).

It's because this is the major platform that it have alls the rights ???
And are you really certain that it can remain the major platform in some years or after ?

So, why the major platform doesn't want to make as alls the others and help really for to use and upgrade a standardised API that exist since a very long time and that work on almost all the newests hardwares and OSs that are born since the first OpenGL implementation from SGI in 1992 and that is based on the IRIS GL API ???

In some words, I don't really understand (it's false, I think to have understand but find it very stupid, so I prefer to say myself that I'm stupid and that I understand nothing ...) why a "micro" OS for personnals computers can give now the superiority and "destruct" the work that have to be hardly done by a lot of compagny for to make a professional API that work on professionnals computers, just for replace it by something that is only make initialy for handle video games, it's all ...


@+
Yannoo

Alfonse Reinheart
11-22-2009, 02:53 AM
So are you ok with me that an very old OpenGL program (for example a very basic 1.0 OpenGL code) have obligatory to work on a alls news opengl implementations, yes ?

I was a supporter of Longs Peak. So I would have been very happy with a clean, backwards incompatible break between old OpenGL and new OpenGL. So no, I'm not OK with drivers having to support 15+ year old software.


If no, this new opengl implementation isn't a true OpenGL implementation (because it can't pass the OpenGL tests), true ?

The OpenGL 3.2 specification does not require the support of old software. It has fully removed most of the ancient API cruft that makes writing drivers difficult. Practical realities make it hard for driver developers to break the link between 3.2 core and 3.2 compatibility, but perhaps this will happen in the future as the specification evolves.

And there are no "OpenGL tests." I wish there were.


I have really problems to understand why a decent (software only perhaps) OpenGL implementation can't be done on the PocketPC platform for example

Why do you use OpenGL? To draw semi-decent pictures at 1 frame per second? Or to make something at reasonable framerates?

If you want performance, you need dedicated hardware. A software only implementation is of no value to anyone wanting to do anything of significance on a PocketPC.


And don't understand why we have to be obligatory aligned with the badest standard (that isn't standard for others hardware/OS that itself ...).

What is the "badest standard" you are talking about?


So, why the major platform doesn't want to make as alls the others and help really for to use and upgrade a standardised API that exist since a very long time and that work on almost all the newests hardwares and OSs that are born since the first OpenGL implementation from SGI in 1992 and that is based on the IRIS GL API ???

Are you asking why Microsoft isn't supporting OpenGL? Quite frankly, I don't blame them.

Historically, the OpenGL Architectural Review Board has been terrible at exposing new functionality. OpenGL had a minor advantage in the GeForce 1-2 days. But when programmability came around, the ARB had nothing.

It wasn't like hardware vendors were hiding the fact that there would be programmable hardware coming. Everyone know it was happening. But the ARB took a good year to come out with ARB_vertex_program. A year after Direct3D had vertex programmability. If you are a game developer, why would you make an OpenGL game that couldn't even use this powerful new hardware, rather than a Direct3D game that could?

OpenGL has been behind the curve ever since. ARB_vertex_buffer_object came out long after D3D had solved that problem. ARB_framebuffer_object came out long after equivalent D3D functionality. GLSL appeared 2 years after D3D had shader functionality.

And here's the thing: most of the OpenGL solutions have these really annoying stupidities with them. Buffer objects have their ill-defined usage hints. Framebuffer objects have this stupid hack where a driver can refuse an FBO for no particular reason. The myriad of problems centered around GLSL would take me far too long to explain.

That's not to say that D3D doesn't have API annoyances. But most of OpenGL's problems are born out of things that sounded like a good idea at the time, yet now can never be changed. Because breaking backwards compatibility is a big no-no in OpenGL land. Whereas D3D can do it whenever it is appropriate. This allows them the freedom to correct mistakes.

Game developers need a graphics API that can evolve, one that can improve with the times. An API that, when new hardware comes out, will immediately provide them with access to it. OpenGL couldn't do that. Not cross-platform; NVIDIA has always done a good job with coming up with strong extensions in a timely fashion. But they're not cross-platform.

And you may say, "Who cares about what game developers want?" Well, game developers create the vast majority of software for graphics. They drive most graphics software. They force Max/Maya/etc to use whatever API that they use. And since that API is getting good performance, CAD houses start looking into using it.

Yann LE PETITCORPS
11-22-2009, 03:20 AM
But ok, it's true that I'm very stupid and that I was a very bad guy that can only emit critics about an API that work very well since a long time on alls hardware and alls OSs and remain always and for a long time a very very wonderfull API :)

So very long life to the OpenGL API and alls my apologies :)



@+
Yannoo

Yann LE PETITCORPS
11-22-2009, 04:12 AM
Alphonse,

Only for your information (two seconds for to find it on the net) :

http://blogs.intel.com/research/2008/02/real_time_raytracing_in_your_p.php


@+
Yannoo

Ilian Dinev
11-22-2009, 04:15 AM
I wish the troll would use google-translate :)

See, ARB stumbled a few years ago. The industry couldn't wait. Khronos took over the desktop GL, announced promises. Mobile devices with 3D acceleration were a niche. WinCE-based devices come with DX, but too few devices have gpus - and too few users have those devices, thus PocketPC IHVs don't bother providing another API. ARM cpus are way too horrible for software-rasterization, mobile games stay 2D, so why bother. Nokia/Symbian/Google/Apple/etc stick with GLES. iPhone has a dedicated gpu, fixed screen-size and non-interpreted code, GLES there is extremely successful. Other devices have botched-up GLES implementations, random screen-sizes, random lack of gpu, random input -> GLES there is not successful. PSP, DS are fixed-hardware, have their own low-level API.
Khronos stumble with GL3.0, Microsoft stumble with Vista and DX10 exclusivity. Gamers move to consoles: x360 is cheap and has games, uses modified DX, DX9 on PC prospers with console-ports, more PC developers move to consoles. PS3 uses its own low-level API and Cg; Wii uses its own LL Gamecube API. Other users move to Mac and Linux (desktop GL), but are not graphics-users anyway.
Intel sees the high-performance computing-threshold has been passed for 99% of users, step into gpu-land by reintroducing their ancient silicon (previously known as "the first graphics decelerator") as mobo-integrated; bribing, overpricing and threatening around to gain a huge share by suckering customers ("Vista certified" scandal). Shop around, you generally cannot find a mobo without an integrated GMA. Customers find-out they can't use 3D mode at all, either via DX or GL. "Vista's fault". Intel start to veery slowly fix their horrid drivers to support what the majority of customers use: several Steam games, that use DX. Linux enthusiasts write rock-solid IntelGMA-OpenGL drivers, and so does Apple.
Meanwhile AMD has enough troubles for a few years, and thus don't invest heavily on desktop-GL, for their DX troubles are already enough to handle. AMD bounce-back and start tackling GL3.x seriously. nVidia insist on cushioning the transition of GL1.x->GL2.x->GL3.2, plus keeping an edge in driver-reliability, thus push for compatibility-profiles. GL3.2 spec looks really great.
Vista becomes stable. Win7 gets released with HW GDI acceleration returned to core, lower RAM footprint and improved filesystem performance - joy for everyone. x360 starts to lose some ground, with no improvement on the horizon. Many PC users still stick to WinXP, but it's a matter of time till they upgrade. Desktop-GL soon might have little relevance, if it wasn't for the extensions and some cpu-relieving features in this progressively cpu-bound world. GLES starts to gain serious ground after iPhone, G1 (*smirk*) and iPhone3GS started feeding 3D-vis developers constantly. Around the iPhone, OSX lures developers.

DX provides the shader-compilers
GL requires shader-compilers, but allows extensions, to let developers optimize paths.

DX11 provides multithreading
GL is already multithreading perfectly on nV cards, transparently to the developer.

DX provides shader-bins
GL might get this soon.


So, this enough history for you?
Now, look-up what DX9/10/10.1/11 are, what a gpu is, what an API is, how different graphics APIs try to aid in visualization and what they expose from the HW. You may understand why GL3.2 and DXx are the way they are, and why no-one (who can be bothered to study/read) whines about shaders, programmable-functionality and learning-curves. Or lack of features that you can easily add/implement in programmable-functionality *snicker*.

Overall, GL is becoming a good valid choice. Laptops with older Intel GMA will remain with their problem, and remain used for the sole purpose they were bought for: email. "New OS is buggy" can no longer hide inaptitude of drivers and HW, so natural selection will have its word.


Too much troll feed, sorry. I vote for clean-up after he snacks.

Alfonse Reinheart
11-22-2009, 04:18 AM
But ok, it's true that I'm very stupid and that I was a very bad guy that can only emit critics about an API that work very well since a long time on alls hardware and alls OSs and remain always and for a long time a very very wonderfull API

None of what you said about OpenGL is true. It does not "work very well" on "alls hardware" or "alls OSs". There is a lot of hardware and OSs that use OpenGL ES rather than regular OpenGL. That's because ES is not backwards compatible with regular GL; it was designed specifically for those platforms and removed a lot of the cruft in OpenGL.

And OpenGL hasn't been a "very very wonderfull API" since programmable hardware came out.

Your rose-colored view of OpenGL is not reality. That is why your positions make no sense.


Gamers move to consoles: x360 is cheap and has games

Small point: you're a half-decade late for that move. Gamers moved to consoles long before the 360. The PC gaming industry hasn't been driving the overall gaming industry for a good decade or so.

Yann LE PETITCORPS
11-22-2009, 04:45 AM
And the PS3 doesn't exist ???

Are you very certain that this console use a D3D driver ???

I haven't never a day hear about something with a "Folding at Home" that work with a Xbox 360 :)


@+
Yannoo

Yann LE PETITCORPS
11-22-2009, 04:47 AM
And how can you see a blue ray with a XBox 360 please ?

@+
Yannoo

Yann LE PETITCORPS
11-22-2009, 04:52 AM
I prefer to stop the discussion because you are really on a very bad faith ...


@+
Yannoo

Ilian Dinev
11-22-2009, 04:58 AM
>_< I admit I kind of expected a more coherent reply.
I have 2 PS3s, PS2, PSP, PSX.... And I have written homebrew-style code on each. How you got the idea that I'm an x360 fanboy, I don't know. No-one on the PS3 uses the modified GLES2 lib that Sony provides, so it's not relevant to this hi-jacked thread (which btw turns into an IRC chat. Take a breath, reply in a solid and coherent manner, please).



@Reinheart
s/Gamers move to consoles/Most of the remaining PC gamers move to consoles; There, corrected :)