adrianinsaval wrote: ↑Thu Jun 08, 2023 3:55 pm
I'm no expert on this but please remember that python scripting is one of the main features of FreeCAD, if you can do these things you propose with no regression on the python side ok, otherwise...
Yes! I agree. And I love python.
And the python console teaches me a lot! I actually want a better python integration, but I think it is very hard when no one seems to really understand how things work backstage. It is too complicated. Once
I was experimenting with the sketcher's geometry. Everyone was telling me that it was not possible to change the geometries form python. Then, I figured it was not "design". Actually, it is possible, but you have to
copy the whole geometries array and put it back the whole array, modified.
adrianinsaval wrote: ↑Thu Jun 08, 2023 3:55 pm
IMO this is not feasible [...]
I am a believer!
I am not naive, though.
And I love the quote:
- They did not know it was impossible, so they did it.
adrianinsaval wrote: ↑Thu Jun 08, 2023 3:55 pm
you want us to make our own geometric kernel?
I just want to make it very clear that I do not want anyone to make anything.
I mean, I am not demanding or saying that people have to do this or that... I am sharing an idea...
But if by "us" you mean
"us, the believers"... then my answer is:
No. I think that a
coordinate system object can be specified through the use of some simple (to be listed) parametrized objects. In the beginning, simple ones. I believe that each "thing" (wall, part, geometry, extrusion, etc) is able to "export" those things in a very stable manner.
When I say very stable, I mean that:
1. Things usually do not cease to exist conceptually just because of the shape.
2. When things do disappear, or when the counting changes, or any other topological invariant changes, the name resolution shall fail with the appropriate exception thrown, explaining the user what changed and what actions need to be taken.
I want to avoid TNP as much as possible, and alert the user when some problem happens. I want to do this in a very documented and uniform way. For example, suppose you have a
"coordinate object" that specifies a point by means of the intersection of a one dimensional object L and a two dimensional object P. Some sort of "CoordinatePoint p(L,P)"...
Now, suppose this coordinate point can be reached through a path xxx.yyy.zzz. And suppose it exports the intersection points. It could export names like:
1. "n" - the n-th intersection point.
2. "n_q" - the n-th intersection point of "q" known to exist points.
Then, if you refer to "xxx.yyy.zzz.2" you will get:
1. A reference to the second intersection point when it exists.
2. An exception thrown when "recalculating/executing" the object.
If you refer to "xxx.yyy.zzz.2_3", you will get:
1. A reference to the second intersection point when it exists and there are exactly three intersection points.
2. An exception.
When the referencing object is informed of changes or when it recomputes, it shall advise the user of exception in those problematic references. I have started developing a naming resolution scheme that I think is capable of doing this. Take a look at the README.md here:
https://github.com/andre-caldas/FreeCAD ... e/Accessor
When not possible, people can use the shape... but they should be advised not to do so!
To have a coordinate system one needs an xyz parametrization of the space. This can be specified in many ways using: points, vectors, parametrized surfaces, parametrized lines and other xyz parametrizations. A wall xxx, for example, can take a sketch (it has a normal vector), pick up an element yyy and export "xxx.yyy.top_plane" or "xxx.yyy.left_plane". The origin of the coordinate system can be specified as the intersection of two straight lines on the sketch... and they actually do not need to intersect topologically!!!
The document tree keeps the simple constructions of a part design... all structured. You do not need to refer to some "Face27"!!! You can refer to the bottom plane that was generated by the "pad operation". Part of the TNP can be solved when the user clicks on the face s/he wants to use.
adrianinsaval wrote: ↑Thu Jun 08, 2023 3:55 pm
and what makes you think the same won't happen if we didn't depend on occt?
Design.
adrianinsaval wrote: ↑Thu Jun 08, 2023 3:55 pm
TNP is a fundamental problem in all CAD, it's not specific to OCCT so we would need the TN algorithm anyways.
Yes, it is a fundamental problem. No, we would not need
"the" TN algorithm. And I state that even not knowing what you mean by
"the" TN algorithm.
We need to deal with TNP. And we shall design it to be easy... not magical.