Hi! We are experimenting with grouping objects as Model Groups in Revit so we can use Shapespark’s Switch Objects extension to switch multiple things at the same time. However, Shapespark doesn’t recognize the Model Group entity, only Type entities as the ‘second level’ and RVT links as the ‘third level’ (Materials being the ‘first level’).
This is a bit problematic because of two reasons:
a) As Shapespark doesn’t recognize separate Instances of the same Family as different ‘switchable’ objects, if we want to switch an instance of a Sofa, it will switch all instances of the same type, even if they are in another room, for example. We have been able to circunvent this by creating individual Types for each instance we want to create a Switch Object extension for, but this kind of goes against Revit’s logical workflow.
b) If we want to switch several different ‘second level’ objects (Types) at the same time, we found out this is achievable by grouping them into a Model Group and then turning the group into an external Linked model, which would be the ‘third level’ object. This too goes against Revit’s logical workflow because after we send things to a Linked model, it becomes much harder to change and update stuff as we go.
So to sum up, I have 2 questions for developers:
a) Could Shapespark have a way to separate an Instance of a Family as an individual object?
b) Could Shapespark recognize Model Groups as ‘third level’ objects the same way as it recognizes Linked Models?
Unfortunately, since Revit elements are matched to Shapespark objects by names, we don’t see an easy way how we could address just a single instance of a family, without addressing all the other instances (having the same name).
We will add support for groups, but since our plans for Q3 are already full, we will work on it in Q4. If I understand correctly, this would also help for case a) - after grouping a single instance of a sofa, you will be able to address just this instance through the group name, not the family name.
Yes, I think it is correct that if Model Groups are supported, this would allow us to isolate an instance of a family inside a group. Then we would use ‘Switch objects’ on the group intead than on the family, which would kind of solve problem a) as well.
Another thing that we noticed, is that Shapespark keeps the names of the Families as they come from Revit, which is very helpful because we can reuse Extension setting from a Shapespark model from one project to another. However, we also noticed that in the case of Revit Links, Shapespark adds a number at the end of the name. It would be better if it didn’t do so (either for Groups or Links) once support is implemented, because it is very common for architecture firms to use ‘standard’ groups in a way that is similar to families (like a standard Bathroom design group that is the same in multiple projects, gathering several appliances and plumbing families together). If we use an extension to switch between bathroom layout groups, and the name is kept the same as the Revit group, we could reuse the same Shapespark Extension settings on every project just like we can do with families.
Once support for groups is implemented, my firm is probably going to do heavy usage of Shapespark (we are not able to achieve the results we want without this). I know it’s probably too soon to ask, but is there a target date for this Q4 update? So we can better plan our work around here.
Thanks again for your amazing product and attention to customers!
while you’d like them to have a simpler shared name like:
Linked Revit Model : x.rvt
Linked Revit Model : x.rvt (the same in both cases)
?
Unfortunately, it’s a bit too early for us to declare the target date for the group support. As for the link names, it a smaller change, so it should be possible to add it earlier.
I just wanted to check about how this feature development is going (Support for Groups in Revit), because this is something we really need in order to be able to create interactive Shapesaperk models for our office’s projects.
I am sorry, but some tasks in Q4’2021 took longer than anticipated, and we didn’t manage to start implementing the support for Revit groups. It’s still high in our queue, and planned for this quarter.
Hi! I just wanted to check about how this feature (support for groups in Revit) is going, because we still need it…
In case you guys haven’t been able to advance on this, maybe as a temporary solution, it would help us if you implemented a solution you suggested in the beginning of this topic - removing the automatic number that is added on the end of the linked model name. As of today, all linked models receive this number regardless of its name and quantity of instances, and this messes things up when we try to reuse the same shapespark model from different Revit files (something we do a lot in order to save time, not needing to re-do many configurations that are similar between projects).
It would be even better if Shapesaprk only added this number if several instances of the some linked model were found. If there is only one instance, there would be no need to rename anything!
I look forward to hearing from you!
Sorry for the delay, but your question is right on time. We’ve already implemented the support for model groups and the new version of Shapespark with this feature will be released tomorrow.
As for the the linked models numbering, we’ll take a look at this issue and get back to you.
@Alexandre, the 2.5.2 version with the support for model groups was released on Friday.
As for the links, we’ll change the exporter not to add the : NUMBER : location <Not Shared> suffix.
Which approach do you find better:
Stripping the number for all the links? If a model has two links to the same file x.rvt both links are named Linked Revit Model : x.rvt and are considered instances of the same object type from the Shapespark perspective?
Leaving the number for different links to the same file? In this case the links names are Linked Revit Model : x.rvt : 1 and Linked Revit Model : x.rvt : 2 and the links are not considered object instances from the Shapespark perspective.
Hi @wojtek ! We are really excited with this new update!
The best, I guess, would be to be able to choose this when exporting from Revit through the plugin, because I can foresee scenarios in which 1. or 2. would be better. However, in case this isn’t possible, then I think you should strip the numbering completely. For us, the problem is having no control over which instance of the link receives which number (mostly, the numbering messes up the ‘Switch Objects’ extension). If you don’t add any numbering, we can still rename/renumber links ourselves as needed in Revit before exporting to Shapespark. So, to sum up, I think it would be better to get rid of the numbers!
I haven’t had time to test the new Model Group feature yet, but I suppose it behaves similar to the Linked Models feature we are discussing?
Finally: thanks for this new feature and for your attention and commitment to our request!
Thanks for the feedback. We prefer the simpler solution, so stripping the numbers from the names of the linked models. I think we’ll manage to implement it for the next release.
