Well I think I've thought of a work around for the array issue that should work at least using a plug-in class that has 1 set of data (however much required and could be as a separate plug-in) plus a slot for another entry of the same class - that way it would be easy to interrogate in code to set up the correct number of defined entries unlike the current necessity for a hard-wired method i.e. an array could be read in, in a single array element loop.....
I still think the gradient parameter would be an excellent addition - also requiring less work on your part than some of the other options Plus you could encourage everyone to use it by adding a simple ready to use version of it as an instance of the current OOC color selection option class/es.
I'd still say the best improvement for both authors and users would be to allow output to other formats e.g. for 3D printing either as I stated where the formula authors do all the work i.e. can set up data in a general buffer (of defined size but accessible as plain bits/bytes/words/dwrds but otherwise just like a current pixelbuffer) that can then be written out with any file extension, or this plus one or two predefined formats that are set up correctly for output by UF itself rather than set up by a formula authors code.
This could allow direct output from UF of ready-to-print 3D files or ready to play fractal sound as .wav etc.
Pre-defined values for plug-ins would be helpful - again relying on authors though - also it would be best to allow these defaults set where the plug-ins are plugged rather than just in themselves or as well as with the values where they're included at higher levels overridding those below
Storing more info for less recalculation sounds great, but also sounds like a magnitudes bigger project to implement properly compared to the others.....
Well I think I've thought of a work around for the array issue that should work at least using a plug-in class that has 1 set of data (however much required and could be as a separate plug-in) plus a slot for another entry of the same class - that way it would be easy to interrogate in code to set up the correct number of defined entries unlike the current necessity for a hard-wired method i.e. an array could be read in, in a single array element loop.....
I still think the gradient parameter would be an excellent addition - also requiring less work on your part than some of the other options ;) Plus you could encourage everyone to use it by adding a simple ready to use version of it as an instance of the current OOC color selection option class/es.
I'd still say the best improvement for both authors and users would be to allow output to other formats e.g. for 3D printing either as I stated where the formula authors do all the work i.e. can set up data in a general buffer (of defined size but accessible as plain bits/bytes/words/dwrds but otherwise just like a current pixelbuffer) that can then be written out with any file extension, or this plus one or two predefined formats that are set up correctly for output by UF itself rather than set up by a formula authors code.
This could allow direct output from UF of ready-to-print 3D files or ready to play fractal sound as .wav etc.
Pre-defined values for plug-ins would be helpful - again relying on authors though - also it would be best to allow these defaults set where the plug-ins are plugged rather than just in themselves or as well as with the values where they're included at higher levels overridding those below ;)
Storing more info for less recalculation sounds great, but also sounds like a magnitudes bigger project to implement properly compared to the others.....
The meaning and purpose of life is to give life purpose and meaning.