Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BlenderBim IfcRepresentation ELEVATION_VIEW does not flatten the representation in the correct axis #2472

Closed
Plae-Blue-Dot opened this issue Oct 4, 2022 · 1 comment
Assignees

Comments

@Plae-Blue-Dot
Copy link

When creating an IfcType such as a window, there are 3 2D representations that can be attached:

The plan annotation view
The elevation view
and the section view

While the Plan view works no problem:
image

And the tesselation is present:
image

Both the elevation and section views get flattened in the Z direction same as plan but should be flattened in another direction
image

The IfcRepresentation Plan-Annotation-ELEVATION_VIEW Annotation2d does not does not flatten the representation in the correct axis.

Here is the ifc file:

W - 2400x1800 - Alum - Copy.ifc.txt
Just remove the .txt

@Moult Moult closed this as completed in 6adbcdd Feb 3, 2023
@Moult Moult self-assigned this Feb 3, 2023
@Moult
Copy link
Contributor

Moult commented Feb 3, 2023

This is a more fundamental problem initially brought up as a question here: #1153 (comment)

The problem is that any Plan context, such as Plan/Annotation/ELEVATION_VIEW only stores 2D XY coordinates, so therefore we are at the mercy of the orientation of the window itself. This is fine for actual Plans, but means that it's actually impossible to flatten in the "correct axis" because we're in a 2D world ... there is only one way you can flatten it.

The correct solution is to allow for 3D annotations, as well as 3D annotations that "accompany" a 3D body. That way, you can have a full 3D body window in an elevation which also has those annotated triangles "superimposed" on them to show how the windows swing.

This creates a breaking change, as previously annotations would "replace" the 3D body, whereas now we'll show both.

Note that you can now also override the body itself in a particular target view. I'll find some time when this matures to create a few examples demonstrating how this solves a number of documentation problems.

If you have an old file that breaks as a consequence and want to recover it, let me know and I can help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants