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

Parts: Wrong location for parts #86

Open
eibre opened this issue Jan 23, 2019 · 23 comments
Open

Parts: Wrong location for parts #86

eibre opened this issue Jan 23, 2019 · 23 comments
Labels
coordinate system Errors in non-aligned model origin coordinates export Issue with exporting process or results geometry Error in geometry results Triage Initial inspection of issue to determine labels and urgency

Comments

@eibre
Copy link
Contributor

eibre commented Jan 23, 2019

Version: IFC4RV Beta Release v0.6 .2

Steps to reproduce:

I have a simple I-beam where fire insultion is added.
Create parts of the beam
Export ifc in a view where parts are visible.

Problem:

The position of the parts are offseted.
If "export parts as building elements" is checked, the position seems to be correct.
image

Sample Revit and two ifc files created with different settings are attached:
sample_files.zip
Maybe this is related to #20

@eibre
Copy link
Contributor Author

eibre commented Jan 28, 2019

@WawanSolihin @dvrvb Do you have any idea whats wrong here, or if it's already fixed in a more recent commit?

@dvrvb
Copy link

dvrvb commented Jan 28, 2019

Hi eibre,

Nope, it's not yet fixed.
I can confirm your finding and indeed it seems to be the same issue as #20
I copied your beam and added a floor underneath the beam (as reference location which stays in place): the parts seems to runaway more if their original position is on a greater distance from the base point.
2019-01-28_beam_runaway_parts

Regards,
Dirk

@WawanSolihin
Copy link
Contributor

In this case, what is your expectation on the exported IFC? Is the beam supposed to be created as a Beam with aggregation of the parts? or it is OK with a Beam with multiple geometries?
It seems that in the latest version, the later (Beam with multiple geometry items are created). The position seems to be correct.

@dvrvb
Copy link

dvrvb commented Jan 28, 2019

With a 'standard/default' export (without the option of 'Export parts as building elements' ticked), it is now creating the aggregation: I think that's OK.
image
image

But in that case the parts are running away.

@eibre
Copy link
Contributor Author

eibre commented Jan 28, 2019

@WawanSolihin

Is the beam supposed to be created as a Beam with aggregation of the parts

Yes.

or it is OK with a Beam with multiple geometries?

I don't think it is OK, but this is the current workaround I use because the other method fails.

@WawanSolihin
Copy link
Contributor

Maybe I was not very clear. I tested the file with the latest ifcexporter and I do not get a IfcBeam with an aggregate of 5 IfcBuildingElementParts, but I get an IfcBeam that has 5 geometry items instead. The location seems to be correct (see attached). I don't think this change in the behaviour is on purpose, but it is a side effect of supporting the creation of the Type object (e.g. IfcBeamType in this case) that will have a shared geometry (using MappedItem), which is shared by multiple instances of the same type. In the past the type was not supported, or not real (i.e. one type for each instance).

So my question here is which is the desired behavior that is preferred? An IfcBeam with aggregate of 5 IfcBuildingElementPart, or an IfcBeam with a reference to IfcBeamType that has 5 geometry items (linked to the instance by MappedItem)?

@WawanSolihin
Copy link
Contributor

The attachment:
beam-part-sampleRV.zip

@dvrvb
Copy link

dvrvb commented Jan 28, 2019

with the DEV-solution until 21th january (not your latest commit of 25 jan) I got this result, with the aggregation: see sample
beam-part-sample_dvrvb.zip

@WawanSolihin
Copy link
Contributor

Yup I got that at first until I updated to the latest codes. I do not think there was any particular change directly related to it between 21 Jan to now.
I need to take a closer look.

@dvrvb
Copy link

dvrvb commented Jan 28, 2019

I'm building now the latest solution. I thought it was only related to some German translations, but I will notice it in a few moments.

@dvrvb
Copy link

dvrvb commented Jan 28, 2019

Even with the latest commit, I still got the aggregation.
Can you check if you export it with:
image

