Civil engineering feature implementation (Transportation Engineering)

[Joel_graff]

it looks interesting. Do you have some theory behind or is it an experimentical result?

Mostly intuition. I applied constraints which are geometric properties of a simple arc, just to see what the result is. No matter how I moved or oriented it, visually, it appears to match a simple arc exactly. I suspect this is a known property of splines and can be proved mathematically, but I can't prove it.

Anyway, breaking it down with a slightly enlarged image:

screenshot_4.png (32.14 KiB) Viewed 1351 times

In terms of a simple arc, two key points are already established - the end points (PC / PT).
I need two other points to complete it, namely the center point and the point of intersection (PI).

Center point:

Consists of two line segments which are of equal length and orthogonal to the curve at it's end points.

I achieved this by applying an equal length constraint (#19) and two orthogonal constraints (#20 & #21). Because b-splines don't support ortho contraints, I had to constrain the radius lines to the adjacent tangent lines

PI:

Created by adding four line segments tangent to the curve, connecting the end pints to the spline control points, and then projecting to the PI itself.

I discovered by inspection that the spline control points appear to always fall on a line which projects tangentially from the end points. I added two line segments, each connecting an end point to it's nearby control point, and applied an equal-length constraint between them (#23). These constraints ensure the control points form a line segment that is always tangent to the midpoint of the curve. The last two line segments are simply constrained to the previous line segments tangentially (#14, #15) and meet at the point of intersection (PI).

Note that the last two line segments and three corresponding constraints (#14, #15, and the coincident constraint at the PI) are not really necessary. The same degree of control could be gained by connecting the control points with a line segment, thus reducing the constraint count by 3. However, the PI is a critical part of traditional curve design, so it's representation is essential.

Also, the equal length constraint #1 is unnecessary. I noticed it only as I was writing this up. I deleted it with no ill effect, reducing the total constraint count to 16. I'd like to think there's a way to optimize it further (apart from deleting the last two line segments that form the PI), but I'm not that good at geometry.

[microelly2]

I played with the idea and it seems to work.
So I will write a next Sketcher Class which automates this method.
this seems to be easier than the ideas I had before.

[Joel_graff]

I played with the idea and it seems to work.
So I will write a next Sketcher Class which automates this method.
this seems to be easier than the ideas I had before.

Right, but now the question is, can we reliably approximate compound (two / three center) curves using a single b-spline? I don't see how to get that done at this point. I'll have to study compound curve geometry a little bit. Maybe something will come to me.

The other issue will be, assuming it can be done, how much additional geometry and constraints will be required?

[microelly2]

we need with your idea 4 control points for one arc, than 2 to get a straigt line beteen and the next 4 for the next arc.
this will work for at least two arcs. Than we create the next sketcher and connect both wit the endpoint and tangent overtake.

[Joel_graff]

this will work for at least two arcs. Than we create the next sketcher and connect both wit the endpoint and tangent overtake.

You're proposing separate splines for compound arcs? I considered that, but it defeats the purpose of using splines rather than piecing together arc's and line segments.

But if you see value in that, I won't get in your way.

[Joel_graff]

we need with your idea 4 control points for one arc, than 2 to get a straigt line beteen and the next 4 for the next arc.
this will work for at least two arcs. Than we create the next sketcher and connect both wit the endpoint and tangent overtake.

I've almost solved this problem.

Untitled.jpg (99.38 KiB) Viewed 1322 times

two-center-curve.FCStd

(5.3 KiB) Downloaded 53 times

There are several blocking issues:

1. Reference constraints can't be used in Sketcher constraint expressions. This prevents me from calculating t1 / t2, which is based on the arc radii and the angles theta 1 and theta 2. It could be done in python, but it will require updates as the user drags control points

2. b-splines don't support tangent / ortho constraints. Making this possible might reduce the need for item #1, but probably not eliminate it. Here, though, it would be potentially helpful if the line passing directly over the arc could be constrained tangentially to it.

The three-center and spiral curve cases are certainly solvable, I think, if we can get two-center curves to work right.

[microelly2]

I will look at your model tomorrow.
for the moment I have the script to generate a Arc+Line+Arc Bezier.

bp_756.png (34 KiB) Viewed 1297 times

it's in my git, next I have to merge it and to start writing concepts.

[Joel_graff]

I will look at your model tomorrow.
for the moment I have the script to generate a Arc+Line+Arc Bezier.

Gorgeous.

I wonder though, if you've got a few redundant constraints... the 10 mm radius constraint on the initial control points - I don't see the need for it here. And it looks like you've got an equality constraint on the upper-half of the tangent lines. Those, I know, arent' needed...

But otherwise, that looks amazing.

[griffmic88]

I will look at your model tomorrow.
for the moment I have the script to generate a Arc+Line+Arc Bezier.

Gorgeous.

I wonder though, if you've got a few redundant constraints... the 10 mm radius constraint on the initial control points - I don't see the need for it here. And it looks like you've got an equality constraint on the upper-half of the tangent lines. Those, I know, arent' needed...

But otherwise, that looks amazing.

I've been playing around with the tool myself and looking at the code (you guys need to slow down lol, making me feel bad). I wish o how I wish their was survey foot option in the preference file for working units.

[Joel_graff]

I've been playing around with the tool myself and looking at the code (you guys need to slow down lol, making me feel bad).

Don't look at me. This is entirely microelly's doing.

I wish o how I wish their was survey foot option in the preference file for working units.

Hmmm... so 1 survey foot = 1.000002 international feet. Or 2 * 10^-6 difference. Setting up a new unit of measurement for that shouldn't be an issue, but I wonder if floating point error might complicate that...?