Hi
I'm playing around a little with parametric cells. I've created some steel plates and can now place them through the place object tool. When I place or later copy them they're getting attached to the element I click on on placement. So when I later move my, for instance, beam around, the plates are moved along with it.
Same goes for when I add my beam to a named group, all the objects attached to it will also be added to that named group.
Is there a way to see this hierarchy of elements? And attach, detach elements from each other?
Regards,
Robert
Robert,
Robert Högberg said:Is there a way to see this hierarchy of elements? And attach, detach elements from each other?
When you place an element using the Object tool (Place Content command), by snapping to another element such as column, a graphic group relationship is established and both the elements will have a same value for GGroup. The value of GGroup can be found in the Element Information , which can be opened by clicking the MoreInfo button from the Building Element Info.
Elements can be later attached and detached from the group using Add to Graphic Group and Drop from Graphic Group commands.
Robert Högberg said:I still can't move my beam without the plates following along. Ok, so there is no way to turn off this relationship between these elements?
I still can't move my beam without the plates following along.
Ok, so there is no way to turn off this relationship between these elements?
To move the elements individually after turning off the Graphic Group lock as suggested by Marc, try
1. Select the move command
2. then select the individual element to move.
If you select the element first and activate the move command, it will move all the elements in the group.
Interesting!
It would be good to warn users that the Graphic/Named Group behaviour only works with verb-noun workflow. The Mstn help file does not mention any of this, I don't think.
There doesn't seem to be any explanation in the OBD help file either. Could you expand on how the auto GG assignment works, please?
1. Does it always assign and match a GG? Even when GG lock is off? Or does it follow the Imply Relationship lock settings? Or both?
2. Snapping: Why match to the element snapped to... always? There will be times where the user will be snapping to something else when placing the object. For example: grid lines or when using the intersect snap which requires selecting two different elements (one of which would be the 'host' element or object). Some 'sprites' showing the GG numbers would be helpful.
3. The N/G-G propagation settings are very powerful / flexible. How does the Placement tool decide what settings to use? I can see when placing a cabinet onto a wall, the cabinet would ideally be a passive member so that the user can manipulate the cabinet without affecting the host wall. Expected behaviour. But if you are placing a structural member, you may want to place it as an active member so that you can manipulate both members together. Maybe there needs to be a setting in the Place Content dialog? Defaults stored in the object's DataGroup catalog definition.
There is even the means to propagate to other groups. Hmmm...
This might be a useful means to 'parametrically' link the placed objects to a floor level / z-elevation. This is something that a lot of users have asked for and found in most if not all competing BIM apps. Any object placed would have a Floor GG assigned automatically by looking up the active Floor Manager settings. If the snaps are used, the GG number would be assigned as above, but be subsequently assigned as a 'child' GG to the active Floor GG. Again, tick box in the Place Content dialog.
A quick vid showing structural beams recognising 3d constraints.
It would be good if the Constraints tools could be jigged to prioritise the structural centrelines, end planes when selecting edges to be parallel etc.
A quick vid showing what happens when a user tries to place an endplate to a beam.
1. The user is prompted for the host object. He then selects.
2. Then loses the ability to rotate Accudraw in 3d (E). The endplate Cell can only be rotated on the Top plane.
The Mstn Place Cell tool is a bit more flexible, but I don't think does the GG matching thing. It would be good to tweak the Place Object tool be a bit more 3d-friendlly.
Screenshot of the desired endplate orientation...
Copying the endplates seems to preserve the GG assignment which is good.
This will relieve the user a bit from busy work.
As mentioned, this allows the 'nested' or children elements of the structural object to be manipulated independently, depending on the GG lock setting.
This works with the Rotate tool as well.
But does not work with a lot of other tools, including the Modify Member End and Manipulate 3d Constraints tool...
... most annoyingly, GG does not play well with manipulation via Handles.
Amazingly, the Break Element tool seems to be able re-assign the endplate GG correctly. Triforma's proximity-based post processing engine at work?
Unfortunately, the converse Join Element tool does not....
Should be a super easy fix. It would be great to see the OBD team sign up to some kind of UX quality charter or 'maturity level' roadmap when dropping tools for users to use. There are so many interfaces, compositions, use case pipelines etc that each tool would need to address at some point. The devs seem to be just sloppily 'agiling' about without a proper spec, solving just the bits they can. While the testers are just approving the code based on unit test statistics? I won't even mention how unhelpful or ineffective the Help file is for tracking these 'to do' items.
If not, I can guarantee users will just think 'Oh, another dysfunction that never seems to be corrected. Heck, they even expect us to file a SR before they will even look at it and debug their own dog food. Let's outta here'.
Even 'small' stuff add will up... eventually to a tipping point.
PS:
dominic SEAH said:Amazingly, the Break Element tool seems to be able re-assign the endplate GG correctly.
Unfortunately, doing some Un/Redo's screws this up as well.