I’m hoping for some shader-advice, if I may:
I want to give a fragment shader access to a largish set of data-points–perhaps thousands, perhaps even tens of thousands of data-points; I haven’t yet determined the final scale of this. (Although a given fragment would likely access only a single data-point.) The data-points would each consist of a time-stamp, a state (either boolean or integer), and possibly a 2D vector.
(Okay, I don’t know whether this is a largish data-set by most standards; it is by my limited shader-experience, at least. ^^; )
This data would be updated at run-time. The exact rate of updates would likely depend on what the player was doing–there might be periods in which it’s updated every frame, and periods in which it’s not updated at all, and periods in-between.
Either way, I would expect only a few entries to be updated in any given frame.
Handling this on the Python side shouldn’t be too difficult, I think.
My uncertainty, then, is how to communicate and handle this data on the shader-side.
Would an array of some sort be a good idea? But then, each fragment would have to index into this array–would that cause problematic branching…?
It’s tempting to consider storing the data in a texture and then just using a standard texture-read.
But I’m not sure of how well that works with the time-stamp data–would values higher than one be passed through intact? Would some other means of representing time-stamps be called for?
Furthermore, storing the data in a texture would seem to imply that I’d have to transmit the entire texture every time anything changes–even if only one data-point has changed. Is that likely to perform well, especially in those periods in which there might be an update per frame?
Is there perhaps another way…?
So, as you may see, I am somewhat unclear on how I might proceed.