I notice the V6 Change Log shows this as the “issue” or “fix” for a number of commands. It’s easy to speculate about what this means, but I thought I would ask if anyone knows what it really means and the background about what’s going on. How was Rhino designed/organized before; what is the advantage of “moving” and what is “commands plugin”? How will this affect developers, if at all (besides just knowing what it means)?
For myself, I think I’m just interested in the 30,000 ft view, but maybe some others would like more detail. So a short story regarding this subject would, I think, be greatly appreciated.
I think commands are moved out of the core code of rhino, and into a plugin. Just as of it were a command made by a third party developer.
This means two things: a better separation of concerns in the code, and a promise to other developers that anything a rhino command can do, they can do as well. Both of these are good things™.
Menno is correct, but there is a little more to add to this,
We created a plug-in in V6 called “commands.rhp”. This is a plug-in written in C# using RhinoCommon as it’s SDK. By moving commands into this plug-in, we know that we have enough access at all levels in our SDK to actually implement the command.
This has not happened yet and no promises, but I am also hoping to eventually make the commands plug-in source available as a repository on github. This will provide developers with real world samples of how different tasks are done using the RhinoCommon SDK and provide potential for developers to help with bug fixes and feature enhancements to the existing code.
@stevebaer Are you doing any speed benchmarking of the old way vs the .NET way? I think a comparison of a dozen or two commands representative of different tasks would be very interesting information for developers. It would give them a solid reference from which to judge how good .NET is and help dispel any lingering doubts that a managed code solution could possibly be as fast as a native one.
I presume you folks already know the answer, but hard data is always nice. I know you certainly wouldn’t fudge the data.
Much of the low level core calculation code is the same so there will be no performance difference. Commands like “Sphere” really don’t need any benchmarking (I sure hope not). Some commands may run a little faster (Silhouette uses separate tasks/threads for each object it is running calculations against.)
