Open djulien opened 2 months ago
Shaders can already get the duration of the effect (XL_DURATION, float), buffer size (RENDERSIZE, float2). I believe the buffer size would already account for the center location (center of the buffer is center as defined in xLights.
Can this be closed?
Can this be closed?
I was under the impression that RENDERSIZE only had x/y but if it has X/Y/Z then it could be closed..
Is there a Z render .. I thought we were always 2D?
Is your feature request related to a problem? Please describe. The built-in effects are great, but sometimes it would be helpful to add a new custom effect or to change the behavior of an existing effect - for example, enhance an existing 2D effect to work in a particular way on a 3D sphere or cube, or maybe the range of a parameter on an existing effect needs to be expanded. Currently this requires modifying the xLights source code and recompiling it, which requires some familiarity with xLights internals and tool chain setup. Done incorrectly, it also could destabilize xLights (memory corruption, etc)
Describe the solution you'd like I could use a shader to do the above if the shader had a little more info about the model that the effects were being applied to. For example, if xLights passed in the X, Y, and Z size of the model, the duration of the effect, the origin or center of the model as defined in xLights, etc, then the effect behavior could be customized without changing and recompiling xLights.
The shader could ask for the model info using a generic mechanism similar to how shader settings are currently passed in from the xLights UI (ie, JSON structure) - maybe xLights could recognize references to the model or sequence properties within the shader's JSON file and then supply those from the internal C++ structures rather than from the UI (kind of a SerializeToGL function driven by a JSON structure).
Taken to extreme, this capability could even be used to replace any built-in xLights effect with a shader, so that built-in effects could be easily modified or extended using a set of user-editable shaders. (a set of out-of-the-box shaders could be supplied with xLights, or built up as needed). Eventually it might be nice to have ShaderToy, SHADERed, or equivalent added into xLights, but initially an external tool could be used to make the custom shaders.
Describe alternatives you've considered an alternative would be adding custom scripting to xLights (ie, JavaScript, Python, or Lua), exposing selected internal xLights structures thru that, and adding a generic Script effect UI (basically just a text editor), but shaders seem more appropriate since they would run on the GPU which is more oriented towards graphics manipulation.
Additional context not an urgent feature, just something that would make life easier (or at least more interesting) in future as models become more complex