Non-primary design options are by definition not a valid part of the project so should not be included in the concept ‘everything’ if everything means the whole current valid project.
I think Speckle should (by default) ignore all non-primary Design Options. In the picture below a secondary design option is used to make an overview of Doors but is being sent in the stream when I send ‘everything’.
This is really good feedback. I definitely agree that typically people are only going to want to see their primary design option in a stream. Quick question for you, as I assume you use Revit more than myself, do you see a use case for retaining the option to send all the design options instead of only the primary one?
hi @conner I can’t think of a situation where that would make sense. It would be full of variations of the design overlapping in meaningless ways.
How Revit works is that every time one makes a design option there are at least two options: the ‘Primary’ which is shown in the ‘Main Model’ and should be part of ‘send everything’, and as many other options as one makes.
It might be useful to export individual Design options, for example for the doors above. But I think that is an edge case and is not really how Revit is designed.
Myself I think there are three places where Design Options can be handled:
- send everything: only primary are part of ‘send everything’
- send/filter by view: already respects design option settings
- send/filter by design option might be a new possibility
Never underestimate the autonomy of users to do weird things. I’ve seen design options used and abused in many different ways.
While I think the Primary only as default is a good call, I can remember examples where losing others would be problematic.
@jsdbroughton would you like to expand on some examples and maybe good ways for speckle to handle them?
A bunch of ways, but the two most significant would be Design Options used in place of what would have been better as Worksets.
Secondly, which was ingenious if mad was Design Options used for fit-out where Primary was shell and core. I suppose this was a special case of the first example.
In both instances jettisoning Design Options not primary would have been detrimental. It’s all manageable with the options you put forth, but it would need to be communicated and as such @connor suggestion option to toggle the functionality would be both that, and the override option.
@DuncanNZ I’m imagining a scenario where maybe there is a design option that lives exclusively in one option and has no counter-part in another option. For example, maybe a client is considering adding a canopy to a project. I would then model that in a design option so if we decided not to not add the canopy, I could just turn it off. But maybe I would want to see that alongside the rest of my building in a Speckle stream (and maybe @jsdbroughton is right and I really should be using a workset for that ). Regardless, we already have an existing issue dealing with the scope of the “everything” category [Revit] `Everything` filter doesn't truly grab _everything_ · Issue #1308 · specklesystems/speckle-sharp · GitHub. I’ll mention this thread in that issue so that we consider it when we get around to fixing that.