Is the ‘Query Model Objects’ going to support the referenced layer in the attached 3dm in the future in Rhino 8?
I’ve created a feature request RH-89602 Query Model Obects to support worksession objects.
If i recall this might get covered with a more enhanced import component. Currently worksessions are windows only and the model objects need to be in the active document.
2 Likes
In a mature workflow, I actually propose to use the Import component. However, in some scenarios, I would like to use to reference the worksession objects for quick, dirty manipulations, and this will help to save time.
Can I see more detail in the workflow you are looking for? There are some decent tricks we can pull with using the import components and model objects. Details would be great.
1 Like
Sorry for the late reply.
In a large project in Architectural Facade, model size normally are too big, and we will use seperate files instead of all-in-one.
In the construction stage, the import omponent in my fixing mature workflow acts a significant role, this is great.
But in some reasons, you just want to check the old version file with the new one, so attaching the older file and other relevant 3dms, then visually mannually check the attributes of the geometry, and maybe you need to regress the portion of the atrributes by the older one. What’s the most efficient way is to quickly select multiple objects (they could be in different layers) and reference to gh to go with specific programs. However, if I use import component, I have to go with the following steps:
1, drag components out and place
2, copy the file path of the target files, maybe multiple files, so multiple times
3, click import
4, drag multiple match and filter components
5, check the objects’ specific features
6, filter the objects ……(multiple times to select exactly what you want)
Comparing to the old way of elefront referenced objects’ steps:
1, drag components out and place
2, reference objects you want
These two way have their own advantages. I expect the reference-object way should be supported officially.
May be a simple way that duplicates a modelobject with the attributes of the referenced object and omit the guid is enough for me.
There are a number of ways to approach this. Let’s figure out a way that works best in this situation.
Just as a start, if import Content is used to grab the outside file. This does not come with Guids. Then the can be Cached into the file if wanted or compared with attributes in Grasshopper to the objects with in the file.
Here is the import, filter and find attributes part. Essentially it is a reference in itself.
While it is not always necessary to Cache the objects by grabbing the result of the cache, the objects and the new Guiids can be used later in the process.
This approach is systematic but not flexible enough. Here arises an issue that it’s hard to select exactly what I want when the objects do not all share the same attributes, or the objects I need are a part of them.
For example, objects ‘n1-n10000’ may have the same attributes, but I only need ‘n1’, ‘n2’, ‘n3’, which could be window-selected easily. How can I quickly grab these objects by the import means without modifying the original archives?
Also, I may need to repeat this operation multiple times with different criteria.
It’s like, it’s right there for the taking visually, but you just have to go the long way around OFFICIALLY.
If I needed to extract ‘n11’, n’29’ or 'n??’ with two digits that end with 5 or 6 just as a random example… I’d use regex filters
regex_model_object.gh (14.7 KB)
I don’t like to rely on filtering indices since a dataset can change and you end up having a mess with shifted lists and what not. A regex filter in a panel does not automatically update.
The example of ‘n1-n10000’ represents a huge number of objects, which do not really have the name or userstring for ‘n1’, ‘n2’, ….
They have the SAME attributes of layer, name, and portion of the complex user texts, etc., which can not be distinguished by just a few simple rules.
Ok, good luck
This is a bit confusing because we have a lot of information here about what will not work, although little information about what will.
If Window select is a critical important part of the process. Then import and run the Cache to get those objects in the viewport and selectable. Then select run the analysis in Grasshopper off a Model Object Param. Of course then the selection can be changed at anytime using Window selects.
When imported objects using can be Cached using a CacheName in the to specify an identifier. That CacheName can also be used to effect the Layers the object land on if it is important the duplicate objects are on different layers. Details on CacheName can be found here: Content Cache Updated Guide
Technically userdata could be used to ID objects, but that is not always necessary.