IfcPointByDistanceExpression length along curve miscalculated

[CBenghi]

Hello @andyward, @Ibrahim5aad,

I'm attaching a file that demonstrates a problematic behaviour with IFCPOINTBYDISTANCEEXPRESSION placement.

There are four IFCGRADIENTCURVEs in this demo model.
One of them (the roundabout in the center) is built out of two ifcCircle segments (see label 132), the others are a mix of ifcLine, ifcClothoid, and ifcCircle.

I have placed light poles at regular distance along them to help demonstrate.

When computing IfcPointByDistanceExpression, the length is computed as a parameter (radians) for the roundabout, but it's correctly interpreted as a distance (meters) for the others, even though they contain circle segments.

inconsistentLengthTreatment.zip

I've investigated the problem a bit, but I'm not sure how to intervene in the code.
I'd be happy to to prepare a PR once we agree on the approach to take.

[Ibrahim5aad]

Thanks @CBenghi, I'll take a look into it and let you know my opinion on it.

[CBenghi]

Thanks @Ibrahim5aad, just a few pointers.

I think that we are using a occt primitive that considers U as a radian, but we need to create an Curve2D that takes a length parameter for D0() and converts it to radians (similar to Geom2d_LineWithMagnitude)

XbimGeometry/Xbim.Geometry.Engine/Factories/Unmanaged/NCurveFactory.cpp

Lines 711 to 728 in bd0f77c

	Handle(Geom2d_TrimmedCurve) NCurveFactory::BuildTrimmedCurve2d(const Handle(Geom2d_Curve)& basisCurve, double u1, double u2, bool sense)
	{
	try
	{
	Handle(Geom2d_Circle) circle = Handle(Geom2d_Circle)::DownCast(basisCurve);
	if (!circle.IsNull())
	{
	if (!sense)
	{
	double u = u1;
	u1 = u2;
	u2 = u;
	}
	GCE2d_MakeArcOfCircle arcMaker(circle->Circ2d(), u1, u2, sense);
	if (!arcMaker.IsDone())
	Standard_Failure::Raise("Could not build arc segment from circle");
	return arcMaker.Value();

Also, we are changing the start and finish parameters to radians in

XbimGeometry/Xbim.Geometry.Engine/Factories/CurveFactory.cpp

Lines 1888 to 1896 in bd0f77c

	if (curve->IsPeriodic())
	{
	IIfcCircle^ circle = dynamic_cast<IIfcCircle^>(segment->ParentCurve);
	IIfcEllipse^ ellipse = dynamic_cast<IIfcEllipse^>(segment->ParentCurve);
	if (circle != nullptr) {
	double r = circle->Radius;
	startParam = startParam / r;
	endParam = endParam / r;
	}

but for coherence with the code in NCurveFactory, perhaps using a ConvertIfcTrimParameter method that divides back and forth by the radius would be ok.

[Ibrahim5aad]

Hello @CBenghi,

I took a look, and all the circle segments of the gradient curve instances in the file are handled the same way, so it can't be that some of them are built correctly and some are built incorrectly.

We convert the curve parameterization to radians for periodic curves like circles because we use OCCT to trim the curve to get the segment defined by the parameters, and OCCT uses normalized angular parameterization for such curves. But after the overall curve is approximated to a B-spline, these local segment parameter spaces are no longer in use, in favor of the spline parameterization.

I was trying to intuit my way through the data itself. The composite curve specifies two circle segments, each with the same radius but placed in opposite directions. Looking at the numbers:

The radius of these circles is 23.4, which gives a circumference of 147,
and for a segment of 73.5, that's half of the circle.

So we have two half circles placed opposite to one another → a full circle, as I can see in the screenshot.

Please correct me if I'm wrong.

[CBenghi]

Yes, that's right. Two half circles.
If you follow in debug you see they get trimmed in two arcs.

[Ibrahim5aad]

Okay, I see the issue now, I was a bit confused as I thought it is an issue in trimming the curve segments (circles). It is not.

It is a problem (at least in how we use it) in the parameterization of the bSpline representation of the horizontal projection of the gradient (the composite curve) when all its segements are periodic curves (at least this is how it looks, but not 100% sure). It somehow didn't remap the arc length to the natural parameter space of the curve, and kept the angular params of the two half circles (-π to π).

This method:

XbimGeometry/Xbim.Geometry.Engine/Factories/CurveFactory.cpp

Lines 1564 to 1566 in bd0f77c

	Handle(Geom2d_BSplineCurve) bSpline = EXEC_NATIVE->BuildCompositeCurve2d(segments, ModelGeometryService->OneMeter);

I guess one of the solutions is to resample the conic curves like we do with the polynomial and spiral:

XbimGeometry/Xbim.Geometry.Engine/Factories/Unmanaged/NCurveFactory.cpp

Lines 284 to 304 in bd0f77c

	if (polynomial) {
	// Approximate the curve
	Standard_Real firstParam = curve->FirstParameter();
	Standard_Real lastParam = curve->LastParameter();
	int numPoints = std::max(Geom2d_Spiral::IntegrationSteps, 1000);
	TColgp_Array1OfPnt2d points(1, numPoints);
	for (Standard_Integer i = 1; i <= numPoints; ++i) {
	Standard_Real U = firstParam + (lastParam - firstParam) * (i - 1) / (numPoints - 1);
	gp_Pnt2d P;
	curve->D0(U, P);
	points.SetValue(i, P);
	}
	Geom2dAPI_PointsToBSpline curveBuilder(points, 8, 8, GeomAbs_CN);
	Handle(Geom2d_BSplineCurve) approximate = curveBuilder.Curve();
	if (!compositeConverter.Add(approximate, tolerance, false))
	{
	Standard_Failure::Raise("Compound curve segment is not continuous");
	}
	}

Or find a wa to detect if the bSpline is on angular or natural parameterization, but not straightforward call.

But you might have better ideas.

[CBenghi]

Indeed, I followed the same rabbit hole up to

XbimGeometry/Xbim.Geometry.Engine/Factories/Unmanaged/NCurveFactory.cpp

Lines 273 to 274 in bd0f77c

	Geom2dConvert_CompCurveToBSplineCurve compositeConverter
	(Convert_ParameterisationType::Convert_RationalC1); //provides exact parameterisation

According to ChatGPT, the Geom2dConvert_CompCurveToBSplineCurve keeps the exact representation for conic curves where possible; conic curves can be exactly represented as rational B-splines (NURBS) of degree 2.

The converter uses the known exact form rather than approximating by sampling. For example:

• A line becomes a degree-1 B-spline.
• A circle or ellipse becomes a degree-2 rational B-spline with weights.
• Parabola/hyperbola likewise get their exact rational form.

It looks like the parametrization logic can be controlled by the parameter passed on line 274, but I don't see there's one that fits our needs at the moment.

[Ibrahim5aad]

@CBenghi can you verify if it is working on your side now? I tested in Flow model processing and working fine for me.

[CBenghi]

Helllo @Ibrahim5aad,
I think there is probably still an issue there. I added a test case in the branch referenced above here (9746445).

Distances along the central roundabout should be about 0.2 meters apart, while the others are spaced about 5 meters apart