IfcSectionedSolidHorizontal

[aothms]

I hope this is a step in the right direction.

I've tested a bit on the following file, with makes the spec example a bit more interesting with various interpolations, and it seems to match my understanding of what it should look like. @civilx64 @RickBrice hope you can have a look, curious to hear your comments and questions.

sectioned-solid-horizontal-multiple.ifc.txt

[aothms]

I'm going to merge this in to start a build, but comments still welcome :)

[RickBrice]

Took me a little digging through the IFC to understand the image. There are 3 solids. One is along the gradient curve, one has a lateral offset of 50 at the end of the gradient curve, and one has a vertical offset at the mid-point. Yes?

I see lots of IfcLinearPlacement and IfcPointByDistanceExpression. Cool! That seems to be working.

@aothms Can you try this with an IfcOffsetCurveByDistances?

IfcSegmentedReferenceCurve isn't going to work yet. That's still a work in progress.

[aothms]

@aothms Can you try this with an IfcOffsetCurveByDistances?

sectioned-solid-horizontal-ocbd.ifc.txt

Seems to work! Awesome. (None of the other viewers I tried render something for this though...)

I didn't realize though we already have logic for this interpolation. I also didn't realize the conceptual overlap between SectionedSolidHorizontal and OffsetCurveByDistances. They both are a curve with a list of linearly placed offsets. The only difference is that the solid also defines an equal-cardinality list of profiles.

The code we wrote is a bit different. You have a really interesting approach of defining the offsets as another piecewise function and returning the composition of both. I just iterate over the curve domain, lookup the span I'm currently in, and then apply the offset by lerp'ing. The consequence of that is that I will probably never hit exactly the locations at which the profiles/offsets are defined. I assumed that's not a big problem. And would also be the case if I use your approach, because ultimately the spans are hidden at the call site. It also makes sense that our approaches are different, because you return a new piecewise function and I just use the evaluation to position the profiles. But good to be aware of the conceptual overlap maybe and something to revisit/harmonize later.

Took me a little digging through the IFC to understand the image. There are 3 solids. One is along the gradient curve, one has a lateral offset of 50 at the end of the gradient curve, and one has a vertical offset at the mid-point. Yes?

Yeah sorry, I was a bit in a rush. Yes for the offsets. Two of them also have a different end profile.

[RickBrice]

I also didn't realize the conceptual overlap between SectionedSolidHorizontal and OffsetCurveByDistances

Neither did I.

You have a really interesting approach

Interesting good or interesting bad - If you have an alternative, I'm open to making the implementation better.

How are you making the IFC files and displaying them in Blender? (sorry, still bit of novice). Being able to visualize a solid might help me understand cant and whether or not I'm doing it right.

[aothms]

Interesting good or interesting bad

Haha I don't know. I guess yours is computationally more efficient because you calculate the slope and multiplication is cheap. I'm lerping for every interpolated point. But maybe there is some overhead in your case for returning full matrices or std::function.

How are you making the IFC files and displaying them in Blender?

Mostly hand editing actually. If you have some files in mind that you want me to wrap a solid around I don't mind. I'm curious to have a look as well.

[RickBrice]

I've got a program that exports bridge superstructure models that uses IfcSectionedSolidHorizontal. I just don't what tools (IfcConvert maybe?) and what options to use to create something that can be opened and visualized in Blender.

[aothms]

IfcConvert v0.8 to convert to Collada .dae which can be imported easily in Blender.

IfcConvert.exe sectioned-solid-horizontal.ifc -yv sectioned-solid-horizontal.dae --use-element-guids

for the curve geometry:

IfcConvert.exe sectioned-solid-horizontal.ifc -yv sectioned-solid-horizontal-curve.dae --use-element-guids --plan

edit:

I've got a program that exports bridge superstructure models that uses IfcSectionedSolidHorizontal

I didn't know you were that far already. That's really cool!

[RickBrice]

Thanks - my IFC bridge models are pretty weak. I've got an IFCOS build going right now. As soon as it's done I'll generate a post a couple of models.

They are precast, prestressed concrete bridges and post-tensioned spliced precast bridges. Deck, girders, traffic barriers, and prestress reinforcement only.

[RickBrice]

Guess I'm not as far along as I thought - the beams, deck, and railings are coming out with decent geometry but their placement is a mess.

This file has a bunch of errors when running through IfcConvert

[Notice] [2024-03-18 14:08:31] exclude entities IfcOpeningElement IfcSpace
[Error] [2024-03-18 14:08:31] No operation defined for:
#608=IfcSectionedSolidHorizontal(#113,(#195,#236,#277,#318,#359,#400,#441,#482,#523,#564,#605),(#197,#238,#279,#320,#361,#402,#443,#484,#525,#566,#607))
[Error] [2024-03-18 14:08:31] Failed to convert:
#609=IfcShapeRepresentation(#119,'Body','AdvancedSweptSolid',(#608))
[Error] [2024-03-18 14:08:31] No operation defined for:
#609=IfcShapeRepresentation(#119,'Body','AdvancedSweptSolid',(#608))

