Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 10

Thread: new function suggestions

  1. #1
    Junior Member Newbie
    Join Date
    Sep 2003
    Location
    Oslo / NA / Norway
    Posts
    23

    new function suggestions

    I think that the NV only functions like saturate and transpose should be included in glsl. Anyone (dis)agree?

  2. #2
    Member Regular Contributor
    Join Date
    Apr 2002
    Location
    Austria
    Posts
    328

    Re: new function suggestions

    These function would be nice be are not necessary. Transpose can be used by switchen vector and matrix at a matrix-vector multiplication and saturate can be done by clamp(x,0.0,1.0).
    So there's no really need of these functions.
    There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

    There is another theory which states that this has already happened...

  3. #3
    Member Regular Contributor
    Join Date
    Mar 2001
    Posts
    468

    Re: new function suggestions

    What about things like(most of the functions are CG built in functions)

    -lit
    -refract
    -determinant
    -round
    -sign

    -the possibility to specify inverted and transposed matrices as uniforms (like in ARB_vp/fp)

    -the possibbility to get (texel) width and height of a texture bound to a sampler as integer variables (could be easily done by myself, but requires work...)

  4. #4
    Junior Member Regular Contributor
    Join Date
    Feb 2004
    Location
    Aus
    Posts
    141

    Re: new function suggestions

    my main suggestion is to be able to get access to the texture units like:

    gl_TextureUnit[0] instead of having to bind them yourself....

  5. #5
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264

    Re: new function suggestions

    Originally posted by supagu:
    my main suggestion is to be able to get access to the texture units like:

    gl_TextureUnit[0] instead of having to bind them yourself....
    You could just as well use a number for them instead of having a name.

    ex:

    texture2D(0, texcoord);
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  6. #6
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: new function suggestions

    the problem is that introduces too much coupling between the shader and the code which will call it. If you hardcode all your shaders to use a certain texture from a certain texture unit then you have to make sure all future programs use that texture unit for that effect.
    Doing it the uniform way allows you do decouple the shader from its resources, so all your shader knows is that its using say a 'bumpmap' shader, your application knows it has to give a value for 'bumpmap' but it can place the texture anywhere it wants.
    much more flexable and imo a much better solution than hardcoding.

  7. #7
    Intern Contributor
    Join Date
    Apr 2004
    Location
    Bellevue, WA
    Posts
    73

    Re: new function suggestions

    I totally agree.

    However, why did GLSL then choose to make all the other variables immediately translatable in glsl (inconsitent...). What I mean is that the modelview matrix is ALWAYS gl_ModelViewMatrix right? What if we are doing alternatives stuff (say full screen blur) and we're actually using it only as an index into a texture? It's still called gl_Vertex.... Why didn't the ARB do something like HLSL with the semantic syntax? (i.e. vec3 myvariable : GLVERTEX0)

    EDIT: Ok, my oops, using semantics for both the uniform variables default in gl (matrices, etc.), and for the input parameters, is what I meant.

    In my opinion this is a much better system. It would have led to functional style interface (rather than main + globals to accommodate, which is really rather weird). I mean HLSL has some downsides too (valid instructions,etc. go to who ever gets to MS first), but otherwise, the semantic stuff seems much more suited for a graphics interface.

    I mean isn't graphics all about data flow, since it's all parallelized? And doesn't a pass-return paradigm fit that better than a main-global paradigm? Someone please explain this to me (or slap me upside the head), as so far I am not terribly impressed with the way things (gl 2.0 stuff) are turning out.

  8. #8
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,264

    Re: new function suggestions

    bobvodka, I know that, but considering what supagu is saying, I suggested a more straighforward way.

    gl_TextureUnit[0] suggests an array that could contain any value.

    Originally posted by Adruab:
    Why didn't the ARB do something like HLSL with the semantic syntax? (i.e. vec3 myvariable : GLVERTEX0)
    Because it's not needed. If you want to do aliasing, that's another matter.
    I see that as a strength on GLSL's part. Unless if I misunderstood what you are saying.

    I mean isn't graphics all about data flow, since it's all parallelized? And doesn't a pass-return paradigm fit that better than a main-global paradigm? Someone please explain this to me (or slap me upside the head), as so far I am not terribly impressed with the way things (gl 2.0 stuff) are turning out.
    It's really a matter of style.
    I think there is nothing stopping them from updating the spec and modifying the compiler to accomodate this style.

    You can pack your globals into a struct right now if you wish.
    It's a pretty insignificant difference. There isn't much to explain.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  9. #9
    Member Regular Contributor
    Join Date
    Apr 2004
    Location
    UK
    Posts
    420

    Re: new function suggestions

    Originally posted by V-man:
    bobvodka, I know that, but considering what supagu is saying, I suggested a more straighforward way.

    gl_TextureUnit[0] suggests an array that could contain any value.
    yeah, sorry, i wasnt thinking when i replied and my reply should have been directed at Supagu more than yourself (the main thrust of my point being you dont want to make your shaders dependant on a certain setup), applogises if this caused any confusion/offsense etc

  10. #10
    Intern Contributor
    Join Date
    Apr 2004
    Location
    Bellevue, WA
    Posts
    73

    Re: new function suggestions

    Yeah, HLSL was focused on working inside an Effect file interface, it seems. And, in my opinion, the effect interface is really nice (which is why I'm glad that nvidia has a version that is opengl compatible... though not glsl).

    The main-global interface works certainly, but it is very focused on a single file interface. That doesn't bother me, I personally just like being able to name my variables what ever I want (especially if I'm using them for different purposes). Aliasing would accomplish that, but GLSL doesn't have any sort of support for that right? Any plans in the works? And any idea if they are going to try to figure out a way to have effect style support?

    I mean, I know GLSL was designed somewhat after renderman, which is a well known/used interface. So I probably just need to get used to it. However, there are a lot of things I've been running into with OpenGL recently that seem like limitations, which is disappointing since in the past it's been far more flexible than DX. We'll see I suppose.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •