Sorry for the question: is it out of the little time wip Rhino 6; the development of the new version, it should be faster than switching from Rhino 4 to Rhino 5, since we do not need to rewrite all the code from scratch, or not?
The engine of intersection of the next version will be the same then?
Thank you
I’m pretty sure that even between RH2 and 3 not everything was rewritten from scratch. RH6 will take as long as it takes, I am sure. 
As for intersections, if you find something not working you’ll have to provide a specific example of a situation so that it can be fixed.
Matter of fact, lots of R5 code needs to be rewritten still…
The step from R4 to R5 was 32 to 64bit. Now hopefully, R6 will get a lot more attention to multithreading. Some code may easily port, but lots may need to be rewritten to fit that concept.
What features are you hoping or expecting to be multithreaded?
Basically anything that might be scripted. While there are high frequency CPUs around, the trend is clearly towards multi-core, low frequency.
It really sucks to wait minutes for a medium sized script to finish while the CPU literally sits idle.
With Grasshopper and scripting being an integral part of Rhino now, I think the design factor for commands execution speed should be automation, not user interaction… And user experience would profit for heavier operations where users currently see a delay in execution.
I am aware not every operation lends itself to parallelization, but that’s the point. Find out what can be done and do so. And if it can’t be done, at least make it thread safe.
Scripting is a linear operation and not easily threaded (since the next thing to be scripted is dependent on the current one finishing).
I’m not sure how you measure the “size” of a script. But the size has no correlation with the speed of execution.
We are always in the process of doing this…
Try to keep in mind that multithreading is not the holy grail of performance. Certainly some features can and will benefit from multithreading. But many operations, that appear to be good candidates, won’t see any benefit from multithreading. And, there is overhead for setting multiple threads, which can negate any performance gain.
I need to clarify: when i am talking about scripts I am generally thinking grasshopper. While grasshopper still executes left to right, it could make massive use of multithreading. So when I talk about medium sized scripts, I think about grasshopper generating a few hundred copies.
Then again, the script interface is just one way to make use of Rhinos functions. I couldn’t make a RhinoCommon plugin multithreaded, because there just is no guarantee, the functions are thread safe.
So the second thing I want to clarify is, when I am talking about focus on multithreading, I am talking about the possibility of using the SDK in a multithreaded environment. I do not mean to make every command use multiple Threads.
Thanks for the clarification.
I’m not sure about massive, but I’m sure @DavidRutten could implement threading in some areas. I’ll let him address this.
To make threads work, make sure you have your own copy of what you need. And, don’t call into the document from anything but the main thread.