PDA

View Full Version : new function suggestions



eirikhm
04-29-2004, 04:56 AM
I think that the NV only functions like saturate and transpose should be included in glsl. Anyone (dis)agree?

Corrail
04-29-2004, 05:04 AM
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.

ScottManDeath
04-29-2004, 06:19 AM
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...)

supagu
04-30-2004, 11:00 PM
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....

V-man
05-01-2004, 02:01 PM
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);

bobvodka
05-01-2004, 06:04 PM
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.

Adruab
05-03-2004, 03:10 PM
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.

V-man
05-03-2004, 06:29 PM
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.

bobvodka
05-03-2004, 06:46 PM
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 :)

Adruab
05-03-2004, 09:03 PM
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.