I need to be way more efficient with the beam cross section as well.

I405-SR167 Flyover.ifc.txt

[aothms]

[Error] [2024-03-18 14:08:31] No operation defined for:
#608=IfcSectionedSolidHorizontal(#113,(#195,#236,#277,#318,#359,#400,#441,#482,#523,#564,#605),(#197,#238,#279,#320,#361,#402,#443,#484,#525,#566,#607))

Are you sure you pulled the latest changes? IfcSectionedSolidHorizontal is exactly the scope of this PR.

But yeah... we have some work todo.

[RickBrice]

Oh my - that's embarrassing :)

I've got your commits on v0.8 branch from 2/21 and 3/13-3/15. Fetching doesn't get any more commits.

[aothms]

I've got your commits on v0.8 branch from 2/21 and 3/13-3/15

That seems ok, but then you really shouldn't get an error about No operation defined for IfcSectionedSolidHorizontal

I also tried with IfcOpenBot@0d3c73d / https://s3.amazonaws.com/ifcopenshell-builds/IfcConvert-v0.8.0-0d3c73d-win64.zip and I don't get the error on the automated build either.

[RickBrice]

I'm really stuck here with bridge models using IfcSectionedSolidHorizontal. I re-build and ran the INSTALL project from visual studio. This seems to have updated IfcConvert so the previous error for No operation defined for IfcSectionedSolidHorizontal has gone away.

Using a fresh build of IfcConvert (also using the pre-built one) I get

Log:
[Notice] [2024-03-20 12:23:21] exclude entities IfcOpeningElement IfcSpace
[Error] [2024-03-20 12:23:21] Failed to convert:
#487=IfcShapeRepresentation(#88,'Body','AdvancedSweptSolid',(#486))
[Error] [2024-03-20 12:23:21] No operation defined for:
#487=IfcShapeRepresentation(#88,'Body','AdvancedSweptSolid',(#486))

That tells me I'm doing something wrong with the shape representation and representation contexts. Using your sectioned-solid-horizontal-multiple.ifc file as a guide, I updated my coding so the representation context, representation subcontext, and shape representations are the same.

Using IfcConvert without the --plan option, there are no errors and no dae file created. With the --plan option I get the 'No operation defined for' error and no geometry.

Any ideas?

The attached is a more simple model than before - one span, 5 beams, straight, flat road.

PGSuper1.ifc.txt

[RickBrice]

Is this an error in the IfcSectionedSolidHorizontal documentation?

The profile X axis is the direction of RefDirection from IfcAxis2PlacementLinear

If RefDirection is omitted in IfcAxis2PlacementLinear it defaults to the tangent of the curve. This would put the section profile x-axis along the curve making the sweep nonsensical.

Maybe it should be the profile x-axis is aligned with the placement x-axis defined by the cross product of Axis and RefDirection.

[aothms]

This is strange. For me that model fails on a null ObjectPlacement in the mapping of IfcProduct. And it's not an exception that can be caught. I've fixed it in here 4b32381

After that output looks like this on my end:

Is this an error in the IfcSectionedSolidHorizontal documentation?

IfcAxis2PlacementLinear:

RefDirection: The direction used to determine the direction of the local X Axis... If RefDirection is omitted, the direction is taken from the curve tangent at Location.

IfcSectionedSolidHorizontal:

The profile X axis is the direction of RefDirection from IfcAxis2PlacementLinear, and the profile Y axis is the direction of Axis.

To be honest I just randomly tried a couple of axis permutations until it looked well, but maybe I should have had a proper look.

At least linguistically it seems to make sense. X matches X. The other axis doesn't linear Z corresponds to profile Y.

My problem is that I don't understand linear placement I guess.

• What is the value of Axis/Z when null in the model?
• I find X the least sensible axis to align to curve tangent. In most conventions either Z (e.g opengl camera) or Y corresponds to the "forward" axis. Also in the name: "RefDirection" is a supplementary direction, but isn't in a curve the tangent the primary direction.

But this is probably something to bring up with the IF again..

[RickBrice]

For me that model fails on a null ObjectPlacement in the mapping of IfcProduct

I should have run my file through the validation service. It found that issue.

The bridge model is what I expected. Simple, but a step in the right direction.

The attached files are:

1. sectioned-solid-horizontal.ifc from the Ifc documentation, except that I changed the cross section shape so it is asymmetric.
2. sectioned-solid-horizontal_With_PlanOption_Output.txt - output from running IfcConvert with the --plan option
3. sectioned-solid-horizontal_With_PlanOption.dae - the Collada file - when imported in Blender there is no visible geometry
4. sectioned-solid-horizontal_Without_PlanOption_Output.txt - output from running IfcConvert without the --plan option
5. sectioned-solid-horizontal_Without_PlanOption.dae - the Collada file - when imported in Blender there is visible geometry

