Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Add a method for entering group edit mode. All i want to do is assign a group type name and the user gets flashed with a confusing warning. "A group has been changed outside group edit mode. The change is being allowed because there is only one instance of the type."
Ability to reliably edit groups through API is critical.
It is a necessary feature required in Revit API.
Virtually every model of every design firm uses model groups. And current state of Revit API drastically hinders potential automation capabilities, since making most modifications to grouped elements is not possible.
The inability to reliably edit groups through API forces developers to use workarounds that break model elements and annotations. This blocks automation efforts that could save hours on every project.
Current workarounds, and their problems:
Currently, the only somewhat-viable alternative to Group Edit mode is suggested @jeremytammik / @jeremy_tammik in TheBuildingCoder blog here:
This approach suggests ungroup-edit-regroup approach.
Although this solution can be helpful in some instances, it is not a reliable solution, since it works well only in perfect conditions and controlled scenarios.
There are the few issues with the currently suggested approach:
The approach breaks when one of the group instances is mirrored, and other instances are not. When a mirrored group instance is ungrouped and then regrouped, the newly created group will not be a mirrored group instance. Changing the group type of other, originally non-mirrored, group instances breaks the design
The approach breaks when a group is rotated. Similarly to mirrored group instances, when regrouping previously rotated group, new group instance of new group type will not be rotated. Swapping group type of other groups to the new type will break the model
The approach also breaks when “edited” group has vertical offset applied to it with “Origin Level Offset” parameter. In this case, newly created group will not have the same offset applied to it, and changing other groups to this type will also break the model.
Another problem is caused by the fact that when creating a new group from edited elements, original Group Origin point is not preserved. When swapping group instances to new group type, the shift from their original location. The biggest problem with this approach is that this causes Tags and Dimensions to either disappear, or the Tags reference incorrect host elements after the change.
All these issues are worsened by the fact that there is no reliable way to determine location properties of the group. The only location aspect of groups exposed though API is a location point. It is not possible to reliably know the rotation of the group, and whether the group instance is Mirrored or not. To be fair, there was an approach suggested to determine rotation/orientation of the group using one of the group members, a Wall or a FamilyInstance in particular (see link below). However, this approach is also hard to rely on, because in the event when a group does not have any groups or family instances, but only, for example, Floor or Ceiling elements, determining the Orientation (mirrored vs. non-mirrored) and Rotation is really complex and difficult.
On top of that, comparing Orientation and Rotation of two different group instances of the same type becomes almost impossible, because there is no way to map corresponding elements which are used for determining Orientation and Rotation.
There is another approach brought up by some users.
In the event when a Group Type has only one instance present in the model, Revit will allow modifications to be made to grouped elements. This means that within the same command it is possible to create a temporary Group Type, swap group types to a temporary type for all Group Instances of original Group Type except for one instance, change elements in that group instance, and then change the Group Type back to the original one for this instance. However, this approach is also not reliable, since Revit either does not propagate the changes properly, or “excludes” certain instances from group.
In addition, none of the existing workarounds not preserve dimensions and tags that reference grouped elements. They either get deleted, disappear, or get relocated in views. This behavior is not observed with conventional group editing.
Suggested Solution:
A potential alternative to adding Group Edit mode in Revit API would be an ability to inspect and manipulate Group Origin in Revit API. Specifically, Location (in all axis, X,Y, and Z), Rotation, and Orientation (mirrored vs. non-mirrored). This is currently not exposed in API.
However, this could also carry potential issues, and implementation of Group Edit mode in Revit API would be a more reliable approach.
Incredibly well put! A very clear overview as to why the current API for Groups is sorely lacking. I fully agree that a first and very simple step would be to expose a Groups position, rotation and mirrored state and allow us to move the origin point. If you stop and think about it, it's quite baffling that a 3d modelling program does not expose this basic stuff in their API for one of their cornerstone building blocks.
