Dissallowing cross coordinate-system links

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
DeepSOIC
Posts: 4504
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Dissallowing cross coordinate-system links

Postby DeepSOIC » Sun Feb 19, 2017 7:03 pm

@ickby: I'm curious to know, why didn't you go for cross-reference prevention by altering the behavior of getSelection()/getSelectionEx()?
ickby
Posts: 2428
Joined: Wed Oct 05, 2011 7:36 am

Re: Dissallowing cross coordinate-system links

Postby ickby » Mon Feb 20, 2017 6:39 am

DeepSOIC wrote:@ickby: I'm curious to know, why didn't you go for cross-reference prevention by altering the behavior of getSelection()/getSelectionEx()?

Mostly because this only helps for tools and is not a general solution, you can mes sthings easily from the python or c++ API. I suppose doing it that way we still would end up having any kind of crazy graphs.

Yesterday I realized that my code doesn't work very well, as it only checks for new links. However, if one removes a object from a group, but not the objects it links to, it still creates an invalid linking without my code recognizing it.

With this issue and the already mentioned ones bfrom deepsoic it seems I need go back to the drawing board, the current solution is not very satisfying...
DeepSOIC
Posts: 4504
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Dissallowing cross coordinate-system links

Postby DeepSOIC » Wed Mar 15, 2017 3:29 pm

Hi!
I have a couple thoughts to drop in.

I don't really like the term "coordinate system" referring to a collection of objects sharing a coordinate space. I'd suggest replace the term with the word "workspace".


Another thought is about caching InLists. I think this is a little bit of an overkill. And it doesn't knock the performance of looking up a container of something down to absolute nothing. You still need to filter the inlist to pick up containers from it, and then check if the feature is actually contained by the container.
Making the object know which container it is in seems to be easier, as you only need to alter GroupExtension to take care of keeping the stuff synchronized. Yet it gives absolute maximum performance for the problem.
One thing that benefits from inlist caching is TempoVis, which has a feature to collect up all dependent objects to make sure they are hidden. But this kind of operation can be re-implemented to pre-cache the graph as needed, especially to constrain itself to only work within one container. And even in current implementation I haven't noticed any slowdown yet.
User avatar
kkremitzki
Posts: 326
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: Dissallowing cross coordinate-system links

Postby kkremitzki » Thu Mar 16, 2017 12:54 am

DeepSOIC wrote:I don't really like the term "coordinate system" referring to a collection of objects sharing a coordinate space. I'd suggest replace the term with the word "workspace".

Why not reference frame? Isn't that exactly what they are?
DeepSOIC
Posts: 4504
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Dissallowing cross coordinate-system links

Postby DeepSOIC » Thu Mar 16, 2017 1:34 pm

kkremitzki wrote:Why not reference frame? Isn't that exactly what they are?
Because
a) reference frame, as in physics, does not define a coordinate system. In this case, we are talking of a container that does define a coordinate system.
b) in our case, we are talking that geometric objects belong to a coordinate system, and it requires additional effort to use the object from within another coordinate system (transformation between them needs to be taken into account).

Workspace seems to do a better job, because I can say:
"Object1 is in Workspace1"
"Objects within a workspace can link freely to each other", e.g. "I can Part Fuse a sphere and a cube because they are both in Workspace1"
"Objects in different workspaces cannot simply link to each other, they must use special link type and optionally account for coordinate system difference"
"Placement defines a coordinate system" (I mean, placement alone by itself, App.Placement)
"Coordinate system doesn't define placement, since coordinate system can be in general left handed, skewed and otherwise distorted"
"Placement doesn't define a workspace. Workspace is defined by a moveable container (e.g. PartDesign Part). Objects in non-moveable containers (like Group) within Part are in the same workspace, Part."
User avatar
kkremitzki
Posts: 326
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: Dissallowing cross coordinate-system links

Postby kkremitzki » Thu Mar 16, 2017 3:19 pm

DeepSOIC wrote:
kkremitzki wrote:Why not reference frame? Isn't that exactly what they are?
Because
a) reference frame, as in physics, does not define a coordinate system. In this case, we are talking of a container that does define a coordinate system.
b) in our case, we are talking that geometric objects belong to a coordinate system, and it requires additional effort to use the object from within another coordinate system (transformation between them needs to be taken into account).

Workspace seems to do a better job, because I can say:
"Object1 is in Workspace1"
"Objects within a workspace can link freely to each other", e.g. "I can Part Fuse a sphere and a cube because they are both in Workspace1"
"Objects in different workspaces cannot simply link to each other, they must use special link type and optionally account for coordinate system difference"
"Placement defines a coordinate system" (I mean, placement alone by itself, App.Placement)
"Coordinate system doesn't define placement, since coordinate system can be in general left handed, skewed and otherwise distorted"
"Placement doesn't define a workspace. Workspace is defined by a moveable container (e.g. PartDesign Part). Objects in non-moveable containers (like Group) within Part are in the same workspace, Part."

Are you using a very particular definition of reference frame? A reference frame does not require a particular coordinate system (e.g. Cartesian, spherical), but a reference frame from my understanding is a coordinate system/orthonormal basis equipped with an origin, so while it doesn't "define" a coordinate system, it certainly "has" one, although which one is arbitrary. Then, the geometric objects you mention in b) "have" that reference frame, or are defined in terms of it, and in order to use objects in another reference frame, you have to start expressing things using a combination of the vectors that define the origins of your reference frames plus their basis vectors.

Reference frames seem to do everything you're describing so it's quite confusing to hear you say otherwise.

However, as far as the actual implementation, what you're saying makes sense; using "Workspace" for a movable container of objects that are share the same reference frame (as I use the term) seems useful, especially as a way to differentiate between fixed containers like Group.