I got users asking me if the curve componant in the kcm can be:
exposed to the command panel rollout.
not be clamped from 0-1
animated!
Any thoughts on this? I know how hard it is to create dynamic controls and expose them as custom attributes. But you guys are super clever…I’m thinking if you disable the ability to add and remove points on the curve when exposing, you get a static number of elements. Then its just about preventing crossings, or dealing with them.
The only work around i can come up with is to dump the data to a texture channel and use a texture to manipulate the data. then in a second kcm, load in the texture and set the channel. I don’t see how to extend the modules in the kcm.
We do a lot of scalar field look-up table animation, so this is super important to us.
While nothing is impossible, some of these are big cans of worms (worms look kinds of like curves anyway )
The Curve Control allows for animatable curves, but it is not clear where the animation is stored and since the nodes you see in the MagmaFlow are build rebuilt from scratch all the time, I would have to add some form of connection to real animation controllers somewhere in trackview plus all the management related to adding/removing them (currently only Input nodes support keyframe animation and it was a PITA to get that right already). I will look closer at whether I can connect points positions to trackview controllers, but I suspect that will not be trivial. Don’t hold your breath!
Mapping input ranges outside of the 0-1 would be possible though. Clearly the UI widget supports that, all I need is a range control in the UI that specifies the X of the first point and the X of the last point. I just tried it by hard-coding a range of -10 to 10 and it worked well, so the underlying Magma code seems to have no problem with it. Will have to think about the best UI implementation, but I am on it.
Exposing the curve controls to the UI is not impossible, but since the whole exposed UI stuff is a Custom Attribute, I will have to see if I can encapsulate all existing event handlers as more general functions to avoid including all that code in the CA string definition. If I manage to do that, it wouldn’t be hard to get it there (except for the fact that the current UI paradigm assumes only Input nodes can be exposed. I might have to think about letting users expose other things like Transform nodes a la “ToSpace” and “FromSpace” to be able to change reference coordinate systems etc. It is probably a good idea.
)