With the --plan option there are 'Failed to convert' with 'No operation defined for' IfcShapeRepresentation(#17,'Body','AdvancedSweptSolid',(#116)).

There is also a bunch of warnings about `No material and surface styles for' the IfcCompositeCurve, IfcGradientCurve, and IfcCurveSegment but I think this is expected.

Without the --plan option there is a bunch of errors for Failed to convert with No operation defined for IfcShapeRepresentation for 'Axis' and 'FootPrint' curves. I think this is probably expected too, but not sure.

Are there bugs here?

sectioned-solid-horizontal.ifc.txt
sectioned-solid-horizontal_With_PlanOption.dae.txt
sectioned-solid-horizontal_With_PlanOption_Output.txt
sectioned-solid-horizontal_Without_PlanOption.dae.txt
sectioned-solid-horizontal_Without_PlanOption_Output.txt

[RickBrice]

My problem is that I don't understand linear placement I guess.

My problem is that I don't understand placement in general I guess.

For sectioned-solid-horizontal.ifc file in the previous comment, I changed the shape of the cross section so the left side is really wide compared to the right side, when looking in the X-Y plane the section is defined in. I changed (-5,-1) to (-50,-1).

I expected the wide side of the cross section to be on the left in the IfcSectionedSolidHorizontal but it was on the right. After reviewing the documentation, this is expected.

The profile normal is derived from the associated IfcAxis2PlacementLinear, not necessarily the tangent of the Directrix

It seems that the profile X-axis maps to the linear placement Y-axis and the profile Y-axis maps to the linear placement Z-axis. Doing the right-hand rule cross product the profile normal is the profile Z-axis and is pointing out of the screen. For this axis to align with the linear placement X-axis the mirror image of the profile shape is projected along the curve.

This brings me to the conclusion that the documentation in IfcSectionedSolidHorizontal is not correct.

The profile X axis is the direction of RefDirection from IfcAxis2PlacementLinear

This should be the profile normal is the direction of RefDirection from IfcAxis2PlacementLinear.

There is still an open question in the IF about the default Axis and RefDirection buildingSMART/IFC4.x-IF#125 (comment). I'll ping the IF to see if there are any resolutions.

[RickBrice]

Here is that first bridge model I sent you. Can you see how it converts and renders in Blender?

I don't seem to get any geometry in Blender, but do in RDF and ODA.

I405-SR167 Flyover.ifc.txt

[aothms]

This should be the profile normal is the direction of RefDirection from IfcAxis2PlacementLinear.

I think that's a good way to put it, but strictly speaking the profile is 2d, so even I perfectly understand what you mean, maybe it needs to be augmented a bit to indicate that this normal is obtained when embedding the 2d profile in 3d space. I would also add another clarification indicating that RefDirection is the curve tangent.

---

I must say, I'm not getting more optimistic about the state of 4.3 support in software. But yeah, good news is compared to the rest, we, with 0 buget, are doing ok :)

BimVision. A bit wobly

ODA. Weird plates.

rdf.bg. Only the beams.

---

IfcOpenShell. Discontinuities in gradient curve.

For us the problem appears to be in the gradient curve evaluation. In order for that to show up I had to uncomment the footprint. For some reason it takes priority for visualization. Multiple representation and the selection of curve/surface types is still not ideal in v0.8 as you also observed in the logs.

If I comment out the footprint:

#147=IFCPRODUCTDEFINITIONSHAPE('Alignment Product Definition Shape',$,(/*#122,*/#123));

And then run

IfcConvert I405-SR167.Flyover.ifc -yvv I405-SR167.Flyover.dae --use-element-guids --plan --include attribute GlobalId 3rzI5aF7nFWABTp2u297Ph

I get the discontinuous gradient curve to display in Blender.

[RickBrice]

Thanks for creating those images for me. ODA version 24 did a better job than version 25 on the same file.

I don't get the same result for Blender. I just get an empty canvas with the default cube.
The steps I'm using are:

1. Remove FootPrint representation
2. Fire up Blender 3.6
3. File > Import > Collada
4. Select the attached dae file
5. Look around the scene... nothing but the default cube

It appears to be loading the alignment

I405-SR167.Flyover.dae.txt

I'll take a look at the gradient issues. It was correct before, but with all the guessing on implementation I probably broke something.

Edit - the gradient curve issue is bad IFC coding, not the IFCOS implementation.

[aothms]

When you select it from the "outliner" (your image), on the 3d view menu select Frame selected. Make sure that you have reasonable clipping planes in the view menu as well. Use the little arrow to get to that menu if you don't see it.

Edit - the gradient curve issue is bad IFC coding, not the IFCOS implementation.

But how come than the other viewers don't have the weird jumps?

[RickBrice]

Thanks - I thought I tried Frame Selected, but obviously not. I don't have any real experience with Blender. Obviously, there is still more work to do. Being able to visualize the geometry will help tremendously.

But how come than the other viewers don't have the weird jumps?

Maybe I'm not doing the IFC coding and the IFCOS implement correctly in general. There could be offsetting errors that end up looking ok when I dump the piecewise function points and plot them in Excel.