Activity for Dirk Van Rillaer
-
Dirk Van Rillaer posted a comment on discussion General Discussion
2020.2.0.48 is the version number of the Revit update 2020.2 and it refers to the out-of-the-box exporter, which is outdated (although its higher number). The exporter version 2020.1.0.1 is the current/latest exporter (unless you built your own solution than you can have a slightly more up-to-date version).
-
Hi Anno, To my surprise, it is indeed possible to use such a combination expression. I tried successfully the following notation as expression for a Wall/Door/Roof {$this("Base Constraint").("Name")+$this("Level").("Name")+$this("Base Level").("Name")} so in the same style all the other "leveltypes" could be added to this expression. Regards, Dirk
-
Hi Hans, As far as I know, the only way to get rid of the prefix, is by using an expression. In this case the expression would be: {$this("Base Constraint").("Name")} Regards, Dirk
-
Many thx for the script! I will give it a try.
-
Not that I know ... unfortunately. I suppose the only solution would be if something in the code of the exporter would be altered concerning the evaluation of empty fields. @angelvelezsosa: could you shine some light on this?
-
Hi Adrian, There is a difference between an empty field and an untouched empty field. Only the untouched ones are skipped by export. If you fill in a value for the parameter Reference Level / apply / delete value / apply, and then export it to IFC, you will notice that also the Reference Level parameter is exported. Regards, Dirk
-
Hi Milutin, You can assign the parameter IfcSpatialContainer as Instance parameter to any object. Suppose, you have a Revit Level with Name "Level 2", which is ticked as Building Story. You have to use the Revit level name as value (not the name of an override for IFC export, which is for instance "02"):. So, if you use IfcSpatialContainer = Level 2 it will be exported to the desired IfcBuildingStorey "02" Regards, Dirk
-
you're welcome!
-
Hi Martin, I tried your sample with 19.3.0.0 and indeed I get the same result as you. But ... I see that you ticked the option "Include Steel Elements": if you untick that option, both pairs of beams will be exported correctly. There are issues with that option "Include Steel Elements" : https://github.com/Autodesk/revit-ifc/issues/98
-
Hi Martin, I tried your sample with 19.3.0.0 and indeed I get the same result as you. But ... I see that you ticked the option "Include Steel Elements": if you untick that option, both pairs of beams will be exported correctly. There are issues with that option "Include Steel Elements" : https://github.com/Autodesk/revit-ifc/issues/98
-
Hi Martin, I tried your sample with 19.3.0.0 and indeed I get the same result as you. But ... I see that you ticked the option "Include Steel Elements": if you untick that option, both pairs of beams will be exported correctly. There are issues with that option "Include Steel Elements" : https://github.com/Autodesk/revit-ifc/issues/98
-
Can you try version 19.3.0.0? It is available at https://github.com/Autodesk/revit-ifc/releases/tag/IFC_v19.3.0.0
-
Hi Caroline, It looks to me that your picture exactly shows the correct and expected behavior of the IFC exporter. I assume the reference levels in your picture are the Revit levels where the parameter Building Story is ticked, and only the floor elements are modelled on those reference levels. Everything that is modelled on levels (aid/help levels, not being a Building Story level) that are located lower than the 'reference level' will drop down to the next Building Story below. Revit has no knowing...
-
Hi Martin, Probably you could post a little sample.rvt here at the forum. As I've done a little test with (2x) 2 beams (with and without using mitter), it seems OK, since both pairs are getting the same IfcSite elevation. Tested with R2019.2 and exporter version 19.3.0.0 for IFC2x3CV2.0 Regards, Dirk
-
Hi Caroline, It looks to me that your picture exactly shows the correct and expected behavior of the IFC exporter. I assume the reference levels in your picture are the Revit levels where the parameter Building Story is ticked, and only the floor elements are modelled on those reference levels. Everything that is modelled on levels (aid/help levels, not being a Building Story level) that are located lower than the 'reference level' will drop down to the next Building Story below. Revit has no knowing...
-
Probably same issue as https://github.com/Autodesk/revit-ifc/issues/82 Regards, Dirk
-
After all, it seems that there is unfortunately a possible issue with the geometrical description within the IFC model. FZK Viewer isn't showing some of the columns (that are involved with the steel connections). The IFC schema validator comes up with a bunch of issues. It seems to go well as long as the option of the 'steel elements' is unticked (but then - of course - you don't get the steel connections exported), when the option is ticked, it seems to trigger some issues (not only in IFC2x3CV2.0...
-
Just some feedback concerning the outcome: it looks like that it is an issue of the IFC viewer Tekla BIMSight, not showing some of the columns. The columns are present in the IFC file (so the IFC export is fine, at least at that point). Viewers, such as BIM Vision, BIMcollab ZOOM and Solibri Anywhere are displaying the columns. But there are some other issues regarding columns, beams and steel connections, which are already subject of other posted topics: - the missing Psets for Beams and Columns,...
-
I'm willing to take a look at the simple sample model if you send it by message.
-
My best guess is that you have to look to the slab within the container of the roof. I assume you are using Revit 2019 with Exporter version 19.2.0, and you export the model in MVD IFC2x3CV2.0, and you're using Solibri as IFC viewer. In that case: it all seems to work well (at least, it shoud be) The container Roof is indeed not getting the attribute LoadBearing, since it is the container. But the decomposition element(s), as being IfcSlab.ROOF (in Solibri also displayed as 'Roof'), gets the attribute...
-
issue is similar to https://github.com/Autodesk/revit-ifc/issues/12
-
Then the next guess is the Category2Class mapping: File > Export > Options > IFC Options check if the Steel Connections are not set on 'Not Exported'. A more efficient way (instead of guessing) would be if you post a simple rvt model sample with the issue.
-
It's worth installing the Revit IFC exporter @ https://apps.autodesk.com/RVT/en/Detail/Index?id=1763588736399554049&appLang=en&os=Win64 Tick the option 'include steel elements' and the steel connections will be exported. Regards, Dirk
-
Hi, Could it be an issue of the eveBIM viewer? When I load your 3 IFC models in 3 other IFC viewers (BIMcollab ZOOM / BIM Vision / Solibri), they all show the 3 fanions at the same z-location. Regards, Dirk
-
Hi, Could it be an issue of the eveBIM viewer? When I load your 3 IFC models in 3 other IFC viewers (BIMcollab ZOOM / BIM Vision / Solibri), they all show the 3 fanions at the same z-location. Regards, Dirk
-
Hi, Could it be an issue of the eveBIM viewer? When I load your 3 IFC models in 3 other IFC viewers (BIMcollab ZOOM / BIM Vision / Solibri), they all show the 3 fanions at the same z-location. Regards, Dirk
-
Hi Andy, this issue with sample is ported to Github as issue 99 Regards, Dirk
-
Hi Joao, The best thing you can do now, is to isolate a part of the model (with at least 2 windows: one that is correctly cutting through the walls and one that isn't). If you post that sample revit model here on the forum the developers probably will take a look at it. Regards, Dirk
-
Hi Joao, The best thing you can do now, is to isolate a part of the model (with at least 2 windows: one that is correctly cutting through the walls and one that isn't). If you post that sample model here on the forum the developers probably will take a look at it. Regards, Dirk
-
Hi Joao, In the beta version the version number is not adjusted. So if the beta installed correctly, you should try the export (and hopefully notice that the openings are fixed in your case). Regards, Dirk
-
Hi Joao, Did you already try the beta of the IFC-exporter @ https://github.com/Autodesk/revit-ifc/releases/tag/Beta5-v19.2.0 ? These kind of cuts through multiple walls should be fixed with the commit https://github.com/Autodesk/revit-ifc/commit/958482e2651a941b5a645913dd18afa147354939 Regards, Dirk
-
But in this case I suspect it is not a viewer issue. I will post (later on) this issue on Github.
-
What kind of viewers/applications do you use (that support the IFC4RV output of Revit)? In my experience it seems limited to BIM Vision / FZKViewer / BIMcollab ZOOM. If you look at the attached sample, you'll notice some difference. There is only one displaying the complete steel framing...
-
Sorry, the R2018-IFC-exporter is another story. As I notice how much effort is spent by the developers on the improvements that are made for IFC4RV in the R2019-IFC-exporter (as you could see on Github), I could imagine that it is not evident that all these improvements will be ported to an update for the R2018-IFC-exporter. Personally, I would not count on any update for the R2018-IFC-exporter (but that is only my opinion, it is not up to me to answer this kind of questions), but if IFC4RV export...
-
For Revit 2019 you could try the beta of the IFC-exporter @ https://github.com/Autodesk/revit-ifc/releases : seems to create nicely the IfcSystems for IFC4RV1.2 (see attached screenshot) Regards, Dirk
-
Hi Eddy, The opening-issue for IFC2x3 is fixed with commit https://github.com/Autodesk/revit-ifc/commit/958482e2651a941b5a645913dd18afa147354939 I tested it on several model samples, and for instance also in the D-A-CH Golden Nugget sample model the openings of the windows are back again. Regards, Dirk
-
crossover reference: https://github.com/Autodesk/revit-ifc/issues/78 - issue of the empty IfcGUID is fixed with the update to R2019.2 - it is now also possible to overwrite each IfcGUID
-
Hi Stephen, I'm afraid I can't answer that question because I don't have any programming skills, and the code on Github is mainly focussed on the IFC exporter for R2019 (which has BTW a lot of improvements, not only for IFC4RV but also for IFC2x3CV2.0). (Of course, in theory everything is possible.) Regards, Dirk
-
Even more thx! With this commit, combined with the 'Extract IFC Ids' tool in your Xmas present, it is now possible to reveal the hidden IfcGUIDs of copied elements. Although it would be nice that the reveal action is automatically done by the exporter itself, at least this tool is now already solving the problem!
-
Thx Jon for this nice Xmas present! It is a very handy tool to make the GUIDs of these 3 entities (IfcProject/IfcSite/IfcBuilding) consistent between the federated models (aspectmodels), without the fuss of the workaround as I described. Regards, Dirk
-
Yes, there is a beta version of the IFC exporter (for R2019): it is available at https://github.com/Autodesk/revit-ifc/releases/tag/IFC4RV-beta-v0.6.2 To be sure, I checked it, and it is also fixed/working for IFC2x3CV2.0
-
Yes, there is a beta version of the IFC exporter (for R2019): it is available at https://github.com/Autodesk/revit-ifc/releases/tag/IFC4RV-beta-v0.6.2 To be sure I checked it, and it is also working for IFC2x3CV2.0
-
Yes, there is a beta version of the IFC exporter (for R2019): it is available at https://github.com/Autodesk/revit-ifc/releases/tag/IFC4RV-beta-v0.6.2 To be sure if I checked it, and it is also working for IFC2x3CV2.0
-
Probably similar to https://github.com/Autodesk/revit-ifc/issues/30 ?
-
It's not yet fixed, but there is a workaround, since Wawan Solihin recently added the functionality to override the level. Regards, Dirk
-
I think a lot of people would already be happy if at least Wall Sweeps are exportable as IfcWall, Slab Edges as IfcSlab and Roof Fascias and Roof Gutter as IfcRoof.
-
Tested with R2019.1 exporter 19.1 (regular version): same issue as 18.4 exporter current-Github-Master-version: (most) issues are fixed! fixed: -The MEP Fabrication Parts are now also exported in IFC4RV. -The hangers are exportable as IfcDiscreteAccessory (or IfcMechanicalFastener) (still) issue: The insulation/liners are not exportable as IfcCovering. The geometry of the insulation is not exported as one tries to export them as IfcCovering (making use of the export mapping file). The export is fine...
-
@WawanSolihin & Angel: Nice! Commit https://github.com/Autodesk/revit-ifc/commit/be8b42851d89538bcd496e8d792f69e0f9b8dcdd fixed the issue. Tested with R2019.1 for IFC2x3CV2 and IFC4RV1. Regards, Dirk
-
Retested it with R2019.1 with regular 19.1 exporter and with current-Github-IFC4RV-exporter-version IFC4RV1 A) 19.1 exporter (regular version): same issue as with R2018 and 18.4 (as expected, since the code should be similar) A.1) IFC export options: Stairs mapped 2 IfcBuildingElementProxy -> doublure of StairFlight and supports: issue A.2) IFC export options: Stairs mapped 2 IfcStair -> correctly exported with 1 x IfcStairFlight (Run), 2 x IfcMember (Supports/Stringers), 2 x IfcRailing: export OK!...
-
Hi Andy, I retested it with R2018 (18.4) and R2019 (19.1) for IFC2x3CV2 and IFC4RV1: the mapping is indeed fixed! I discovered an issue in my mapping file. While the custom mapping file allows multiple mappings to the same parameter (where the first match is exported), this isn't allowed (anymore?) in the mapping file for common parameters. Regards, Dirk
-
Issue of some missing geometry still exists: sample file will be placed on Github.
-
Retested with R2019 and current-Github-exporter-version : issue fixed!
-
Retested the issue-sample (of the dislocation of a ceiling) with R2019 and current Github exporter version: issue seems to be fixed!
-
Retested the sample, as well as a real model with this issue, with R2019 and current Github exporter version: issue seems to be fixed! (I didn't figure out which commit is contributing in the fix of this issue)
-
Probably I didn't formulate my sentence correctly, because that was indeed what I noticed, and I just wanted to compliment that you already commented it very well.
-
Thx! Indeed, the IFC4RV-export generates again IfcSystems (for Duct and Piping Systems). (Tested with R2019 and the current exporter-Master-code on Github) For future reference it is nice to notice that these changes concerning port connection are commented in the code.
-
Thx! 2 additional questions: 1) Is it more handy to keep posting issues on Sourceforge, or is it better to post new issues on Github? Since I recently migrated to R2019, I will have to do some re-testing I suppose. 2) Actually this is more a kind of request: would it be possible to consider to introduce IfcBuildingSystem and IfcDistributionSystem? Regards, Dirk
-
As I wrote above << Especially for Project/Site/Building/BuildingStorey it would be nice to be able to manually override it >> Actually I discovered that for IfcProject, IfcSite and IfcBuilding it is indeed possible to choose your own GlobalID, which you can easily use in all the aspectmodels. Before you do any IFC-export with the option "Store the IFC GUID in an element parameter after export"), add the 3 following parameters in the group of IFC Parameters, and give it a valid bogus GlobalId. IfcProject...
-
Intermediate test: based on: https://github.com/Autodesk/revit-ifc/commit/1e10b35ee00c994336b311fff3bc48a41aeaf271 : Various fixes for PreDefinedTypes tested with R19.1.current-IFC4RV-branche-version issue: https://sourceforge.net/p/ifcexporter/discussion/general/thread/b6a9156b/#cc0a - IfcDoor (PredefinedType on 11th position): all PredefinedTypes are translated to DOOR not yet fixed - IfcWindow (on 11th position): all PredefinedTypes are translated to WINDOW not yet fixed - IfcBuildingElementProxy:...
-
Intermediate test: based on: https://github.com/Autodesk/revit-ifc/commit/1e10b35ee00c994336b311fff3bc48a41aeaf271 : Various fixes for PreDefinedTypes tested with R19.1.current-IFC4RV-branche-version issue: https://sourceforge.net/p/ifcexporter/discussion/general/thread/b6a9156b/#cc0a IfcDoor (PredefinedType on 11th position): all PredefinedTypes are translated to DOOR not yet fixed IfcWindow (on 11th position): all PredefinedTypes are translated to WINDOW not yet fixed IfcBuildingElementProxy: all...
-
Making use of the sample of Eddy: screenshot of the changing GlobalId's of the IfcWindows. Tested with R19.1.current-IFC4RVcert.-branche
-
Hi Eddy, I can only fully agree with the content of your message. We shouldn't be busy anymore by worrying about the issues of the export, or inventing all kind of workarounds, so that all the time could be spent in the real challenge: getting better buildings, making processes more effiently, doing smart stuff, getting focus back on our real jobs, by USING the IFC-models. It's amazing how much time is lost now: if you just take in mind the time you spent on this kind of issues, and you add the time...
-
Hi Eddy, Ignore my question above. I've got it working. It's nice to be able to make use of an intermediate exporter with fixed issues (and to follow up the bunch of issues that are unfortunately not yet fixed). Regards, Dirk
-
Hi Eddy, Renaming the props.template(s) and adjusting the paths, is working well. But in the Solutions Explorer, there seems stil to be a problem with the References of Revit.IFC.export. I don't have a clue how to get this corrected. Regards, Dirk
-
Hi Eddy, Thx! I'll try if I get it working (or as a good literal translation: if can make chocolate out of it :-) ) Regards, Dirk
-
Hi Eddy, Do you have a quickstart on how to compile the code on github to an installable plugin? It would be nice to be able to evaluate intermediate fixes and improvements. Regards, Dirk
-
It seems only to be an issue in IFC4RV. Geometry is exporting fine in IFC4DTV. But the issue of the mapping of the Lining and the Insulation is in IFC4DTV the same as described above for IFC2x3CV.
-
Hi Angel, Maybe you could pass that team also that the hangers are only exportable as IfcBuildingElementProxy. For IFC2x3 it would nice to have them as IfcDiscreteAccessory(Type). Also the Insulation and Lining is only exportable as IfcDuctSegment, IfcPipeSegment or IfcBuildingElementProxy, instead of IfcCovering. Trying to export them as IfcCovering they even are not exported at all. Having them as IfcCovering would be consistent with the 'regular' Revit duct/pipe lining and insulation (which are...
-
R2018.3 18.4.0 Seems that the MEP Fabrication Parts (Ductwork, Pipework, Hangers and Ladders) are only exported in IFC2x3, not yet in IFC4RV...
-
R2018.3 18.4.0 Seems that the MEP Fabrication Parts (Ductwork, Pipework, Hangers and Ladders) are only exported in IFC2x3, not yet in IFC4RV...
-
R2018.3 18.4.0 IFC4RV Arrived at the letter "D", the Duct Systems are not exported as IfcSystem in IFC4RV. Alphabetically still a long way to go till "P", but propably also the Piping Systems will suffer from the same issue. Attached an export in IFC2x3CV2 with IfcSystem(s), and an export in IFC4RV with the missing IfcSystem(s) (even with Notepad search) MDV: IfcSystem seems to be part of IFC4RV http://www.buildingsmart-tech.org/ifc/review/IFC4Add2/ifc4-add2-rv/html/schema/ifcproductextension/le...
-
R2018.3 18.4.0 IFC4RV Arrived at the letter "D", the Duct Systems are not exported as IfcSystem in IFC4RV. Alphabetically still a long way to go till "P", but propably also the Piping Systems will suffer from the same issue. Attached an export in IFC2x3CV2 with IfcSystem(s), and an export in IFC4RV with the missing IfcSystem(s) (even with Notepad search) MDV: IfcSystem seems to be part of IFC4RV http://www.buildingsmart-tech.org/ifc/review/IFC4Add2/ifc4-add2-rv/html/schema/ifcproductextension/le...
-
R2018.3 18.4.0 A little bit odd: basic cube, simple extrusion, size 1m x 1m x 1m, modelled as Loadable Family (Generic Model), and as Model In-Place (Generic Model). The area values that are exported to IFC are different for both cubes. I would expect that the surface area is exported, which would be 6 m2 (as the FZK Viewer is independently calculating it correctly). The Model In-Place is displaying in the Revit Pset "Dimensions": Area = 1 m2 (probably the footprint) The Loadable Family is displaying...
-
R2018.3 18.4.0 A little bit odd: basic cube, simple extrusion, size 1m x 1m x 1m, modelled as Loadable Family (Generic Model), and as Model In-Place (Generic Model). The area values that are exported to IFC are different for both cubes. I would expect that the surface area is exported, which would be 6 m2 (as the FZK Viewer is independently calculating it correctly). The Model In-Place is displaying in the Revit Pset "Dimensions": Area = 1 m2 (probably the footprint) The Loadable Family is displaying...
-
Ahum, actually the above tested results were only based on the use of IfcExportAs on a Generic Model. It seems that the use of the PredefinedTypes in the mapping table (Export Options) is broken. They seem to result in "NOTDEFINED". See attached image.
-
Probably not really an exporter issue, but rather a historically Revit-evergreen-issue. When Revit is regenerating the export options mapping table, it will list the non existing EntityClass "IfcReinforcementMesh". Probably an idea to get it once corrected into "IfcReinforcingMesh"?
-
Probably not really an exporter issue, but rather a historically Revit-evergreen-issue. When Revit is regenerating the export options mapping table, it will list the non existing EntityClass "IfcReinforcementMesh". Probably an idea to get it once corrected into "IfcReinforcingMesh"?
-
Just one for almost the start of the new week. R2018.3 18.4.0 IFC2x3CV2 & IFC4RV With a mapping of all Revit Categories to IfcBuildingElementProxy (in the Export Options), there seems to arise a conflict with the hardcoded mapping and the geometry creation. The Stair Run is translated to 2 entities: IfcRampFlight as well as IfcBuildingElementProxy. The Stair Stringer is (of course 2 times) also translated to 2 entities: IfcMember and IfcBuildingElementProxy. A little bit too much geometry I thin...
-
Just one for almost the start of the new week. R2018.3 18.4.0 IFC2x3CV2 & IFC4RV With a mapping of all Revit Categories to IfcBuildingElementProxy (in the Export Options), there seems to arise a conflict with the hardcoded mapping and the geometry creation. The Stair Run is translated to 2 entities: IfcRampFlight as well as IfcBuildingElementProxy. The Stair Stringer is (of course 2 times) also translated to 2 entities: IfcMember and IfcBuildingElementProxy. A little bit too much geometry I thin...
-
R2018.3 18.4.0 Just one for the weekend :-) Unfortunately another issue concerning basic definition attribute related stuff. Next to the issue that not all PredefinedTypes are currently correctly exported, there is also an issue in particular with the correct use of PredefinedType = USERDEFINED. At the moment the exporter allows that there is not a value set as OjectType (for the EntityClass) or as ElementType (for the TypeClass): in other terms, the exporter is now allowing an output with "$", which...
-
R2018.3 18.4.0 Just one for the weekend :-) Unfortunately another issue concerning basic definition attribute related stuff. Next to the issue that not all PredefinedTypes are currently correctly exported, there is also an issue in particular with the correct use of PredefinedType = USERDEFINED. At the moment the exporter allows that there is not a value set as OjectType (for the EntityClass) or as ElementType (for the TypeClass): in other terms, the exporter is now allowing an output with "$", which...
-
Hope this is of any help for testing purposes. Since the exporter v18.4 is supporting and exporting all EntityClasses of IfcElement and IfcSpatialElement, I isolated just the few with an issue. "Part1.ifc" is IFC4RV. Although not all PredefinedTypes were correctly exported, I manually corrected them with Notedpad: so this "Part1" is more intended for testing a Viewer (such as BIM Vision, which is in the current beta version also supporting them all!). But I also attached "Part1_ori.ifc": with the...
-
Hope this is of any help for testing purposes. Since the exporter v18.4 is supporting and exporting all EntityClasses of IfcElement and IfcSpatialElement, I isolated just the few with an issue. "Part1.ifc" is IFC4RV. Although not all PredefinedTypes were correctly exported, I manually corrected them with Notedpad: so this "Part1" is more intended for testing a Viewer (such as BIM Vision, which is in the current beta version also supporting them all!). But I also attached "Part1_ori.ifc": with the...
-
R2018.3 18.4.0 IFC2x3CV2 For testing purposes: I did my best to get it messed up, but luckely the exporter is doing the correct expected behaviour (as far as I tested). Instance > Type Project Parameter (on Categories) > Parameter within Family So, if you have the IFCExportAs(=IfcFurniture) as Type parameter within the Loadable Family (f.i. Generic Model), and the IFCExportAs as Instance parameter in the Project Parameters on the Category Generic Models, and for a particual occurence the value is...
-
I think the instance will override the type parameter, but I should test it (because I also have a vague memory that "the strongest" was depending on which parameter was added at first: it is indeed also a thingy on my todo-list). I don't do production work myself, I only try to figure out what should work best (and to really test it also). So I agree with you that in most cases its making more sense to have the IfcExportAs parameter as Type parameter, so that you only have to use the Instance parameter...
-
It is possible to have both parameters as Instance and as Type parameter, but you have to edit the shared parameter text file to make the magic happening. So you will have the choice to add the parameter as Instance or as Type parameter for different categories. See attached example.
-
Hi Jon, Probably I have too many blond questions about the "how to build" process, that it is better that I patiently wait until the notes are written (as now is mentionned on GitHub at the openingspage): "We are in the process of greatly simplifying the build progress. We will add notes shortly once this work is complete." The tips on the Sourceforge-page are a little bit to cryptic for me to get a fast start: https://sourceforge.net/p/ifcexporter/wiki/Development%20Environment%20Tips/ I referred...
-
I think some people will have the preference that also 2018 is moving to GitHub for making code contributions, since R2018 is still the currently used version for production. They are mostly only switching to the next version after the 2nd service release. And if I understand correctly also compiling the code is gonna made easier (topic of Emanuele?), so maybe it could help in managing the repeated question "when is the next version available", if each of us can compile it at anytime with the improvements...
-
I think some people will have the preference that also 2018 is moving to GitHub for making code contributions, since R2018 is still the currently used version for production. They are mostly only switching to the next version after the 2nd service release. And if I understand correctly also compiling the code is gonna made easier (topic of Emanuele?), so maybe it could help in managing the repeated question "when is the next version available", if each of us can compile it at anytime with the improvements...
-
Is the code of 19.1 similar to 18.4 (concerning issues with 18.4)?
-
R2018.3 18.4.0 IFC4RV Would be nice if Roads would be exportable with the appropriate EntityClass IfcCivilElement. They are now only exportable as IfcBuildingElementProxy or IfcSlab (with the use of Export Options or with the parameter IfcExportAs) Wondering if this fixable with the exporter or is this something hardcoded in Revit or Site Designer? Also wondering if there is still hope (after so many years) if Wall Sweeps / Slab Edges / Fascias would be exportable, as IfcWall / IfcSlab / IfcRoof...
-
R2018.3 18.4.0 IFC4RV Would be nice if Roads would be exportable with the appropriate EntityClass IfcCivilElement. They are now only exportable as IfcBuildingElementProxy or IfcSlab (with the use of Export Options or with the parameter IfcExportAs) Wondering if this fixable with the exporter or is this something hardcoded in Revit or Site Designer? Also wondering if there is still hope (after so many years) if Wall Sweeps / Slab Edges / Fascias would be exportable, as IfcWall / IfcSlab / IfcRoof...
-
R2018.3 18.4.0 IFC4RV1 (but also IFC2x3CV2) any idea why two identical ramps are differently exported? They are in IFC exported as: 1) container IfcRamp containing an IfcRamp 2) container IfcRamp containing an IfcRampFlight The Export Options are on purpose all on "IfcBuildingElementProxy". The export as IfcRamp of this System Family is hardcoded. No "IfcExportAs" is used. (BTW it is not making any difference if the Category and all subcategories are set on IfcRamp in the Export Options Panel)
-
R2018.3 18.4.0 IFC4RV1 (but also IFC2x3CV2) any idea why two identical ramps are differently exported? They are in IFC exported as: 1) container IfcRamp containing an IfcRamp 2) container IfcRamp containing an IfcRampFlight The Export Options are on purpose all on "IfcBuildingElementProxy". The export as IfcRamp of this System Family is hardcoded. No "IfcExportAs" is used. (BTW it is not making any difference if the Category and all subcategories are set on IfcRamp in the Export Options Panel)
-
R2018.3 18.4.0 IFC4RV1 (but also IFC2x3CV2) any idea why two identical ramps are differently exported? They are in IFC exported as: 1) container IfcRamp containing an IfcRamp 2) container IfcRamp containing an IfcRampFlight The Export Options are on purpose all on "IfcBuildingElementProxy". The export as IfcRamp of this System Family is hardcoded. No "IfcExportAs" is used. (BTW it is not making any difference if the Category and all subcategories are set on IfcRamp in the Export Options Panel)
-
As far as I notice Wall Sweeps, Slab Edges, Roof Fascias are still only exportable as IfcBuildingElementProxy (in whatever IFC version). Is there a solution to get them exported as something other than a proxy?
-
As for as I notice Wall Sweeps, Slab Edges, Roof Fascias are still only exportable as IfcBuildingElementProxy (in whatever IFC version). Is there a solution to get them exported as something other than a proxy?
-
R2018.3 18.4.0 some more findings concerning location and levelassociation of some objects. IFC2x3CV: - ModelText location : OK - Assembly (container) BuildingStorey: wrong level (associated with lowest level -1, while it should be 00) - Assembly (decomposed elements) BuildingStorey: wrong level (all elements are associated with lowest level -1, while it should be 00 for lowest block and 01 for other block on top of it) - Parts location: not OK ("out of the box" location) IFC4RV: - ModelText location...
-
R2018.3 18.4.0 some more findings concerning location and levelassociation of some objects. IFC2x3CV: - ModelText location : OK - Assembly (container) BuildingStorey: wrong level (associated with lowest level -1, while it should be 00) - Assembly (decomposed elements) BuildingStorey: wrong level (all elements are associated with lowest level -1, while it should be 00 for lowest block and 01 for other block on top of it) - Parts location: not OK ("out of the box" location) IFC4RV: - ModelText location...
-
Finally also a simple sample of the dislocation of a ceiling in IFC4RV compared to the IFC2x3CV where the ceiling stays in place.
1 >