blimey Posted May 8, 2009 Share Posted May 8, 2009 Hi I've got this frustrating problem of VP moving when files have different origins, i'd be very grateful for any advise to resolve this : *** TOPO.vwx is the topographic site plan of a project we have with many buildings. It is oriented North-South with its 0,0 at the limit of the site *** AXES1.vwx is the main axes plan for building1. It is oriented so to have the building straight. It has its 0,0 on the top right corner of buiding1 *** AXES2.vwx is the same for building2 and so forth for the 5 buildings that each have different orientation => i'm bringing TOPO.vwx in each of the AXES files so to have a referenced file for axes and topography that I will then use for all the plans of each building. TOPO.vwx is so referenced in a referenced DLVP on layer VP_TOPO => Because it does not have the same origin nor the same orientation I move the viewport and rotate it so to match the origin and orientation of each building => For exemple it works perfectly fine when done in AXE1, and I get the topography together with the AXES1 => things go wrong when I reference AXES1 in GROUND1.vwx the ground floor of building 1 : I have the axes of AXES1 nicely set, but the position of the TOPO is moved back to its own origin... Does this make sense ? is this normal? am I doing something wrong? or is this a bug? Thanks for any hints. Quote Link to comment
brudgers Posted May 8, 2009 Share Posted May 8, 2009 I would recommend that you have a common point of origin for the project...that's what makes it a point of origin. A work around might be to create a seperate design layer and to use design layer viewports to bring in each component. Then reference that layer in your sheet layer viewport. I think this will give everything in the sheet layer viewport a common origin. The composite of site and other buildings could even be done in a separate file to make it reusable for future projects. Quote Link to comment
blimey Posted May 8, 2009 Author Share Posted May 8, 2009 Hi, thanks for the answers... I know it's anoying having different origins... the thing is that it makes it much easier for the mesuring of axes position within each building to reset the origin for each building... However i'm just testing to put the chained ref in cached mode and it seems to help... Quote Link to comment
blimey Posted June 19, 2009 Author Share Posted June 19, 2009 I really don't get this origin problem... Does the program remember somewhere another orign then the one we put in with thesetting origin command? I'm going to write another post on origin in case this one is not in the right place, but basically here is what happens : 1. I've got 4 floors of the same building with their origin all set at the cross section of axe1 and axeA... 2. I reference them in a new file as RDLVP, they all come nicely one on the top of the others, nicely superposed. I save the file under i.e. the name "REFERENCES.vwx" The purpose is to create a reference file that contains all the floors and that I will attach (as a RDLVP) in all my sections in order to be able to draw them 3. whenever I create in a new section file a RDLVP with the external reference 'REFERENCES.vwx" all my floors are splitted as if they where having different origins... => I just don't understand what happens => it is as if the floors file remember "past" origins that they retain as a real origin => The floors plan are not splitted randomly, their positions seem to be in relation with some "initial" origin which setting I don't know how to see and how to change => in order to double check this, i've referenced the floors as referenced layers (the old way) : the result is that they all come nicely superposed. YET if I select "Ignore source user origin" they do the splitting... exactly in the same position as above... I REALLY DON'T UNDERSTAND THIS AND IT'S REALLY BEEN DRIVING ME NUTS FOR MONTHES!!! Does anyone PLEASE have a clue on what's happening??????? Quote Link to comment
islandmon Posted June 19, 2009 Share Posted June 19, 2009 Think about each activity as involving Containers. With each Container having pre-sets & Over-rides depending on the nesting sequence. It all comes down to the complexities of ye olde Set Theory http://en.wikipedia.org/wiki/Set_Theory The easiest solution is to just maintain a common default Origin ( 000 ), then use Loci with coordinate offsets for everything, as req'd. Quote Link to comment
blimey Posted June 19, 2009 Author Share Posted June 19, 2009 (edited) Thank Islandmon, (please also see my reply on http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=125376&Searchpage=1&Main=26073&Words=SET+ORIGIN&Search=true#Post125376) I agree with the common default origin, but I would have expected that VW would record its "absolute" origin and shows clearly that what we actually set as "user" origin is really a user origin (relative). I can't see no way to refind the "absolute" origin once the origin has be set with "set origin" tools, not knowing that this was just a relative set... hence the mess... Edited June 19, 2009 by RENEWIT Quote Link to comment
blimey Posted June 19, 2009 Author Share Posted June 19, 2009 (edited) see also my post on origin (http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=125381&Searchpage=1&Main=26103&Words=SET+ORIGIN&Search=true#Post125381). I do feel that this behaviour pertains more to a leak in VW than to my understanding of mathematics or methodology or Logic. Yet I might be wrong and would then work on improving it. Edited June 19, 2009 by RENEWIT Quote Link to comment
blimey Posted June 19, 2009 Author Share Posted June 19, 2009 (edited) meantime I will sure lock the original origin as you advise. Thankx alot Edited June 19, 2009 by RENEWIT Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.