View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001994||Arch||Bug||public||2015-03-07 20:59||2015-09-02 16:29|
|Target Version||Fixed in Version||0.16|
|Summary||0001994: Circular dependencies in Sketch-based Arch Windows|
and "Document::recompute: The graph must be a DAG."
I guess I found it out and this is essential.
An Arch Window becomes a part of a host Arch Wall and changes it. But if a window is based on a sketch which is binded to wall's edges, then we have dependency loop: changed (windowed) wall brokes the binds on those the changing was built.
|Steps To Reproduce||1. Make a wall.|
2. Make a sketch on the wall's face.
2.1 The sketch MUST BE binded with the face's edges using External Geometry.
3. Make a window based on the sketch.
or simply make an Arch Window on the Sketch001 of the attached project.
|Additional Information||Linux 32-bit, commit 89a6e67, but it doesn't matter, I'm sure.|
|Tags||No tags attached.|
This is not so minor as can seems. For example I cant change the height of the foundation on which such windowed wall is built.
It's ok after window removing.
||This is solved in 0.15 already.|
I asked to set git tag for v0.15 in FC IRC, but that was ignored, unfortunatelly.
So.. I don't see where v0.15 is. Only unclear (for me) commit bd6a5ce ("Bumped version to 0.15 and added a temporary new splash"):
-#define FCVersionMinor "14"
+#define FCVersionMinor "15"^M
I retried the bug with the current HEAD (10aa881, see conamed attach) and that was reproduced (make a Window on the Sketch001)
||May be v0.15 is placed in a custom git branch? But I dont see obvious variant...|
||I don't really understand what you mean... But in any case, version 0.15 is the current git master from the sourceforge repo. And with it, I can't reproduce your bug. When doing point 3. (making a window with the sketch selected), things work correctly (the external edge binding is removed).|
Yorik, see attached video please. Only one of two ExternalGeometry's was autoremoved, and there is no window hole, as you can see.
But I guess, removing of external bindings is not a good idea. This is the fast and easy decision, yes, of course; but not good. Sketches becomes unconstrained, any host changing can produce unexpected movings of slave objects.
And this is the common place of FC's External. I discussed with @ickby in IRC but without significant results.
I see two perspective improvements:
1. The ability to bind to ExternalVertexes, not only Edges.
2. Any changing which can reenumerate object's edges, faces or vertexes must be workarounded by an algorithm of matching between old and new parts. Found => ok and rename back(or rebind slave sketches), not found => remove all bindings and report it.
Or completely avoid reenumerating by using autoincrement for naming, for example.
I tried to analyze the possibility of the above, but I doesn't have sufficient skills.
As I understand, v0.15 is the _current developing_ (all after 0.14). I thought this is a release and couldn't find it on the site or in the git.
Ok now I see... Indeed If you have more than one external edge it fails. I'll fix that.
Removing the external geometry is unfortunately the only solution at the moment, because FreeCAD strictly prohibits circular dependency. And since the wall depends on the window to create its opening, and the window depends on the sketch, the sketch cannot depend on the wall.
Yes, I agree this is essential for Arch Windows, and cant be easily fixed.
But what do you think about the improvements above? It's a bit offtop, but the first floor of my very first house moves onto the side of the foundation, when I made a vent hole. I was forced to abandon any external bindings in the second variant. And now any base resizing leads to a lot of manual work.
Take a look... Any shape contains of vertexes, edges and faces. Any new item gets autoincrement uid. An External Geometry uses edge's uid not index for binding. Adding vertexes to an external geometry obviously expands FC abilities.
I understand this is not as easy as it looks, but I'm sure it can be great enhancement for the project.
1. What to you mean?
2. Is it possible.... mmm.. to force this idea among the maintainers? :)
This is already the subject of bug 0000876 but it is a huge work and it won't be done overnight... As for selecting vertices, that could be done, but I suggest you discuss the idea on the forum first to find people interested in implementing it.
This won't solve the window dependency issue, but honestly I still haven't found a good solution for that problem.
||The problem with windows based on sketches that contain more than one external geometry is now fixed, so I'll close this issue since there is no more that can be done here. Reopen if needed.|
|2015-03-07 20:59||farisey||New Issue|
|2015-03-07 20:59||farisey||File Added: DAG.fcstd|
|2015-03-07 21:14||farisey||Note Added: 0005856|
|2015-03-11 23:05||yorik||Note Added: 0005859|
|2015-03-11 23:05||yorik||Status||new => closed|
|2015-03-11 23:05||yorik||Assigned To||=> yorik|
|2015-03-11 23:05||yorik||Resolution||open => no change required|
|2015-03-11 23:05||yorik||Fixed in Version||=> 0.15|
|2015-03-13 13:23||farisey||Note Added: 0005865|
|2015-03-13 13:23||farisey||Status||closed => feedback|
|2015-03-13 13:23||farisey||Resolution||no change required => reopened|
|2015-03-13 13:23||farisey||File Added: DAG.10aa881f.FCStd|
|2015-03-13 13:59||farisey||Note Added: 0005866|
|2015-03-13 13:59||farisey||Status||feedback => assigned|
|2015-03-13 16:14||yorik||Note Added: 0005867|
|2015-03-13 16:15||yorik||Status||assigned => feedback|
|2015-03-13 21:16||farisey||Note Added: 0005868|
|2015-03-13 21:16||farisey||Status||feedback => assigned|
|2015-03-13 21:17||farisey||File Added: dag2.avi|
|2015-03-13 21:25||yorik||Note Added: 0005869|
|2015-03-13 21:25||yorik||Fixed in Version||0.15 => 0.16|
|2015-03-14 13:17||farisey||Note Added: 0005871|
|2015-03-14 15:46||yorik||Note Added: 0005873|
|2015-09-02 16:29||yorik||Note Added: 0006326|
|2015-09-02 16:29||yorik||Status||assigned => closed|
|2015-09-02 16:29||yorik||Resolution||reopened => fixed|