The quickest solution is to make every point a different node, and make the spline point at these nodes... I do not like this solution as it introduces too many nodes for something as simple as Float3.

But that too many nodes don't need to end up in the game, so who cares?

Optimiziation should be the last you think of for a never ending, never good enough, maybe replaced by something differnt... project like a level editor. You can do this optimization in the output, or even in the games import function.

Flexibility and keeping it maintable is more important, so i'd use one node per control point.

You already have the necessary transformation tools for nodes -> no need to add something for the control point case.

You already plan for links between nodes, that can serve for the order of control points in the spline.

You could do things like using differnet parents for the start and the end of the curve, so allowing e.g. to connect bezier splines and manipulate the knots without breaking continuosity.

Probably more unexpected advantages show up later...

Thanks for the suggestion guys.

I currently have no game on my hands, I do this thing in my spare time, so I can put a little bit of extra effort to make the thing a bit more flexible, after all I may end up adding a different tool which could take even more advandage if I managed to make the spline editor. Afterall the guys at Autodesk made it somehow, I just cannot grasp they did it(or an alternative way).

?Otherwise if I had to do it today I would definitely go with nodes.

so I can put a little bit of extra effort to make the thing a bit more flexible

So, say you do the extra effort and make splines a special case of your data structure AND also you make a special spline editor.

You added 2 things (although you already have all required basics: node data structure and node transform tools).

In the future you may add a cool tool that aligns all selected control points vertically - nice. But wait, would'nt it be even nicer to have aligning tools for the nodes as well? No problem - put a little bit of extra effort and implement it a second time :)

You get what i mean - you actually limit flexibility and increase mainteance cost by adding special cases.

3DSMax Spline editor is very powerful, but the implementation can be done on top of nodes or float3's - does not matter.

Probably 3DSMax is built a lot on the 'special case for anything' approach i advise against, but it's not made by one guy in his sparetime.

You know XSI as well? XSI exposes its data strucures visually in a large tree, just by looking at it i learned a lot about how it probably works.

(If Max is more about technical construction, XSI is more the kind of character developement tool)

Well I'm not trying tp hardcode the spline,

technically I'm trying to think of an abstraction that can handle selecting and editing object of different types. For example the spline is a node, and when you try to edit it you can "edit" the data in the viewport itself, meaning that all the tools you have should just work like: move, rotate, scale, focus camera ect.

If the solution is hardcoding the spline editor just for having a spline editor I wouldn't do it.

?I'm looking for an abstraction that is flexible enough to handle such situations. For example in the future I may end up with a NURBs terrain editor, If I managed to make the splines works flawlessly, and develop a good abstraction
?that could scale, that would be great! Otherwise if I do not of course I would reuse my nodes code and ect ect. So again I'm looking for a way to change my abreaction, and to look at the problem form different angles where a much better solution may lie.

I'm really sorry If I somehow frustrated any of you guys, I really did not meant it.

so just for the sake of argument, putting away making every control point of the spline being a separate node(and because I currently thing that it's not an elegant solution, as it will increase code complexity In several places as parsing for example, you have to agree that having a simple array I way clear than having a chain of nodes).

?The design problem that I have is that: just because something is selectable in the viewport that doesn't mean that it is a node. That the abstraction that I'm probably looking for.

?In the spirit of reusing code for manipulator tools, and undo/redo that is already implemented, I came up with a somewhat mixed solution.
?

So when a Spline node is selected, and the user enables the "Spline edit tool" the editor will change regime, making the spline edit tool the main focus.
?When the spline edit tool is created, it will create a few "special helper" nodes(I still need figure out how to implement them), for each control point. These nodes will act as regular nodes, except that they will get deleted when the tool is ready and they do not get saved to the scene.

?So this is what I will try to code tomorrow if nothing better shows up.