ickby wrote:Hello tanderson,
I did have a brief look at your dag view. I do like it, I think this kind of view is a nice addition. Not as visually comprehencable as the dependency graph, but way less space hungry. IMHO a good compromise.
Hello, I was hoping you would chime in as we have had a similar conversation a little while ago.
ickby wrote:One thing I noticed is that it does not work well for "overlapping edges"- Meaning if two parts depend on one, the edges overlap and it becomes basicly impossible to differentiate the paths. For example create a part with some solid, make a datum plane based on that solid and then pad a sketch on top of the datum plane. Now add a second part and create a sketch in this second part on top of the edatum plane of the first part. Now the dag view gets impossible to read correct (can't attach the file right now, sorry)
I don't really follow your example as it trying to use a datum plane from another body/part which part design rejects. Doesn't matter though because I have no doubt the problem you describe exists. My question to you about this is: Does this problem exist because a feature node/point isn't in the correct column? If the answer is yes, this leads back to the point of my original post.
ickby wrote:A second thing imeaditly noticable is the missing possibility for grouping. It would help very much for understanding if one would be able to close groups like in the tree. For example the origins are most likely never of interest.
I have had some thoughts and I was leaning toward the idea of filters. Mainly to try and stay away from more scene items and animation.
filter ideas:
show paths from "leaf"
show paths from "root"
hide paths under "origin" or whatever object.
show paths for body object.
more
Nothing in this matter is concrete.
ickby wrote:This does of course create a huge problem: once multiple graph nodes are grouped inside one parent, all the subnode edges need to originate from the parent node. To stay in the example, once the origin node is collapsed all edges connecting to the planes and lines no need to be connected to the origin itself. However, as you seem to use the boost graph library I can offer some code that has already solved that problem. The exact same functionality is needed for the assembly solver so I created a set of template classes around boost::graph which do exactly this: subgrouping graphs while keepig the connections. If interested have a look at this:
the explanation of the concept:
https://github.com/ickby/openDCM/blob/m ... rgraph.hpp
the base class:
https://github.com/ickby/openDCM/blob/m ... sgraph.hpp
the cluster graph:
https://github.com/ickby/openDCM/blob/m ... rgraph.hpp
a filter graph:
https://github.com/ickby/openDCM/blob/m ... rgraph.hpp
if you have any questions feel free to ask. It may be also helpful to build the project documentation, as then nice pictures are included into the clustergraph documentation.
Hah! I already looked at it a little while ago out of curiosity and even made some changes to the documentation. Sounds interesting, but to be honest the idea/concept hasn't penetrated my thick skull yet. Is your latest code merged into jurgens assembly branch? Even though I am building this on the assembly branch I am doing my best to make the dagview independent.