support for uniform arrays is limmited in fragment shaders. If the compiler cannot unroll the loop and give hard coded adderssing for the array elemnts at compile time it will fail. you are not allowed to access arrays randomly with a runtime variable in a fragment program. you can however do this in a vertex program. Hope this helps
Originally posted by paintor: support for uniform arrays is limmited in fragment shaders. If the compiler cannot unroll the loop and give hard coded adderssing for the array elemnts at compile time it will fail. you are not allowed to access arrays randomly with a runtime variable in a fragment program. you can however do this in a vertex program. Hope this helps
well, not exactly My point was (apart from that the two shaders above are vertex shaders with a single reduction loop ) why attribute arrays arent allowed at all. Imo for a high level shading interface to the application and cases like the one shown in my first post this would make sense.
My point was (apart from that the two shaders above are vertex shaders with a single reduction loop [Big Grin] ) why attribute arrays arent allowed at all. Imo for a high level shading interface to the application and cases like the one shown in my first post this would make sense.
Ultimately, glslang must still be useful in modern hardware. Hardware is incapable of array indexing attributes. So, how would you suggest that they go about doing this kind of indexing? How would you specify how indexing works, such that hardware that can’t actually do real array indexing can still run these shaders?
Originally posted by Korval: Ultimately, glslang must still be useful in modern hardware. Hardware is incapable of array indexing attributes. So, how would you suggest that they go about doing this kind of indexing? How would you specify how indexing works, such that hardware that can’t actually do real array indexing can still run these shaders? Hi Korval, guess we again differ with our modern gaphic API design opinions…
well, by definition a high level language does things which couldn’t run one-to-one on hardware, therefore I guess it is compiled. So the compiler could support attribute arrays and just compile it down to such a ugly result which I’m now have to code by hand.
But on the other hand as it seem be to be such a complicated task for leading IHVs to implement a dialect of an 30+ year old language for their hardware it is probably really the best thing to leave as much high level constructs out as you can.
And don’t worry, with my next project I definitely will try directx just to see how often compared to OpenGL you have to use dirty hacks because the clean solutions aren’t provided by the API. But till then (Feb. 2005) I guess I just continue to post messages when I hit a point where I would have expected the graphics API to provide a clean solution to support me as coder in my effort to create flexible and good designed applications but instead have to work around the API shortcomings.
And yes, again this is a minor problem, you can live without the feature and use workarounds. Only the strange thing is, since I use OpenGL extensively I frequently find such annoying little shortcomings and summed up they don’t exactly encourage the OpenGL use. Ok, nothing is perfect in life, but I have already used lots of other (non graphic) Libs/APIs which didn’t showed this behaviour and if they did, there were always better alternatives which did not…
Originally posted by jra101: Attribute arrays are supported by NVIDIA’s GLSL implementation.
cool, nice to hear. Guess that comes from the Cg/HLSL side, so they also support attribute arrays?
Unfortunately as attribute arrays being non-standard glsl and portability being one of the main arguments for using OpenGL this is of no practical value
But good to know that there are some who know how to do it right, and that I’m not the only one who think such “special” features make sense…
My point was (apart from that the two shaders above are vertex shaders with a single reduction loop 
) why 