I'm assuming that storing it three ways is because the conversion is expensive? In any case, from a non-programer perspective storing in any format that massively changes the position of that data when knots are changed feels broken. And while there are valid reasons to want the data in any of these formats, it seems like it should only operate to the user as data which does not exhibit bad behavior. For my system, I feed it to my shaders in knot space because I can use the T value from a bezier interpolation to quickly lookup the associated data - but then this creates an issue for users if I store it that way. So I suppose what I'll have to do is store it in distance, then convert it into knot space for my shaders. I guess the valid use case for knot space is if people want to associate data directly with the knots, and not allow users to move it off-knot, etc. Hmm... Which is implemented in exactly none of the examples. Now, one can argue that examples don't have to be production ready, but I think when coming from Unity they should at least be a good guide into how to make something production ready, because it's a sure fire way for you to see all the issues that come up, and the amount of code which would need to be written to make things compatible with your system, as well as test that system. And likely you'd come up with an abstraction which handles this all automatically (or with a lot less code) after writing it several times. And since this code will be copied by many people, things that code does not handle will propagate to every system made with it. I think being able to reference a spline in serialization would be a big help. Having to do all this by index and keep it all in sync via callbacks is a fragile affair, and easy to get wrong. Further, tools will be written that do things to spline data outside of either of our code bases, which can easily get that data out of sync in new and interesting ways. So the more direct the binding of the data, the less chance of that happening. Right now, learning this system and handling all its edge cases is about as complex as grabbing an existing open source spline system and modifying it to your needs. For instance, the callbacks you mention don't seem to be on Spline Container or the spline class - but assuming I just can't find them, a spline is added or removed from the container - in theory I can reorder the spline data to match but what about when it's reordered in the list? Does that get called as a remove and then an add? Do I have to keep the old data around in case an add comes in which matches it? > 3. You have to completely rewrite the spline editing classes to work with multiple splines, as the ones included in the package don't work. If something is not working, please let us know with a bug report![/QUOTE] Bug reports: IN-20272 IN-20273 IN-20275 For the editor, I modified your editor as described a few posts up (to call the editor functions on all the splines instead of just the first one), but only the last spline works. So to fix it I had to pull out all those editor functions and rewrite them (but I've deleted that at this point since there were so many other issues trying to get multi-spline to work).