I don’t know much about Rhino core and other CAD programs kernels so I will just simply ask. Will operation as seen on the video ever be possible in Rhino? Could dimensions attachment points survive boolean operations like that? Boolean difference alters the shape of polysurface but not drastically.
If it’s possible, will it happen in the next few years? I can’t plan to wait for a feature that might happen in 10 years, that is too long.
Actually, this is not related to boolean function but to all other operations as well because in Rhino Dimensions are treated as History and history will be lost if you change something in brep. thats why it shows you the warning also.
It’s a secondary thing for me to what it is connected, I know that I can break history in multiple ways.
What I mean is when it will be technically possible to maintain the connection between dimensions and points, edges, surfaces, etc.
Note that per-face display colors do not disappear when a boolean operation is made.
The same goes for Named Selections.
2 Likes
i think logically this should be possible. because the points your dim is associated with remain the same. with boolean only brep structure is altered. i dont know how rhino stores data, but if vertices change their guid after each operation then it wont be that easy meaning it will never happen.
As long as a slight modification of the geometry will detach dimensions, Rhino will stay with bad drafting capabilities. Another interesting thing is how this might work for the new Grasshopper components where you can swap the geometry of the Model Object? Maybe Dimensions should re-stick themselves to the new points within distance tolerance every time geometry is altered?
1 Like
there are more options i suppose how to make annotations stick. it is absolutely doable in my eyes but dont dream it will be done within this decade 
my guess - this will not happen in Rhino.
See below the data structure of a Brep. Vertices, Edges, Faces are identified by Indices. When you change the typology - other number of faces, edges, vertices - the indices will not remain the same - the connection to the Dimension-Object fails.
EDIT: it also fails because BooleanDifference is creating a new Object with a new ID.
hoped Workaround / that does not do it s job - kept because of answers below:
EDIT: this workaround does not do it s job, as BooleanDifference will create new Object with new ID.
@Gijs (Boundingbox - history does not work !! (both current Mac V7, V8 Beta)
according to the help _boundingbox supports history.
EDIT: could not reproduce this error after restart. see below.
So I hoped - to to have a hidden object - a boundingbox - that supports some basic dimensions. the dimension will rely on the boundingbox, not on the actual object - this workaround does not do it s job because of a new ID after BooleanDifference
How about re-attaching to the closest vertex after the boolean operation that I mentioned? Is it too naive? If it’s not perfect, then maybe it’s still better than nothing. It doesn’t care about vertex guids or order.
Right now Dimensions stick and move to the vertices of the object, so they know about the object and its vertices position.
You can make some modifications to the geometry, and right after that Dimension checks the vertices of its host object and sticks again to the vertex that is the closest and no further than tolerance (let’s say 0.1 mm or whatever). It’s immediately sticked again and you can move faces or the whole object again and the dimension will use updated vertices.
If Brep is so shocked or too dumb 
to remember the vertex order after the boolean operation then let the dimension object be smart.
Honestly, I’m totally convinced that this would work just fine for the architecture, but again if I’m too naive, then maybe show me why it would fail.
1 Like
This has nothing to do with Breps (IMO) and everything to do with how Rhino works with history. History records are associated with the object’s ID. As long as the object ID remains the same, the history should stay and update. That is why you can modify certain objects in certain ways and have associated dimensions update.
However, when doing a BooleanUnion for example, the original objects are deleted and replaced with a new object with a different ID. Therefore history is lost.
@Helvetosaur
ok… i was somehow wrong with my initial post.
BooleanDifference (with delete = yes) will create a new object with different ID.
This is crazy, because _filletEdge for example does keep the ID.
Of course BooleanDifference can result in more then one object… but if there is only one…
@Gijs
I tried to reproduce after a restart, only running one instance of Rhino V8 - now Boundingbox with History - it works fine.
But the workflow / workaround I hoped for, does not work because of an ID-Change after BooleanDifference - see above.
… more digging
@Helvetosaur
still believe that dimensions are bind to the ID and the component Index …
if topology changes - this changes it breaks the binding / history of the dim
see in the video: changing the topology with _filletEdge (keeping the ID) breaks Dimension…
kind regards -tom
Yes, of course, that is logical, as somehow Rhino needs to know where on the object the dimensions are attached… (face index, edge index, vertex index). If the object is replaced by another with a different ID that is an immediate top-level fail. If the topology is significantly changed so that the various component indices change (while keeping the same ID), then trying to keep the history might become unreliable, in that case I suspect they simply throw it out to avoid having wrong results. But tbh, I really don’t know how it’s hooked up internally.
Just brainstorming…
Would it be a viable approach to not only make annotations aware which point they are attached to, but also the points which annotation is attached to them? Bidirectional.
Every point could, if needed, store the guid of it’s annotations. Should the brep/crv change, then the command which builds the new geometry would recognize there’s a guid stored with the point, keep it, and also update the annotation object. Something like that.
Thinking of Revit, which has these bidirectional dependencies.
But I guess that would mean tons of core changes…
Next best thing would be, as mentioned, to search if the new geom’s vertices are nearby an annotation, and relink it. Tricky also.
1 Like
i think for future this has to be dealt with. there are solutions for this definitely.
I made a simple proof of concept in Grasshopper. Looks strange, but works good. Please note that this is just a simple clicking on data dams between operations to control the flow. If somebody knows how to code this updating/data dam system should be easy to write.
- Firstly, we specify a pair of vertices to make a dimension between them. Use 1st data dam to update position of object.
- 2nd data dam is where we make solid operation. In this example I just changed the model object geometry, but solid difference can be made in Rhino instead of Grasshopper.
- 3rd data dam is to store dimension (prevent circular reference in Grasshopper)
- 4th data dam is to update Rhino object.
- 5th is to send new points.
- 6th / 1st is to close this loop.
All that doesn’t really matter. It’s just simply updating vertex reference to the closest one after geometry is modified. It’s strange that such basic needs are blocked by the GUID change inside program.
I hope someone can cook up something more native. As long as drafting is underdeveloped Rhino will be a secondary software for me after Revit or Archicad. I would like Rhino to be my primary software.
In the video you can see that the first 2 solid operations did not alter the number of vertices used to make a dimension, The next 2 solid operations changed vertices numbers but the dimension line is still attached to the desired points.
You can try this script yourself - remember to do what is told in the middle panel before you start.
DIM LINE ATTACHED.gh (280.2 KB)
dimensions attached.3dm (355.6 KB)
3 Likes
hopefully drafting will be heavily foccused on in version 9 …
2 Likes