Emphasis on neccessity of clipping boundaries of attached models for further releases


I am trying to remake or persuade my company to abandon autodesk or bentley solutions due to their financially unsustainable licencing policy and opt for Rhinos (potentially some 100-200+ licences), which is far cheaper and gets the same job done.

For our specific or general workflow in civil engineering there are minor drawbacks when using Rhino but at the same time i find them really easy things to implement with huge benefits.

I am currently designing one object on a new railway line which is 30km long.
Surveying and other base stuff are separate models which are usually huge in file size or extent.
For the workflow purposes it is really important to be able to attach external files on the fly and clip their boundaries to managable extent so the model does not get too huge to work with.

Real life example:
I am attaching 60mb .dgn surveying file as underlayer for the design process.

Problem n.1: Importing takes lot of time in order of minutes - i dont know if it is matter of optimization or it can not be further improved due to some technical limits with dgn conversion

Problem n.2: There is no real way to clip attached file to some extent. Working on object which is within 500m but the attached file´s extent is 30km, its simply not possible (extreme lags and freezes).

There should be a way to efficiently clip the attached file:

We are on the cross road now. I would really love Rhino as the main instrument in our firm but these are limitations which would cause lot of trouble and headaches if not implemented or be a reason why not to go for Rhino all the way.

I am writing this post because i dont see it on WIP7 list. Would this be implementable even for R6 in some update?


Would a clipping plane make any difference at all? At least when it comes to display speed. I don’t have any such large files to test it on.

Even when i undisplayed the attached file Rhino was still pretty laggy when clicked on something although just panning and orbiting did not seem to be affected.

I think clipping planes would solve display performance portion but not general performance when any action is invoked. Maybe if the clipping plane would internally also clip all the other than displaying data …

Clipping planes could be extened by clipping solids or clipping surfaces (curved) with options to clip only display data or also internal data of a file.
Then defaultly every attached file would come with bounding box which would be editable and acted like clipping solid assigned only to that attached file…

I cannot send you that 60mb file to test because it is private data bought by our firm (i would but i cant).

Anyone from McNeel to enlighten us how clipping planes work internally, if they only clip display geometry or there is a way to also clip everything so the model is not laggy when working with large files (very common in our profession)?


This is not an issue I ever need to deal with but I have a thought. I’m assuming that you read the whole file into Rhino and that you can actually work on it, although very slowly. Would it be possible to create a real rectangular plane that passes vertically through the entire extent of the model and then just trim off everything on the side you don’t want? I would assume that once you did this on 4 sides and then saved the result to a new file that using the new file would go much faster. Without any actual experience, though I could be wrong.

Another thing that you may have already done is to compare how much memory the file takes to the amount you have. Could it be possible that in the process of working on the file Rhino needs to make a copy of your file which is already taking up over half the available memory and thus forces the OS to start using virtual memory on disk? This REALLY slows down processing no matter what program you are running.

trimming would do it but as i say these are things that are the best done on fly without this kind of rigid processing and saving extra files. for example there can be changes everyday on the attached big file (ussually frequent update of railway corridor, big mesh file) and you need to reattach and trim again, save another file etc which creates mess and possible mistakes in workflow. thats why i am suggesting some seamless and clean solutions.

I don’t disagree with you.

As to getting someone from McNeel to help you, I think you will need to bite the bullet and send the file to McNeel. Not post it here on discourse. I can’t imagine that the supplier who you BOUGHT (as in paid real money!) the file from can have any objection to sharing it with the technical support staff at the company whose software you intend to use it with. After all, you are allowed to share it with others working on the project aren’t you? If you have any doubt you should certainly get their formal approval, of course.