@WawanSolihin
Copy link
Contributor

Hmm that's weird. I used the file provided above, no other change made:
image

@dvrvb
Copy link

dvrvb commented Jan 28, 2019

Aha, if I choose the default export option IFC4 Reference View, I also got the same result as you.
But if I use 'my default IFC4 RV json', I will get the aggregation.
IFC_Configuration_-_IFC4RV1.2.json.zip

@WawanSolihin
Copy link
Contributor

Hmm true enough, that is the case. There is a setting there that makes the import parts somewhere. I will take a look.

@dvrvb
Copy link

dvrvb commented Jan 28, 2019

image

It seems related to this setting.

@eibre
Copy link
Contributor Author

eibre commented Jan 28, 2019

Yes @dvrvb is right. Parts are not exported unless Export only elements visible in view is checked and show parts is chosen in that views propery.

@WawanSolihin
Copy link
Contributor

  1. Parts will only be exported as an aggregation when the 2 settings are set. This is an "as-designed" behavior as I understand it.
  2. Commit 958482e fixes the issue of incorrect offset for parts

@eibre
Copy link
Contributor Author

eibre commented Feb 21, 2019

@WawanSolihin I installed the last beta5 and exported with the settings shown in the image below.
image

This is how the result looks like;
image

@dvrvb
Copy link

dvrvb commented Feb 21, 2019

Hi Eibre,

I don't want to interfere in your question at Wawan.
But although I also tested your sample before I closed the similar issue at #20
I'm now curious how your test differs from mine.
Could you test the sample in the attached zip ? (it is your beam, placed on a floor, to monitor if it stays in place or not).
2019-02-21.zip

If I export it now (IFC2x3CV2.0 and IFC4RV1.2), with a current build solution, it still stays in place.
So I'm wondering what the result is when you export it.

Regards,
Dirk
image

@eibre
Copy link
Contributor Author

eibre commented Feb 22, 2019

@dvrvb Thank you for your interest in this issue! I tested your file and the parts stay in place, the same result as you got. How ever when I added a true north rotation to project base point they are off again:
image
image

@WawanSolihin
Copy link
Contributor

WawanSolihin commented Feb 23, 2019 via email

@WawanSolihin
Copy link
Contributor

Hi @eibre,
The issue is more complicated than it appears. I need to make change that might cause regression to fic this in the right way. Do you have more test cases that contain elements with and without Parts to perform more test? Or if not possible, I can also make test version for you to check on models that you may not be able to share.

Regards,
Wawan

@eibre
Copy link
Contributor Author

eibre commented Mar 4, 2019

@WawanSolihin I can't share my model to the public, but have sendt it to Angel since I couldn't find your e-mail address.

WawanSolihin pushed a commit that referenced this issue Apr 6, 2019
…rrect projection direction for IFC4RV requirements. IFC4RV Beam (Arch) is now without error in the automated test

1st fix for issue related to runaway parts in "export only elements visible in view" (there are still situations that may cause a wrong rotation, but the test case reported in issue #86 so far looks good)
Minor typo changes
WawanSolihin pushed a commit that referenced this issue Sep 4, 2021
…rrect projection direction for IFC4RV requirements. IFC4RV Beam (Arch) is now without error in the automated test

1st fix for issue related to runaway parts in "export only elements visible in view" (there are still situations that may cause a wrong rotation, but the test case reported in issue #86 so far looks good)
Minor typo changes
@JOuellette-Autodesk JOuellette-Autodesk added export Issue with exporting process or results geometry Error in geometry results Triage Initial inspection of issue to determine labels and urgency coordinate system Errors in non-aligned model origin coordinates labels Mar 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
coordinate system Errors in non-aligned model origin coordinates export Issue with exporting process or results geometry Error in geometry results Triage Initial inspection of issue to determine labels and urgency
Projects
None yet
Development

No branches or pull requests

4 participants