I would like to sweep a beam having a cross-section along a non-circular curve using the
IFCFIXEDREFERENCESWEPTAREASOLID representation.
I tried opening the IFC, from the Grasshopper example ‘Curved beam fixed reference’, with Viewers that support IFC4 (i.e. Tekla BIMSight and Constructivity). However the model could not be shown. Does this example work on any other viewer?
Hi Dawit,
Thanks for posting, I might suggest you also consider posting a similar question to this forum
There’s two obvious reasons the resulting file might be problematic in other applications.
What makes this hard for users is that most implementations “swallow” warnings and errors providing no feedback when a problem is encountered. I believe certification should test this, but note that I don’t believe viewers are certified (particularly if they are free).
Claiming IFC4 support (or support of any IFC release) is subject to particular model view definitions (subsets of IFC mapping to use case such as model reference for coordination).
Nearly every implementation for IFC2x3 was for coordination (which only requires primitive shape representations), and most now claiming support of IFC4 haven’t really advanced from the concepts in IFC2x3, they just recognize them with any format changes.
You can round trip the file into Rhino, you can use the Geometry Gym Revit Ifc importer to test. I haven’t found any external viewers that recognize this yet though.
Sample files are attached if anyone else wants to try.
Look forward to discussing further,
Jon
190220 beam fixed reference.zip (19.2 KB)
Thanks a lot Jon.
I can now view the curved beam by round triping the exported file back into Rhino. This will suffice atleast as an initial reference.
It is actually possible to represent a curved beam in IFC2x3 by dividing it into small straight extrusions, which most viewers support, but sweeping using the Directrix curve in IFC4 is a more accurate and efficient one.
I understand the problem that most of the receiving applications might not be certified to support the IFC schemas, and hence the need to look for more reliable references arose.
I will return to the discussions in case of further issues.
Cheers,
Dawit
Hallo Jon,
The example you provided above has a curve defined by a spline, which works fine when imported.
I have tried importing a semicircle defined by points through IFCPOLYLINE, but using the same representation. For the reason I dont know, half of the curve could not be properly visible in Rhino (screenshot attached). I am assuming the IFC file (attached) is ok, since the remaining half is correctly rendered. Could it be anything to fix outside the file?
orientation_beam_4_5.zip (2.2 KB)
Thanks for posting. We found an issue with the sweep orientation vector for this data, and we’ve implemented a fix.
Please update to the latest ggRhinoIFC plugin on the downloads page at www.geometrygym.com
Let me know if you still have problems or any suggestions for improvement.
Cheers,
Jon
It works now, Thanks!
Attached is another similar problem, where the FixedReference is set to (0,1,1) and part of the swept object could not be displayed. It works for (0,1,0) & (0,0,1). Could this also be fixed? orientation_beam_4_6.zip (2.2 KB)
Hi Dawit,
Having studied your second sample, I revisited your first and actually think my adjustment wasn’t right.
Here’s some explanation of the fixed reference solid, http://www.buildingsmart-tech.org/ifc/IFC4/Add2TC1/html/link/ifcfixedreferencesweptareasolid.htm
Note that the direction vector is constant the entire duration of the sweep. To achieve a prismatic solid with constant cross section as you indicate from SOFiSTik, then the reference direction should be perpendicular to the sweep path. So in both cases, you should actually nominate a Z (or -Z) direction for the orientation direction, and then nominate a relative rotated cross section by either rotating the profile definition curve, or transforming it using a derived profile. http://www.buildingsmart-tech.org/ifc/IFC4/Add2TC1/html/link/ifcderivedprofiledef.htm
Let me know if this makes sense or not.
Cheers,
Jon
If my understanding is correct, the option FixedReference is there so that one can rotate the Directrix about its longitudinal axis, and to align the SweptArea’s x-axis to it. In this case one can conveniently reference the same cross section (SweptArea) to multiple differently oriented curves. Modifying the orientation of the SweptArea just because the referring curve is rotated, as you suggested, would be a work around but would also mean creating an extra cross section to each curve.
Referring both models in the picture below, the FixedReference (0,1,0) is constantly perpendicular to the Directrix curve and results in the solid at top. That of (0,0,1) is also perpendicular and gives the one in the middle. If the above two are perpendicular, (0,1,1) must also be perpendicular, and should result in a solid at the bottom. All axes have a ‘LocalOrigin’.
On a another note:
The above coordinates of the FixedReference imply that ggRhinoIFC lays the ‘SweptArea’ on the y-z plane of the ‘object coordinate system’ and x-axis corresponds to the normal or ‘Axis3’ (hence it is 0 in all three cases). However, in the ‘EXAMPLE’ note of the linked explanation, it is stated that ‘Axis3’ is the z-axis or normal and ‘Axis1’ is the x-axis (FixedReference) which aligns with the local x-axis of the SweptArea. You might want to check this too.
The only problem here is the incomplete sweep of shown in the third picture of the first model, which is already correctly started.
Looking forward for your opnion on this.
Thanks,
Dawit
