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

Comments

@eibre
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

The attachment:
beam-part-sampleRV.zip

@dvrvb

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Jan 28, 2019

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

@WawanSolihin

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

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

@dvrvb

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Collaborator

commented Jan 28, 2019

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

@dvrvb

This comment has been minimized.

Copy link

commented Jan 28, 2019

image

It seems related to this setting.
@eibre

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 10, 2019

  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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 23, 2019

@WawanSolihin

This comment has been minimized.

Copy link
Collaborator

commented Mar 2, 2019

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

This comment has been minimized.

Copy link
Contributor Author

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
Wawan Solihin
Fix for orphaned entities and wrong footprint information due to inco…
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.