Civil engineering feature implementation (Transportation Engineering)
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
Be nice to others! Read the FreeCAD code of conduct!
- microelly2
- Veteran
- Posts: 4688
- Joined: Tue Nov 12, 2013 4:06 pm
- Contact:
Re: Civil engineering feature implementation
Nice demonstration how the solver fails.
The solver always finds the "nearest" solution of a constraint system, but
this "nearest" must not be what we want.
We have to draw a configuration which leads the server to our expectations.
With the sketcherobjectpython we can add more intelligence than only solve equation systems.
we can push the system on a death point to the right direction .
then the server can run.
The core task is to define boundary conditions where the sketcher solver finds the solution we expect.
The simple testcase is a task to create a triangel by 2 sides and the not enclosed angle.
There are 2 solutions. How to write a sketcher extension which can switch between both solutions.
The solver always finds the "nearest" solution of a constraint system, but
this "nearest" must not be what we want.
We have to draw a configuration which leads the server to our expectations.
With the sketcherobjectpython we can add more intelligence than only solve equation systems.
we can push the system on a death point to the right direction .
then the server can run.
The core task is to define boundary conditions where the sketcher solver finds the solution we expect.
The simple testcase is a task to create a triangel by 2 sides and the not enclosed angle.
There are 2 solutions. How to write a sketcher extension which can switch between both solutions.
Re: Civil engineering feature implementation
microelly2 wrote: ↑Mon Jun 26, 2017 8:57 pm Nice demonstration how the solver fails.
The solver always finds the "nearest" solution of a constraint system, but
this "nearest" must not be what we want.
We have to draw a configuration which leads the server to our expectations.
With the sketcherobjectpython we can add more intelligence than only solve equation systems.
we can push the system on a death point to the right direction .
then the server can run.
The core task is to define boundary conditions where the sketcher solver finds the solution we expect.
The simple testcase is a task to create a triangel by 2 sides and the not enclosed angle.
There are 2 solutions. How to write a sketcher extension which can switch between both solutions.
Any suggestions on how to tweak the solver to use parameters that are more geared to the objective of this proposed WB ?Abdullah wrote:ping
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation
I know this probably won't make sense, but when I saw the way the curves failed... my intuition told me it was gimbal lock - essentially, what looks like the shorter path ends up becoming the longer path... Don't suppose you've implemented quaternions to calculate angle rotations in the solver...?microelly2 wrote: ↑Mon Jun 26, 2017 8:57 pm Nice demonstration how the solver fails.
The solver always finds the "nearest" solution of a constraint system, but
this "nearest" must not be what we want.
We have to draw a configuration which leads the server to our expectations.
With the sketcherobjectpython we can add more intelligence than only solve equation systems.
we can push the system on a death point to the right direction .
then the server can run.
The core task is to define boundary conditions where the sketcher solver finds the solution we expect.
The simple testcase is a task to create a triangel by 2 sides and the not enclosed angle.
There are 2 solutions. How to write a sketcher extension which can switch between both solutions.
Anyway, on a topic I know a little more about..
This is, obviously, an edge case for the way the solver was intended to be used. And I think we can fix it without having to work with the solver. But it's important to distinguish between the user's intuition of how the solver works from the way that it actually works.
Specifically, a user's intuition would expect:
1. That the general orientation of all geometry should remain unaffected (i.e., no tangent reversals)
2. That previously drawn geometry is canon - and should remain generally fixed unless directly manipulated by the user. Perhaps more functionally, geometry is manipulated by it's selection order. Thus, if I pick two points to constrain tangentially, the latter selection is moved, while the former remains unchanged.
Whether or not those are realistic expectations is another matter. And if it doesn't make sense to force them upon the solver, then another way should be found.
However, these expectations need to be accommodated at some point. I love the Sketcher's more "organic" approach to the process, but alignment construction (in my world, anyway) tends to happen in a methodical serial fashion, and it's no good if previously-placed elements move every time a new one is added.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Re: Civil engineering feature implementation
Looks like if Feature issue #1560 'Provide ability to fine-tune auto constraints' was implemented it could be helpful with this WB as well.
Synchronistically @abdullah assigned it to himself
Synchronistically @abdullah assigned it to himself
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Civil engineering feature implementation
@ickby what is the methodology to customize the solver in sketcher to behave in the way we want it to in he future WB?ickby wrote:ping
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Civil engineering feature implementation
How's it going so far?Joel_graff wrote:ping
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation
@microelly2 and I have been chatting trying to figure things out. I suppose I should bring the conversation into this thread.
Mostly, it's about how to organize the data in a hierarchy that makes sense using the SketchObject class and interactive sketches.
I'll update shortly.
Mostly, it's about how to organize the data in a hierarchy that makes sense using the SketchObject class and interactive sketches.
I'll update shortly.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Re: Civil engineering feature implementation
Yes, thread activity shows vibrancy, builds interest/buzz. So please continue this conversation in the open. Thanks!Joel_graff wrote: ↑Tue Jul 04, 2017 11:44 am @microelly2 and I have been chatting trying to figure things out. I suppose I should bring the conversation into this thread.
Mostly, it's about how to organize the data in a hierarchy that makes sense using the SketchObject class and interactive sketches.
I'll update shortly.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
- Joel_graff
- Veteran
- Posts: 1949
- Joined: Fri Apr 28, 2017 4:23 pm
- Contact:
Re: Civil engineering feature implementation
Ok,
At this point, I've been going a bit in circles trying to figure out how to encapsulate the civil specific geometries I outlined in my video inside sketcher.
The problem is, there's no straightforward way to create a custom part that can be used in sketcher. Generally, I want to create a complex curve along with it's associated construction geometry and constraints as a custom part, of sorts.
To this point,I've toyed with the idea of building a custom Python class to manage this and serializing it using custom properties in the containing SketchPythonObject. That seems like a viable solution (especially since there is a list property)
Microelly2, however, has been introducing me to the interactive sketch work he's done and I'm trying to imagine how it could be used to contain civil / transportation alignment data.
There's really a lot of different kinds of data to be stored:
1. Stationing for the entire alignment (along with station "equations" which accommodate discontinuities)
2. Entire alignments, which may or may not intersect with one another, but may be a part of the same project
3. Alignment components (tangents / curves)
4. Component geometry (construction geometry) and constraints
Microelly2 proposed creating a sketch which encompassed an entire alignment, and then making a child sketch which handled the constraining construction geometry (tangents, chords, radii, etc). This approach would solve the clutter issue I mentioned as the construction geometry and constraints would exist in a separate sketch which could be shown / hidden.
But as I considered it further, I think I've got a clearer picture of the data hierarchy for this sort of work. Specifically, I see the data being broken down into the four categories suggested above.
Thus, where microelly2's hierarchy was:
Mine is a bit more complex:
I am certain I don't fully grasp the way this works, but I'm trying to ensure we have the interactivity necessary to fully construct a corridor alignment in 3D.
Understand I'm thinking about a typical highway construction project. It may involve a new alignment along the main road, with minor changes in sideroads that intersect. Additional "frontage" roads may be created that run parallel, and there may be some alignments which never intersect.
For example, the Corridor / Project sketch might contain b-splines generated from all alignments. It's geometry is not directly editable as it's auto-generated from changes made in the lower-level sketches. However, this would be a great place to develop / manage project-level (global) data that applies to all alignments within it. Further, this geometry would act as the necessary ancestor to child geometries to provide interactivity between them (since sibling interactivity doesn't appear to be possible).
Then, each Alignment sketch would represent any given alignment, primary or secondary. Again, the geometry here is auto-generated and not editable. It provides the source of the aggregated alignment geometry represented in the corridor sketch. Best of all, at the alignment level, we finally have a place for stationing! I still don't know how it can be represented visually, but it is, hierarchically speaking, where it needs to be defined.
Finally, the component / geometry sketches are where work is done. Each sketch tuple represents a single component in the alignment and that component's corresponding construction geometry. So, suppose the user clicks a "Two-Center Curve" button in the UI. A new component sketch and the corresponding geometry child sketch are auto generated and populated, then attached at the end / selected point in the alignment. Then, the higher levels (alignment and corridor) are auto-updated with the change...
In the end, the user works primarily between the component sketch and geometry sketch (much like microelly2 demonstrated in his video). The higher level sketches are simply auto-updated and provide more global data structures for use in editing the lower level sketches.
Sorting through the sketches is a problem, though. A large project would quickly become encumbered by many hundreds of sketches. Using stationing and descriptive naming, it's a small matter to describe where each sketch is located in the project, but the actual hierarchy can't be represented in the element listview.
So I suppose that means a treeview needs to become the default (or optionally switched in) to represent sketch document structures which have a parent-child relationships.
So that's my inspiration ... and it only took two cups of coffee!
Anyway, I imagine my attempt at describing my thoughts has made this about as clear as mud to everyone else. I think we're on the right path, but please ask me to clarify if there's something not understood.
microelly2's video on interacting sketches:
At this point, I've been going a bit in circles trying to figure out how to encapsulate the civil specific geometries I outlined in my video inside sketcher.
The problem is, there's no straightforward way to create a custom part that can be used in sketcher. Generally, I want to create a complex curve along with it's associated construction geometry and constraints as a custom part, of sorts.
To this point,I've toyed with the idea of building a custom Python class to manage this and serializing it using custom properties in the containing SketchPythonObject. That seems like a viable solution (especially since there is a list property)
Microelly2, however, has been introducing me to the interactive sketch work he's done and I'm trying to imagine how it could be used to contain civil / transportation alignment data.
There's really a lot of different kinds of data to be stored:
1. Stationing for the entire alignment (along with station "equations" which accommodate discontinuities)
2. Entire alignments, which may or may not intersect with one another, but may be a part of the same project
3. Alignment components (tangents / curves)
4. Component geometry (construction geometry) and constraints
Microelly2 proposed creating a sketch which encompassed an entire alignment, and then making a child sketch which handled the constraining construction geometry (tangents, chords, radii, etc). This approach would solve the clutter issue I mentioned as the construction geometry and constraints would exist in a separate sketch which could be shown / hidden.
But as I considered it further, I think I've got a clearer picture of the data hierarchy for this sort of work. Specifically, I see the data being broken down into the four categories suggested above.
Thus, where microelly2's hierarchy was:
Code: Select all
Alignment Sketch
|----> Constraints Sketch
Code: Select all
Corridor (Project) Sketch
|----> Alignment Sketch
|----> Component Sketch (tangents / curves)
|----> Geometry Sketch (constraining geometries - tangents, chords, radii, etc.)
Understand I'm thinking about a typical highway construction project. It may involve a new alignment along the main road, with minor changes in sideroads that intersect. Additional "frontage" roads may be created that run parallel, and there may be some alignments which never intersect.
For example, the Corridor / Project sketch might contain b-splines generated from all alignments. It's geometry is not directly editable as it's auto-generated from changes made in the lower-level sketches. However, this would be a great place to develop / manage project-level (global) data that applies to all alignments within it. Further, this geometry would act as the necessary ancestor to child geometries to provide interactivity between them (since sibling interactivity doesn't appear to be possible).
Then, each Alignment sketch would represent any given alignment, primary or secondary. Again, the geometry here is auto-generated and not editable. It provides the source of the aggregated alignment geometry represented in the corridor sketch. Best of all, at the alignment level, we finally have a place for stationing! I still don't know how it can be represented visually, but it is, hierarchically speaking, where it needs to be defined.
Finally, the component / geometry sketches are where work is done. Each sketch tuple represents a single component in the alignment and that component's corresponding construction geometry. So, suppose the user clicks a "Two-Center Curve" button in the UI. A new component sketch and the corresponding geometry child sketch are auto generated and populated, then attached at the end / selected point in the alignment. Then, the higher levels (alignment and corridor) are auto-updated with the change...
In the end, the user works primarily between the component sketch and geometry sketch (much like microelly2 demonstrated in his video). The higher level sketches are simply auto-updated and provide more global data structures for use in editing the lower level sketches.
Sorting through the sketches is a problem, though. A large project would quickly become encumbered by many hundreds of sketches. Using stationing and descriptive naming, it's a small matter to describe where each sketch is located in the project, but the actual hierarchy can't be represented in the element listview.
So I suppose that means a treeview needs to become the default (or optionally switched in) to represent sketch document structures which have a parent-child relationships.
So that's my inspiration ... and it only took two cups of coffee!
Anyway, I imagine my attempt at describing my thoughts has made this about as clear as mud to everyone else. I think we're on the right path, but please ask me to clarify if there's something not understood.
microelly2's video on interacting sketches:
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
Re: Civil engineering feature implementation
@Joel_graff ping. Any proof of concepts yet ?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs