   Shader Fun
  Is there a way to use direct3d compiled shader code in opengl?Also, is there a way to pass multiple vertex streams to the opengl pipeline like you can in direct3d? I am trying to get a vertex shader I wrote that interpolates model vertices to work with opengl. Unfortunately opengl is very cryptic on describing how to accomplish anything. 
  Check out CG from Nvidia. It was codeveloped with Microsoft''s DX HLSL, same syntax, and I assume same functionality.;quote:Original post by GodBeastX  Also, is there a way to pass multiple vertex streams to the opengl pipeline like you can in direct3d? I am trying to get a vertex shader I wrote that interpolates model vertices to work with opengl. Unfortunately opengl is very cryptic on describing how to accomplish anything.   It''s pretty tempting to reply with "RTFM" here. The OpenGL docs are extremely specific when it comes to vertex attribute / vertex attribute streams. Perhaps you should simply read them...Vertex    programs (section 2.14) can access an array of four-component generic    current vertex attributes.  The first entry of this array is numbered    zero, and the number of entries in the array is given by the    implementation-dependent constant MAX_VERTEX_ATTRIBS_ARB.  The commands void VertexAttrib{1234}{sfd}ARB(uint index, T coords); void VertexAttrib{123}{sfd}vARB(uint index, T coords); void VertexAttrib4{bsifd ubusui}vARB(uint index, T coords);    specify the current vertex attribute numbered <index>, whose components    are named <x>, <y>, <z>, and <w>.  The VertexAttrib1ARB family of commands    sets the <x> coordinate to the provided single argument while setting <y>    and <z> to 0 and <w> to 1.  Similarly, VertexAttrib2ARB commands set <x>    and <y> to the specified values, <z> to 0 and <w> to 1; VertexAttrib3ARB    commands set <x>, <y>, and <z>, with <w> set to 1, and VertexAttrib4ARB    commands set all four coordinates.  The error INVALID_VALUE is generated    if <index> is greater than or equal to MAX_VERTEX_ATTRIBS_ARB.    The commands void VertexAttrib4NubARB(uint index, T coords) void VertexAttrib4N{bsifd ubusui}vARB(uint index, T coords);    also specify vertex attributes with fixed-point coordinates that are    scaled to the range [0,1] or [-1,1], according to Table 2.6.    Setting generic vertex attribute zero specifies a vertex; the four vertex    coordinates are taken from the values of attribute zero.  A Vertex2,    Vertex3, or Vertex4 command is completely equivalent to the correpsonding    VertexAttrib command with an index of zero.  Setting any other generic    vertex attribute updates the current values of the attribute.  There are    no current values for vertex attribute zero. [... Stuff about attribute aliasing ...]The vertex specification    commands described in section 2.7 accept data in almost any format, but    their use requires many command executions to specify even simple    geometry. Vertex data may also be placed into arrays that are stored in    the client''s address space. Blocks of data in these arrays may then be    used to specify multiple geometric primitives through the execution of a    single GL command. The client may specify up to 5 plus the values of    MAX_TEXTURE_UNITS and MAX_VERTEX_ATTRIBS_ARB arrays: one each to store    vertex coordinates, edge flags, colors, color indices, normals, one or    more texture coordinate sets, and one or more generic vertex attributes.    The commands ... void VertexAttribPointerARB(uint index, int size, enum type,boolean normalized, sizei stride,const void *pointer);    describe the locations and organizations...    (add after the first paragraph, p.22) The <index> parameter in the    VertexAttribPointer command identifies the generic vertex attribute array    being described.  The error INVALID_VALUE is generated if <index> is    greater than or equal to MAX_VERTEX_ATTRIBS_ARB.  The <normalized>    parameter in the VertexAttribPointer command identifies whether    fixed-point types should be normalized when converted to floating-point.    If <normalized> is TRUE, fixed-point data are converted as specified in    Table 2.6; otherwise, the fixed-point values are converted directly.    (add after first paragraph, p.23) An individual generic vertex attribute    array is enabled or disabled by calling one of void EnableVertexAttribArrayARB(uint index); void DisableVertexAttribArrayARB(uint index);    where <index> identifies the generic vertex attribute array to enable or    disable.  The error INVALID_VALUE is generated if <index> is greater than    or equal to MAX_VERTEX_ATTRIBS_ARB.    (modify Table 2.4, p.23)    NormalCommand  Sizes    ized?   Types ----------------------  -------  ------  -------------------------------- VertexPointer 2,3,4noshort, int, float, double NormalPointer 3    yes    byte, short, int, float, double ColorPointer  3,4  yes    byte, ubyte, short, ushort,  int, uint, float, double IndexPointer  1    noubyte, short, int, float, double TexCoordPointer    1,2,3,4   noshort, int, float, double EdgeFlagPointer    1    noboolean VertexAttribPointerARB  1,2,3,4   flag   byte, ubyte, short, ushort,  int, uint, float, double WeightPointerARB   >=1  yes    byte, ubyte, short, ushort,  int, uint, float, double VertexWeightPointerEXT  1    n/a    float SecondaryColor-    3    yes    byte, ubyte, short, ushort,   PointerEXT    int, uint, float, double FogCoordPointerEXT 1    n/a    float, double MatrixIndexPointerARB   >=1  noubyte, ushort, uint Table 2.4: Vertex array sizes (values per vertex) and data types.  The "normalized" column indicates whether fixed-point types are accepted directly or normalized to [0,1] (for unsigned types) or [-1,1] (for singed types). For generic vertex attributes, fixed-point data are normalized if and only if the <normalized> flag is set.  ;  unfortunately reading the specs is about as interesting as watching paint dry and they make no sense to a beginnerif they changed the style people would probably get into them ;  Agreed, the extension specs are badly organized, a whole OpenGL SDK doc should be entirely rewritten from scratch. But you have to fight through them, there is no other way. They may be chaotic, but they contain a wealth of information, and tons of precise details. It becomes much easier, once you get used to it.;  Sidenote: I guess this is what you get, when pure technicians and developers write docs, instead of having dedicated people (who can actually write) do that... ;  I belive easier documentation is part of what the ARB are looking at with regards to pushing OpenGL as a game graphics API ;  Even if ARB makes new kind of SDK, I still hope they will keep the old way as backup. It takes a while to get used to it, but when you do it''s just nice. It gives you very detailed information on just about everything. The only thing that misses is some simple examples of use (like the ones added to ARB_VP).   You should never let your fears become the boundaries of your dreams. ;quote:Original post by _DarkWIng_  Even if ARB makes new kind of SDK, I still hope they will keep the old way as backup. It takes a while to get used to it, but when you do it''s just nice. It gives you very detailed information on just about everything. The problem is not the information provided in extension specs (which is undoubtly present, and is in fact very precise most of the time), but the way it is presented. The later should be changed. The main problems with extension specs are (IMO):1) they are written as a kind of addendum to the original core specs. This leads to the "(add after the first paragraph, p.22)" type clauses. It is extremely annoying trying to co-read and real-time inserting the paragraphs into the core specs while reading. Some extensions are readable if you simply ignore this, but not all, and certainly not for beginners. Extension specs should instead be written as stand alone documents, with appropriate cross references to the core spec.2) Dependencies on other extensions. This is highly chaotic, and the way they are handled seems to be very inconsistent from one extension spec to the next. Instead, common dependencies (ie. dependencies with standard ARB extensions) should directly be included into the main body text, and more exotic dependencies should be added as an appendix to the spec.3) Extension specs are usually written by many different authors, from different companies, with different writing style. ARB approved extensions should instead be written by an ARB appointed team, and it should always be the same team, using the same consistent writing style and language.;  Oh, and I forgot:2.5) If a new ARB extension introduces backward dependencies with older extensions, then the specs of those older extensions should be updated to reflect the changes. This keeps everything consistent accross the whole range of ARB exts. A kind of extension spec versioning system should be introduced to avoid confusion.