Shaders and Large Sets of Data

Scripting Issues
#1

Having recently received a shader-error indicating that a variable couldn’t be bound due to being “possibly [a] large array”, I gather that there are limits to the amount of data that one can pass into a shader via an array.

Presuming that I’m correct, what are these limits?

And perhaps more importantly, might there be another approach that I could take in order to achieve my current purposes (see below)?

So, to describe my current purposes: What I’m attempting to do is to provide a shader with position- and size- data for a great many elements.

Now, my first thought was to encode this data in vertex-colours–and indeed, this worked! However, it also ran into the problem that Blender (which is the source for the data) internally stores vertex colours as single bytes per channel, meaning that each has only 256 potential values. As a result, I was seeing distinct stepping in my results.

Remembering the use of array-inputs in another part of the project, I set about trying to apply that approach–and ran into the problem described at the start of this post.

So… Is there some other means by which I might get my data into my shader…?

(I suppose that I could chop up my source geometry, and thus the associated data, such that the data-size is reduced. I’m hoping that there’s another way, however.)

[edit] In case it’s relevant, let me note that I don’t require that the data be alterable after initialisation.

#2

I believe that I’ve found a solution that works for my specific purpose: I’ve reverted to the use of vertex-colours, but instead of attempting to store the actual data, I’m instead storing offset-values in the range 0…1, and then separately storing the reference value from which they offset, more or less.

And indeed, this seems to work!

(Naturally, it’s not a general solution for all cases, but at the least my own issue here is resolved for now.)

#3

A buffer texture is another way to get a very large amount of data to a shader, that you can index into arbitrarily.

1 Like
#4

Indeed, I was thinking about something like that at one stage. (Although if I recall correctly, I was thinking about a normal texture, and vaguely recall that buffer textures provide additional features.)

#5

A buffer texture is more efficient for getting large amounts of random-access one-dimensional data to a shader if you do not need all the features of the texture sampling pipeline (like mipmapping, decompression, filtering, etc).

1 Like
#6

Ah, I see–that does make sense!

Thank you for the clarification! :slight_smile: