Noise function, can't compile it!

I’m sure this is a stupid problem.
I wanted to use noise instead of a texture for doing marble, but it always gives a compilation error.

//---------------- the line in the code
/objVertex is vec4
float o=noise(objVertex);
//----------------

ERROR: 0:65: ‘noise’ : no matching overloaded function found
ERROR: 1 compilation errors. No code generated.

and no matter what I try, it always gives that same error

//ERROR
float o=noise(vec3(objVertex));

//ERROR
float o=noise(vec2(objVertex));

//ERROR
float o=noise(float(objVertex));

//ERROR
vec3 o=noise(vec3(objVertex));

and so on…

Help!

What drivers are you using?

Many (read: most) implementations of glslang don’t actually make noise work. Modern hardware doesn’t have a facility for creating a real noise function, so they give a compile error.

Originally posted by V-man:
[b]I’m sure this is a stupid problem.
I wanted to use noise instead of a texture for doing marble, but it always gives a compilation error.

//---------------- the line in the code
/objVertex is vec4
float o=noise(objVertex);
//----------------

ERROR: 0:65: ‘noise’ : no matching overloaded function found
ERROR: 1 compilation errors. No code generated.

Help![/b]

The functions are
float noise1( genType x )
vec2 noise2( genType x )
vec3 noise3( genType x )
and
vec4 noise4( genType x )
.

(Overloaded functions must differ in more than their return type, so the name tells how many components of noise to return.)

-mr. bill

OK, those functions work. I was looking at the older documents. I guess ShaderSpecV1.051.pdf is the one I should use.

More “slight” problems :

Why do I get compiler errors for :

float t;
vec3 PP=//some value written;
t=abs((float)noise3(PP));


ERROR: 0:73: ‘)’ : syntax error parse error

But this works

float t;
vec3 PP=//some value written;
t=abs(float(noise3(PP)));

Could it be a compiler bug? I updated to Catalyst 4.2 and this problem remains.

In C/C++ programming, I write both forms so I assumed the same rules apply.

>>In C/C++ programming, I write both forms so I assumed the same rules apply.<<

They don’t.
BTW, if you want only a single float as return value you should use noise1().

[This message has been edited by Relic (edited 03-09-2004).]

The OpenGL Shading Language uses constructors, not casts. (Casts are often ambiguous.) There are also no implicit type promotion casts.

vec3 PP;
float t;
t = 2 * float( PP ); // wrong
t = float(2)*float( PP ); // ok
t = 2.0 * float( PP ); // ok
t = 2.0 * PP.x; // ok

But also, use noise1 in your example instead:

vec3 PP;
float t = noise[b]1/b; // scalar noise is “cheaper” than vector noise!

-mr. bill

I find this a bit strange…

t = 2 * float( PP ); // wrong
t = 2.0 * float( PP ); // ok

I mean, isn’t “2” a float?! I believe that any given integer anotation should be used (or at least not get compiler errors) since it can be considered a float.

This problem was rather stupid because I compiled the shader in a FX and then, a friend of mine trying it out on a Radeon, got compiler erros simply because of 2 and not 2.0

Is this annotation really necessary?! If so, why?

Originally posted by KRONOS:
[b]I find this a bit strange…

I mean, isn’t “2” a float?! I believe that any given integer anotation should be used (or at least not get compiler errors) since it can be considered a float.[/b]

“2” is a literal integer constant. Not a float. “2.” “2.0” “2E0” or “2e0” are floating-point constants.

Quoting from The OpenGL Shading Language Version 1.051.

“Compilers, in general, accept programs that are ill-formed… Portability is ensured for well-formed programs, which this specification describes.” p. 3

“The OpenGL Shading Language is type safe. There are no implicit conversions between types.” p. 13

You might consider “2” a float. So would many other people. But currently it’s not, and it’s likely to stay a literal integer constant for some time.

You are absolutely free to write non-portable shaders. Some implementations may even compile and execute them. But other implementations may not.

The problem right now it is too easy to accidently write non-portable shaders.

Perhaps some lint-like tools for the shading language are needed? (The OpenGL Shading Language Front-End Comiler Open Source might be a great start.)

-mr. bill

[This message has been edited by mrbill (edited 03-11-2004).]

It seems that Nvidia’s implementation treats ‘2’ as float. I find it more logical then ‘2.0’.

I’m not saying it is wrong. But simply strange because float “encapsulates” an int.

If, for example, there was a byte data type, then how would one distinguish it from and integer? Or a float from a double?

I see the point in “The OpenGL Shading Language is type safe”. But I can’t simply see a unique reason, rather than the one created simply for justifying it’s existence, of “2” not being a float (or considered).

There is not even room for mistakes or problems created by that. That is why I simply can’t understand the “reason”.

From a pure language perspective, 2 is an integer constant in C just like in GLSL. It is implicitly cast to float in C.
There is no implicit cast in GLSL, hence the distinction.
C spec on constants

>>>If, for example, there was a byte data type, then how would one distinguish it from an integer? Or a float from a double?<<<

There isn’t byte support, so that issue is avoided, but personally, I think it would be better to match a C or C++ behavior.

So consider putting in an implicit type conversion.

Also, I beleive the spec should explicitly mention precision. Precision has always been important to programmers.

I have noticed that the GLSL spec has taken into account “double” and “half” which I think is a good move.

The following are there :
double, dvec2, dvec3, dvec4
where is dmat2, dmat3, dmat4?

The following are there :
half, hvec2, hvec3, hvec4
where is hmat2, hmat3, hmat4?

as for vec2 vec3 vec4, not sure why these exist instead of fvec2 fvec3 fvec4.
fvec2 fvec3 fvec4 are reserved but should be used instead of the “f” less ones.
Not a big deal but …

Originally posted by Zengar:
It seems that Nvidia’s implementation treats ‘2’ as float. I find it more logical then ‘2.0’.
A couple of notes:

  1. This is dangerous, as it goes against the spec., encouraging the authoring of shaders that are not portable.

  2. “2” is, in fact, absolutely, an integer, not a float. To use “2” where a float is required necessarily means the compiler must auto-promote it from an integer to a float. C++ autopromotes, it does not think “2” is a float. The issue then is what is the general set of auto-promotion rules. In C++, the general rule includes auto-promotion of function arguments when doing function signature matching. This causes cases of silently calling the wrong function, and more to the point, requires specification of what the rules are. This specification (and possible introduction of problems calling the wrong function) could be done for a future version of the language.

  3. Lack of auto-promotion actually makes the shaders easier to read from a correctness perspective, so it’s not clear there is a big trade-off here by not having confusing issues C++ has in selecting function signatures in the presence of auto-promotion.

JohnK

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.