I am trying to modify files from the “outside” - means I do not wanna open them manually.
Some time ago @stevebaer has been explaining to me how to import and export via a headless RhinoDoc. This works perfectly fine.
Now I have been asking myself how I would modify a document.
Is it state of the art to use a headless RhinoDoc again read a file, modify the content and then save it over the old document?
Or is there a more elgant way via FileIO and a File3dm?
Have you given File3dm a whirl? There are some nice samples to help you get started. I think File3dm would give you the results you need. The only thing to note is that File3dm doesn’t offer as much access for read/write that opening heedlessly would, but this is because it in theory offers more efficent ways to edit data without expanding it into a fully open document.
e.g. → I’m pretty sure File3dm doesn’t load ArchivableDictionaries on RhinoObjects
Basically I would also like to understand the differences between File3dm and RhinoDoc. What is the difference and what are advantages or purpose of useage of File3dm?
Sorry for the leaving you hanging there.
I think you’re right, I don’t see any way to modify definitions in File3dm. I believe headless doc is the way to go.
I have to be honest, I’m not 100% sure on what the differences are exactly. I’m trying to set up a Benchmark.Net test app to compare the speed and memory usage of the two for similar functions, and also just my own curiosity and also a Benchmark.Net sample with Rhino.Inside would be nifty.
I assume File3dm can be faster and more efficient because it’s modifying data in a blob, wheras a headless RhinoDoc actually runs like a RhinoDocument, events fire, you have access to (almost) the full RhinoCommon api.
@tobias.stoltmann can you please share how you would go about doing it via RhinoCommon? How is it that you want to modify the instance definitions? A File3dmInstanceDefinitionTable is a collection of InstanceDefinitionGeometry. I guess you are looking for the modify methods on InstanceDefinitionTable? I’ll trace these to see what they are calling and see if they are something we could bring to rhino3dm.
Looking at the modfy functions, they seem to do quite some bookeeping since they are assumed to be run while Rhino is open.
While you you don’t have access to the modify functions, you can create and add new Instance Definitions with rhino3dm. So you can look at existing InstanceDefinitions, see their properties, get the IDs of the objects, etc, and build new InstanceDefinitions from that. Don’t know if that fits what you want to do.
@fraguada
Exactly - I woudl like to modify an InstanceDefinition via the InstanceDefinitionTable.
I would take an existing InstanceDefinition and duplicate it in the new document or update it’s objects if it already exists.
So for my better understanding: This means File3dm is the better/faster choice, right?
While you you don’t have access to the modify functions, you can create and add new Instance Definitions with rhino3dm. So you can look at existing InstanceDefinitions, see their properties, get the IDs of the objects, etc, and build new InstanceDefinitions from that. Don’t know if that fits what you want to do.
You mean instead of modifying an InstanceDefintions Objects the solution woudl be to copy the content, delete the definition and create a new one with the same name?
Now that we have support for headless docs there is quite a bit of overlap in functionality between the two classes. You’ll need to profile your code if you want to compare speeds between using one over the other. I don’t think we can give realistic performance differences between the two classes without creating exactly the same type of operations that you are trying to do.
File3dm is part of opennurbs and therefore is also available in our rhino3dm libraries. Its primary benifit is that it is available in rhino3dm which runs as a library that does not require Rhino installed on the end user’s computer. RhinoDoc has a lot more functionality because it does require Rhino.