I isolated 3 objects, which are generating an error while exporting as IFC4DTV (and not generating any output).
I attached the sample rvt, and the IFC2x3CV2 ifc (which is OK).
Any idea if there is something wrong with these objects?
We'll take a look. Note that we are not actively working on DTV at the moment, but instead focusing on RV export certification. We will pivot to DTV after that. Also note that DTV isn't even finalized, so this is all really Beta code (the next version of the exporter will likely explicitly state that).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angel,
Nice to know that RV has the focus.
I just retested the sample, and unfortunately also for IFC4RV it's giving the same error, and not generating any output.
Regards,
Dirk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v.18.4.0: A little bit sad that Structural Framing is still generating errors while doing an export in IFC4RV, and causing no file output at all.
The sample at the start of this thread is still applicable.
In a real model this is for instance causing 610 export errors, which could be ignored, but even then no file is generated.
Not exporting the Structural Framing in that model results in a roof without any members ... so it seems that making the move to prescribe IFC4RV as deliverable is sadly enough still not a real option... or did I miss something?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Our IFC4RV work is still in progress - IFC4 stuff is still in Beta until we get through certification. We will definitely be using your file for our testing, though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Dirk, I just tried the first files with v18.4 and RV/DTV, and they exported for me. In RV, the placement looks a bit odd (but I am not sure if that's the viewer or the IFC file), but the 3 entities are there, and same with DTV. Which files are failing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angel,
In the sample, R2018_FAM_20180426_selection_issue_ceilings_structural framing & stiffeners.rvt
it's only the object in the middle that's causing the error, the Structural Framing.
If both the Structural Framing and the Stiffener are exported, the error of the Structural Framing is also causing an error for the Stiffener (but as collateral damage or something like that).
Since your test was OK, there must be something I was missing.
Since I didn't make any use of the parameter IfcExportAs in the sample, it guessed that most likely there must be a difference in the Export mapping table.
So I narrowed down the problem to Structural Framing that is exported as IfcBeam.
In the real model, all the Structural Framing is making use of the parameter IfcExportAs. Some are intented to be exported as IfcMember, some as IfcBeam.
It seems that not the Structural Framing in general is causing a problem, but indeed only the ones with IfcExportAs=IfcBeam are causing the error and causing no output at all.
--
In consideration to move on to IFC4RV (or DTV) the basic condition is that all geometry is exported. So there is again hope that soon this condition is met!
About viewers: at this moment it seems that for instance BIM Vision is doing very well for IFC4RV. The other wellknown viewer is handling IFC4RV very badly.
But in the case of the real model, there are also other issues with the current IFC4RV output, causing BIM Vision to crash, so I need to investigate it deeper to isolate the possible problems.
Regards,
Dirk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angel,
Since you wrote about some discplacement, I can confirm it, ... but with the ceilings.
If I export the real model without the structural framing, I'm impressed with the result in FZK Viewer (until know, so before 18.4, there were a lot of missing walls with complex openings, but they now are exporting very well!). But all the IfcCovering.CEILINGs are discplaced. So there seems still something wrong with the ceilings. XBimXplorer on the other hand is showing only the ceilings (and nothing else) ??? It's indeed getting difficult to evaluate the output based on the results in the viewers, since none of them are certified. But in this case I've have the "feeling" that there is an issue in the output with the ceilings.
Regards,
Dirk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are taking a deeper look now, so hopefully we can shed some light on this. As you mention, with no certified products, it is more difficult than usual to know what's right and what's wrong. I look forward to Revit getting through the RV certification process.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be very nice, or even Ab Fab, if at least the output is certified.
It will be a breakthrough, and it will force the viewers to do something (or not?).
I'm going to do further tests in the next days/weeks, also to discover all the improvements.
Luckely overnight the sadness is again replaced by a strong hope that soon "everything is gonna be alright".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IFC4RV
aside from the export error with Structural Framing as IfcBeam,
and aside from the discplacement of the IfcCovering.CEILINGs,
I noticed a slightly different behaviour in the generation of the amount of entities of IfcSlab.F'LOOR, but I think the new behaviour is OK.
It concerns floors with more than 1 boundary (in one floor).
With export in IFC2x3CV2, it breaks down in pieces, so each boundary will be a seperate IfcSlab.FLOOR
With export in IFC4RV, it remains 1 entity. (So, it's modelled in Revit as one thing, and it exports as one thing: that's OK I think).
Nice to see that now also a new IFC4-entity like IfcShadingDevice is supported.
At the moment it seems that the FZK viewer 4.9(Build 960) is doing a pretty good job in supporting IFC4RV, as well as BIM Vison 2.18.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
R2018.3 IFC4RV
Some more tests with IFC4RV-export.
Since BIM Vision and FZK Viewer are displaying the IFC4RV output out of Revit (almost) equally, I think it's fair to use these viewers as a sort of reference, bearing in mind that possibly the origin of some issues could be in these viewers too.
Based on a test of Generic Models with all the EntityClasses and PredefinedTypes:
1st test: with only the Entities that are valid in IFC2x3 (IfcBeam is left out, since IfcExportAs=IfcBeam is generating an error with IFC4RV)
it seems that the geometry of the text is missing of some EntityClasses (or at least they are not displayed in BIM Vision and FZK Viewer)
IfcCovering(Type)
IfcFooting(Type)
IfcPile(Type)
IfcRamp(Type)
IfcRoof(Type)
IfcSlab(Type)
IfcStair(Type)
IfcWall(Type)
2nd test: with Entities that were in IFC2x3, or only exportable as proxy (since it was a new IFC4 entity, like IfcShadingDevice), or was not exporting at all (like IfcTendon)
Result:
they are now indeed in IFC4RV exportable, but the geometry of the sample boxes seems to be missing
FZKViewer is displaying the text of IfcVibrationIsolator. That BIMVision isn't displaying it, is probably a BIMVision issue.
After all I really don't care about the text, since nobody will model a pile with text,
but since I made only use of 1 and the same family, I'm wondering why there are these differences for some EntityClasses, or is there any easy explanation that I've overlooked?
In the middle of this thread, it indeed jumped to a test with 18.4, and I concluded that there is probably a difference in the export options between my test, and the one of Angel. I assume that you and Angel are using the unmodified export options list of the mapping of Categories to IfcEntityClasses.
The issue can be narrowed down to the export of IfcBeam.
In fact it is the same issue as: https://sourceforge.net/p/ifcexporter/discussion/general/thread/d656bda9/
The other issue, is the one of the disclocated ceilings (IfcCovering.CEILING).
Regards,
Dirk
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Angel,
R2018.3 with exporter 18.3.2
I isolated 3 objects, which are generating an error while exporting as IFC4DTV (and not generating any output).
I attached the sample rvt, and the IFC2x3CV2 ifc (which is OK).
Any idea if there is something wrong with these objects?
Regards,
Dirk
Last edit: Dirk Van Rillaer 2018-04-26
We'll take a look. Note that we are not actively working on DTV at the moment, but instead focusing on RV export certification. We will pivot to DTV after that. Also note that DTV isn't even finalized, so this is all really Beta code (the next version of the exporter will likely explicitly state that).
Hi Angel,
Nice to know that RV has the focus.
I just retested the sample, and unfortunately also for IFC4RV it's giving the same error, and not generating any output.
Regards,
Dirk
OK, good - so that raises the priority :)
It's a little bit surprising to me, since mostly I got better results (or less export errors) with DTV than RV.
Probably some more IFC4RV issues.
Same family (with nested families) as generic model, but with different values for IfcExportAs.
with IfcExportAs = IfcBuildingElementProxy (and the different PredefinedTypes)
IFC2x3CV2: export OK
IFC4RV: export OK
with IfcExportAs = IfcBeam/IfcColumn/IfcPlate (and the different PredefinedTypes)
IFC2x3CV2: export OK
IFC4RV: export errors (no output)
Retested with R2019 and current-Github-exporter-version : issue fixed!
v.18.4.0: A little bit sad that Structural Framing is still generating errors while doing an export in IFC4RV, and causing no file output at all.
The sample at the start of this thread is still applicable.
In a real model this is for instance causing 610 export errors, which could be ignored, but even then no file is generated.
Not exporting the Structural Framing in that model results in a roof without any members ... so it seems that making the move to prescribe IFC4RV as deliverable is sadly enough still not a real option... or did I miss something?
Our IFC4RV work is still in progress - IFC4 stuff is still in Beta until we get through certification. We will definitely be using your file for our testing, though.
Hi Dirk, I just tried the first files with v18.4 and RV/DTV, and they exported for me. In RV, the placement looks a bit odd (but I am not sure if that's the viewer or the IFC file), but the 3 entities are there, and same with DTV. Which files are failing?
Hi Angel,
In the sample, R2018_FAM_20180426_selection_issue_ceilings_structural framing & stiffeners.rvt
it's only the object in the middle that's causing the error, the Structural Framing.
If both the Structural Framing and the Stiffener are exported, the error of the Structural Framing is also causing an error for the Stiffener (but as collateral damage or something like that).
Since your test was OK, there must be something I was missing.
Since I didn't make any use of the parameter IfcExportAs in the sample, it guessed that most likely there must be a difference in the Export mapping table.
So I narrowed down the problem to Structural Framing that is exported as IfcBeam.
In the real model, all the Structural Framing is making use of the parameter IfcExportAs. Some are intented to be exported as IfcMember, some as IfcBeam.
It seems that not the Structural Framing in general is causing a problem, but indeed only the ones with IfcExportAs=IfcBeam are causing the error and causing no output at all.
--
In consideration to move on to IFC4RV (or DTV) the basic condition is that all geometry is exported. So there is again hope that soon this condition is met!
About viewers: at this moment it seems that for instance BIM Vision is doing very well for IFC4RV. The other wellknown viewer is handling IFC4RV very badly.
But in the case of the real model, there are also other issues with the current IFC4RV output, causing BIM Vision to crash, so I need to investigate it deeper to isolate the possible problems.
Regards,
Dirk
Hi Angel,
Since you wrote about some discplacement, I can confirm it, ... but with the ceilings.
If I export the real model without the structural framing, I'm impressed with the result in FZK Viewer (until know, so before 18.4, there were a lot of missing walls with complex openings, but they now are exporting very well!). But all the IfcCovering.CEILINGs are discplaced. So there seems still something wrong with the ceilings. XBimXplorer on the other hand is showing only the ceilings (and nothing else) ??? It's indeed getting difficult to evaluate the output based on the results in the viewers, since none of them are certified. But in this case I've have the "feeling" that there is an issue in the output with the ceilings.
Regards,
Dirk
We are taking a deeper look now, so hopefully we can shed some light on this. As you mention, with no certified products, it is more difficult than usual to know what's right and what's wrong. I look forward to Revit getting through the RV certification process.
It would be very nice, or even Ab Fab, if at least the output is certified.
It will be a breakthrough, and it will force the viewers to do something (or not?).
I'm going to do further tests in the next days/weeks, also to discover all the improvements.
Luckely overnight the sadness is again replaced by a strong hope that soon "everything is gonna be alright".
IFC4RV
aside from the export error with Structural Framing as IfcBeam,
and aside from the discplacement of the IfcCovering.CEILINGs,
I noticed a slightly different behaviour in the generation of the amount of entities of IfcSlab.F'LOOR, but I think the new behaviour is OK.
It concerns floors with more than 1 boundary (in one floor).
With export in IFC2x3CV2, it breaks down in pieces, so each boundary will be a seperate IfcSlab.FLOOR
With export in IFC4RV, it remains 1 entity. (So, it's modelled in Revit as one thing, and it exports as one thing: that's OK I think).
Nice to see that now also a new IFC4-entity like IfcShadingDevice is supported.
At the moment it seems that the FZK viewer 4.9(Build 960) is doing a pretty good job in supporting IFC4RV, as well as BIM Vison 2.18.
R2018.3 IFC4RV
Some more tests with IFC4RV-export.
Since BIM Vision and FZK Viewer are displaying the IFC4RV output out of Revit (almost) equally, I think it's fair to use these viewers as a sort of reference, bearing in mind that possibly the origin of some issues could be in these viewers too.
Based on a test of Generic Models with all the EntityClasses and PredefinedTypes:
1st test: with only the Entities that are valid in IFC2x3 (IfcBeam is left out, since IfcExportAs=IfcBeam is generating an error with IFC4RV)
Result:
IFC2x3CV2: 1891 pieces
IFC4RV: 1875 pieces
it seems that the geometry of the text is missing of some EntityClasses (or at least they are not displayed in BIM Vision and FZK Viewer)
IfcCovering(Type)
IfcFooting(Type)
IfcPile(Type)
IfcRamp(Type)
IfcRoof(Type)
IfcSlab(Type)
IfcStair(Type)
IfcWall(Type)
2nd test: with Entities that were in IFC2x3, or only exportable as proxy (since it was a new IFC4 entity, like IfcShadingDevice), or was not exporting at all (like IfcTendon)
Result:
they are now indeed in IFC4RV exportable, but the geometry of the sample boxes seems to be missing
FZKViewer is displaying the text of IfcVibrationIsolator. That BIMVision isn't displaying it, is probably a BIMVision issue.
After all I really don't care about the text, since nobody will model a pile with text,
but since I made only use of 1 and the same family, I'm wondering why there are these differences for some EntityClasses, or is there any easy explanation that I've overlooked?
Issue of some missing geometry still exists: sample file will be placed on Github.
By the way with the newest exporter (18.4) the three elements in the first issue do export.
Hi Andy,
In the middle of this thread, it indeed jumped to a test with 18.4, and I concluded that there is probably a difference in the export options between my test, and the one of Angel. I assume that you and Angel are using the unmodified export options list of the mapping of Categories to IfcEntityClasses.
The issue can be narrowed down to the export of IfcBeam.
In fact it is the same issue as: https://sourceforge.net/p/ifcexporter/discussion/general/thread/d656bda9/
The other issue, is the one of the disclocated ceilings (IfcCovering.CEILING).
Regards,
Dirk
Finally also a simple sample of the dislocation of a ceiling in IFC4RV compared to the IFC2x3CV where the ceiling stays in place.
Got it, thanks. we'll check it out.
Retested the issue-sample (of the dislocation of a ceiling) with R2019 and current Github exporter version: issue seems to be fixed!