Inserted parts like Windows in Walls use world coordinates, not local Wall's coordinates
I sketched a Slab and drew outer Walls after.
For me Bonsai's Snapping fails when I draw where hovering Faces (So basically anywhere in a 3D Model)
So the result was that all Walls were slightly off in XY and rotation.
Unfortunately I noticed that after I had inserted Windows and Doors.
It is great that I can control and readjust Bonsai Walls from Blenders Transformation Panel.
Wall Connections have to be repaired after manually though (One by one for each pair and connection)
But now I realized that that some inserted objects had strange wall depth positions, and worse, all still were off at Z angle and position too.
That means, if you have to change or correct a Wall's position or scale, you need to rearrange all inserts too.
So far in BIM Modeling I was used to Insertions being a child of their host Wall.
So existing in a coordinate system relative to their host. Similar to Objects inside a Block. So they automatically follow any Host's transformations.
(E.g. also getting invisible when hiding the Walls Layer, although their Windows Layer is still on and such ....)
Any thoughts ?
Comments
For any thing which has a decomposition, I think Alt-D with the BIM Tool activated will allow you to handle all children simultaneously.
Sounds reasonable.
Although, I think the problem is that .... by a multi selection, I lose the explicit coordinate center (?)
(Blender may take the a common center from all selected objects or the bounding box ?)
That Wall's center (= Wall draw line's start ?) is what I can estimate from Blender coordinates. From its slightly off values, I can estimate what it should have been.
Or did I get it wrong ?
Hello. Most likely related issue : https://github.com/IfcOpenShell/IfcOpenShell/issues/8113
The gist of it is that windows and doors are not "parented" to the wall they fill for a variation of reasons, so when you transform the wall with G to grab, Bonsai actually modifies the object selection to select all walls and windows to move around with the wall. This works fine when everyone shares the same local transforms, or if you use the global orientation, but as soon as you go to a local orientation and have flipped doors or windows they go the opposite direction. IMO it's not really good UX as this has also the unintended consequence of retaining the selection if for some reason you cancel the transformation of your wall. (It's a feature not a bug© : Alternatively to ALD+D like Dion suggested you can actually select the wall then hit G then right click to select all fillings in addition to the wall)
It's worse for rotation as rotating a wall totally disconnects geometrically the doors and windows. Regenerating the geometry fo the wall after rotating it will not move the fillings, only recalculate their openings geometry. And rotation may not be solved with the same "select my fillings" operation as rotation is dictated by the rotation center which when selection changes, moves (by default, you can change it in the viewport selection settings, but let's assume user doesn't want to) to be the median of all selected objects origin, so when you assume rotating a wall would rotate it along it's origin the actual origin is actually along its X axis. My 2 suggestions to fix the problem :
Also in the meantime @zoomer if you want to retain the wall origin as the center of rotation, select the wall, SHIFT + S > Cursor to selected then in the header of the 3D viewport change the transform pivot point to 3D Cursor.
That's what I expected, therefore I asked for comments.
As long as they behave like being parented, from a user's view, that's fine.
(If that means that it is really parented internally or whatever else voodoo doesn't matter)
If it would not be possible, pity, but as long we are aware of it we find workarounds.
If I got that correct, it would work when moving rotating graphically instead of numerically in Blender's transformation panel.
I also like the second approach.
Sounds complex and tedious but overall the better solution.
But no hurry from my side.
It may be worth to take the time to first think about possible solutions and their downsides and then also think about effort and priorities.
It looks like the biggest issue is with rotation (and/or mirroring, which I avoid in any CAD) only.
Maybe also a bit about with keeping inserts positions perpendicular to Wall direction/Wall depth.
But for positions along Wall direction, if the Wall needs to be moved and the inserts were already positioned globally, it would be even better when not parented .... (?)
Fair enough. @zoomer I think the decision to not use the "vanilla" parenting system is the right choice, because it has some side effects that do not fit the IFC schema AFAIK. For completeness :
To be perfectly fair I think the actual backend implementation may even be easier than it is now, I think the question as you rightly pointed at is what do majority of people assume would happen if they try to move or rotate a wall with window or doors fillings. My opinion is they would assume the doors and window keep their relative position, but I am aware my workflow is unique to me and myself and there may be other people relying on that quirk when modelling.
Could you elaborate on your last sentence, not sure I understand the point you raised ?
I think that was crap ...
If a Wall has inserts, they may have been positioned intentionally. So if the Wall gets transformed, it makes most sense if the inserts follow 100% in position and rotation.
And I think for rotation of inserts or openings in Walls or Slabs, in AEC, it doesn't make much sense other than perpendicular to the host in general (?)
And to estimate or change Insert's positions, I think distance to the next perpendicular (inner) Wall or next Insert is more suitable than from a (random) Wall's object center.
Just like your Edit Gizmos with temporary dynamic dimensions do.
Interesting. Agreed on orthogonality being what we want when designing buildings but I deal with existing buildings, and I very often have slightly (up to extremely) off center openings so I wouldn't want to enforce it dynamically. Anyways it is already enforced when first filling a wall with a window or door, the door or window rotates accordingly. It just doesn't follow the wall afterwards which we may change.
Interesting take on the relative insert position. Not sure we really want to enforce that either though, because the origin of a parametric wall is one of the only few invariants used to define it geometrically so we can rely on it for all related operations. The actual location of a junction between 2 walls may change if you modify some parameters, eg if you rotate one of the walls, if you change the wall offset, if you set a thicker material, etc. I may update the "wall-offset" window and door gizmos to dynamically add anther arrow to the next wall connection though. But there are already a lot of gizmos on these elements, not sure if we would add it or replace the other one.
Cheers
Seems like a fairly safe assumption to make for most cases I'd say. Only situation I can think of that may cause trouble is when fillings or voids are shared between elements. But that is probably the "1%", and it may be impossible to guess correctly programmatically any way.
In those situations I'd say it is up to the user to determine which wall they want sub elements to belongs to at creation time, so they move with that one element, rather than the any others.
One thing I like about using Blender parenting is if one uses Set Parent > Object (Keep transform without Inverse) we get coordinates relative to the parent object in the transform panel, which is great for precise numeric positioning relative to that wall.
Rather than deal with absolute world coordinates (which may become meaningless with arbitrary rotations, far off positions, floor elevations, etc.) one can more easily asses position relative to the wall direction and origin, like say place a window 1m along the wall axis, or 10cm offset relative to thickness.
This is somewhat brittle though, as its kept in sync with regular transforms (move, rotate, scale), but not on origin or geometric changes (change origin position, or apply transforms like position or rotation). As far as I understand, IFC seems to force wall origins for linear walls to always be at one end of the wall, and if one extends, trims or miters the wall, Bonsai updates that origin accordingly when editing a wall. That would as far as I know require re-parenting to keep the relative coordinates up to date, I haven't found a method to do so in Blender after origin change without unparenting and re-parenting again to reset offsets. We would probably be better off making a Bonsai native solution anyway to avoid undefined behavior or out of sync relative coordinates.
OK.
On the other hand, this might be "overall" a rare case. Something like a limitation or missing feature. And there will always be special cases that can't be solved by an App. And especially, is it that (e.g. existing medieval geometry projects) something that IFC can and is really meant to fully cover - or is IFC always always an idealized data set of buildings ?
Custom PSET instead or adding options for angled, rounded or filleted opening faces in all axis in the parametric Window tools ?
Fair enough.
I am only talking from the user perspective. For me it's not important where the center/origin in reality is best placed from a developer/software standpoint. It can be anywhere.
Just for user editing there might be more suitable action centers for relative coordinates and relevant distances. But I do not mean that Bonsai should use these user favorite centers as their internal tool centers.
For me it is already a great feature that I can read and edit the global center of a Window by Blender's Transformations Panel. (At least for my kind of perpendicular-only geometry cases. It may not help much for inserts in an angled plan design)
I think that is totally OK. If you have to do such drastic changes, of course you have to check, rethink and adapt your design. Maybe your 5-brick-modules Window distance from next Wall makes no more sense if the whole room got 30 cm narrower.
Indeed, some Editing Gizmos are already pretty crowded and hard to read.
I would propose 4 temporary dynamic editable dimensions, already when you select an e.g. Window to its neighbouring elements. Like vertically Opening to Floor or Slab, to Ceiling or Slab above, horizontally to next Walls or Openings.
Maybe without the overhead of the full Editing Gizmo. A Gizmo separation for placing/transformation vs editing dimensions and properties ?
Same for e.g. Walls, Slabs, .... Select a Wall and you will get 2 dimensions from both of its sides to the nearest neighbour. If read only, already a great indicator if you are still in expected position, if even editable and resulting in moving/repositioning the Wall, even better.