Import and open large, complex files to be made easier to work with!

[DanielS]

Hi!
Im working with a heavy, multiple geometry file to become easier on the computer to work with; – anyone has ideas for this?
Should geometries be linked somehow

[wim (Wim Dekeyser)]

Hej Daniel -

@DanielS

Im working with a heavy, multiple geometry file to become easier on the computer to work with; – anyone has ideas for this?

This depends a bit on the specifics of the model and your task involved.
If you have a lot of geometry that is only serving as a reference, you could have that in a separate file and insert that linked and referenced. That would allow you to keep the size of the file that you are actually working with down and would possibly help when saving and opening the file.

If you keep reference objects in the same file in which you are working, you could extract the render meshes of those objects and either delete or hide the originals. If those objects all have the same visual appearance (color or materials), you can then also join those mesh objects into a single object, potentially greatly reducing the overhead of dealing with lots of objects.

If you need to work on all objects in the scene, you’ll have to organize the layers and only have those layers on that you need for your task at any given time.

Working with a coarser display mesh on NURBS geometry (either on the document level or by object) can also help making it easier to navigate a busy scene.
-wim

[DanielS]

Thanks, Wim!
Im working with a model where imported *stp- and polydata needs to be ‘visible’ but at times also work as a reference where i can snap points and curves to. Could this then be inserted and referenced only?

By “render meshes”; do you then mean to convert them to *fbx-data or similar?
In case, ive done so, trying to keep it low-poly but didnt give significant difference i believe.

[wim (Wim Dekeyser)]

Hi Daniel -

@DanielS

By “render meshes”; do you then mean to convert them to *fbx-data or similar?

No. In any shaded display modes, NURBS objects are represented by their “render meshes”. These are generated on the fly and are what you see on screen. Using ExtractRenderMesh lets you extract these as separate objects, and, depending on the settings and number of these, can be quite a bit lighter than the objects they were derived from.

@DanielS

[…] but at times also work as a reference where i can snap points and curves to.

In that case, only using the render meshes won’t work.

@DanielS

imported *stp

That will typically come in as blocks and those don’t necessarily always make sense. It might be better to explode those blocks and move objects into different layers that can be turned on and off as required. Pascal wrote a useful script to automate the exploding and moving to layers part of this:

Separate blocks with hierarchy to single blocks

Hi Tom - There is ExplodeBlock - - that will remove all blocking of the selected block instance and sub blocks. Otherwise there is ExplodeBlockToLayers, below… That also removes the blocking altogether but then makes each bit a single non-blocked part on its own layer. If that sounds helpful, please try this plug-in - it mostly works but may choke on very large files… ExplodeBlocksToLayersV6.rhp (15.5 KB) Unblock the rhp file in Windows , then drag and drop onto Rhino from your disk. The co…

Hiding anything you don’t need typically is the best way to make files easier to work with.

@DanielS

Could this then be inserted and referenced only?

Again depending on the situation, you could insert a complex file (that is a separate 3dm file), create a dummy block in your working file, and use ReplaceBlock to switch between the dummy and the complex versions.
-wim

[DanielS]

Thanks again, Wim!
I think i get the main outline idea of it all now. I think i will simply make two ‘link’ files where one will be a ref and the other simply ExtrctRmesh for visual purpose. Hope it works Thanks again!