Hi guys, we are working with large files and lots of xrefs (in lack of a Rhino word: xref is externally referenced files)
But we have a problem when we reference in a files that also have same files referenced in…
Here is a better example:
File A is first half of a project
File B is second half of a project (A and B are two physical projects handled after each other, with different plans, sections etc. and different project names and numbers are should not be handled as one Rhino file. It’s just how it is in real world)
File C contains the landscape around A and B
File D contains the 3D scan of the site
Both File A and File B needs C and D referenced in.
But then I need File A referenced in to File B so I can see the whole project together, but since they both have C and D referenced stuff gets odd.
AND to make it worse, if I save A with B referenced in, and THEN open B and want A referenced in… then I get a loop, since A allready has B in… you get the picture?
How could Rhino handle cross references like this better when worksessions are NOT an option?
Ideally it would read the file, say: "Oh, I allready have that file referenced in, so I ignore it, and then continue like nothing odd had happened.
In programming contexts one would typically consider introducing a “middleman” to handle the dependencies (only the middle man would know all the participants while the participants don’t know of each other, they only know the middle man) so that the individual participants don’t end up with the dreaded “circular references” problem.
I don’t know how this would be handled with Rhino models though (I once tried to do some fancy “decoupling” stuff using Worksessions, but Worksession are (still) a bit like the old Swedish SAAB cars, - they promise and promise and promise, like “putt, putt, putt”, but they never actually deliver…)
Fig. Old Swedish car (or whatever you’ld call it) which was later implemented as “Worksessions”:
Yeah, worksessions was a prototype that made production and never got refined… unfortunately since it has such great potential.
Same with xrefs in Rhino, the default settings is bad and custom settings are not stored, so each time we have to change three settings for it to work like we want it to. But then it works solid and well. So the underlying structure is well built.
I tried making an extra file to hold all xrefs, and then only reference that into A and B, but that messes up too.
When we reference in a linked file (child) in to a rhino file (mother) we set it to use it’s own layer structure:
We do the same with another mother (father) file, this has the same child.
And then if we reference this file (mother) into another file again (master) and use the same choises then the layers of the mother and the child is shown side by side and not integrated.
And THEN if we insert the (father) this same child is now inserted again in the layers. But not shown as a new object. And can only be turned on and off from underneath one parent. (At least in the situation we had, I have not spent much time crossbugtracking this since it isn’t that fun to play with)
I wish for an option to IGNORE children of files when linked in. That would solve a lot. In theory… but would also cause objects to disappear IF used differently…
So I guess I actually wish for a PURE xref link handler that is used only for referenced files, and that would handle cross references and circular loops like a king. (An integrated worksession hybrid)
What if, instead of referencing A in B and B in A you introduce a new top level Fiendish Masterplan that does nothing but reference A and B, so you preserve a strict hierarchy (sorry, away from computer so can’t try for myself)
