Anyway, my current idea is to how I can reduce the amount of textures, bumpmaps and all kinds of graphical things in general. I explored the idea during my chess viewer assignment and it worked well with certain parameters limitations. But I noticed a) peformance problems with realtime calculation and b) hard-to-setup parameters cause it's was a mostly additive and multiplicative system. To solve problem b, I want to make a system that's a series of editable commands with a flexible set of parameters. The resulting idea shares many elements I can also find in my bytecode/c-code language concepts. So either way it should be possible to combine them with good benefit. And it's a first example of where it's useful to have a flexible bytecode in addition to static code - plus you can mix them with no problems. Problem a on the other side requires a bit more thinking. Originally, I had to precompute everything to compensate it. But since I don't always want to keep values as they are, my idea is to use memoization to store the results of each calculation step. And since the formula system would use sine, cosine etc very often, it's also possible to memoize these, too. In combination it becomes a memoization that's also a set of meomoized data sets etc. So we don't need to store and render them all the time, accessing them on demand and in all possible combinations. I quite like the idea of that. Memoized memoization.
And thinking about it, this system could work well for all kinds of formulas you'd normally change relatively often. Like in a synthesizer where there are many, many ADSR and oscillators you don't want to calculate all the time. I kind of like the idea, though it needs a lot of experimentation to work better than by default. Yay!