We try to apply scales using bim.update_representation and if didn't worked (presumably because object has openings) we reset the scales.
It was confusing for users that they scaled an object, saved IFC and they would know that scaling didn't worked only after they reopen the IFC project.
Currently there is an UX problem that it's not clear for users when it's possible to use scale or not. We definitely won't be able to safely apply scales for objects with openings, so will try to lock them from the start.
* Implement rounding of elevation
Implement rounding of elevation based on precision stored in IfcGeometricRepresentationContext
* Move formating function to tool
The problem was that shared folders names are starting with `\\`, e.g. `\\SERVERNAME\shared_folder`. When we pass path strings we usually sanitize them and save them as posix, so it's saved as `//SERVERNAME/shared_folder` and Blender has a convention that paths starting with `//` it interprets as filepaths relative to the current .blend file, therefore it was giving some weird error that `C:\Users\xxxx\SERVERNAME\shared_folder\test.blend` is missing instead of `\\SERVERNAME\shared_folder`.
So need to be careful passing strings to Blender operators and use str instead of as_posix for those operators, so \\` wouldn't be misinterpreted.
Turn out storing bpy.types.PropetyGroups was not very reliable idea as they get invalidated, just as Objects.
It's still breaking if you'd try to rename the style and then undo.
Previously transaction was never finished and therefore is_top_level_operator would never be triggered (without restarting project) making any IFC undo useless.
Previously it wsan't finishing transaction therefore:
- it was possible to undo ifc changes in the last step that had an error
- since transaction was never finished, IfcStore.current_transaction was never cleared and therefore is_top_level_operator will be never be triggered for the next operators, so new transactions are never created breaking undo for any further ifc changes.
Now user can try to undo the last action to save the file.
OperationData was always including guid key, so guid_map[None] was pointing to some object (typically a style). Also covered by rebuild_element_maps in the most cases.
Probably was harmless, it was just flooding the console with errors such as:
object address : 000002485A776380
object refcount : 2
object type : 00007FFBD1249050
object type name: RecursionError
object repr :
lost sys.stderr
File "\bonsai\bim\module\model\prop.py", line 707, in <lambda>
object address : 000002485A774520
object refcount : 2
object type : 00007FFBD1249050
object type name: RecursionError
object repr :
lost sys.stderr
File "\bonsai\bim\module\model\prop.py", line 713, in <lambda>
Not sure when this occurred but get_bmesh_from_polygon was expecting Polygon in project units but it was SI. Since it's probably better to move everything to SI, added an option to specify whether polygon is in SI or not.
Since 5677768 recalculate_dumb_wall_origin is never used and bim.align_wall is either just changing the location (align_centerline) or might change object's representation but it's already saved to ifc (exterior/interior).
Ryan Schultz