Jump to content

blimey

Member
  • Posts

    248
  • Joined

  • Last visited

Everything posted by blimey

  1. Hi Stan, For me it is the "heaviness" of the DLVP that is mainly responsible of the troubles, not the logic of the referencing itself. That's why having balanced the "pro" and "cons" of the DLVP, we had the feeling that they were a real plus for us only for the manual drawing of sections and elevations (for some projects we use sectionVP and then convert them to group to copy paste in the section file in order to do additional drawing and annotation on them... Actually we would have found it much better to have the sectionVP on DL rather than SL, so manual copy pasting is our workaround) Hi Jeffrey, I shall send you the PDF of our file structure : the rectangles represent vwx files. the rounded rectangles represent layers contained within the files. The continuous lines mean "layer belonging to the file". The dot lines mean "layers referenced into the file". We intend to replace all the DLVP referencing with old fashionned referenced layers (what we where allready doing for 3D anyway). Except for the section and elevation as said. => beware this is only the structure of the "working files". As said before, for daily use and print we're going to add local sheet layers. for final presentation we have a file that gather all the needed layers from all the other files and than generate many sheets.
  2. Hi Jeffrey, i'll try to answer to your question. and if you send me your e-mail I can send you a pdf of our file structure (it is actually not upto date, since it still state to use DLVP while we've decided to go back to referenced layers) ok here we go : 1) How large was the project? (How many stories, how much area?) We've been working on different projects. ProjA - block of 6 appartments, 4 stores, roughly 600m2 ProjB - block of 11 appartement, 5 stores, roughly 1000 m2 ProjC - 12 accomodations 4 floors, 3000m2 projD - 65 appartment + day care in 5 blocks average 3floors. 7000m2 CompA - Daycare for 66 kids - 3floors, 1500m2 CompB - 25 appartments in 3 blocks, 3000m2 CompC - Refurbishment of factory in to offices 10.000m2 various competition don't remember... 2) How many people were on the team? We're a team of 4/5 working on all the projects transversaly but not always simultaneously 3)Who was responsible for what modeling/drawing? One person "in charge" per project yet also working on other project where he is not "in charge". 4)Who was responsible for what modeling/drawing? Separation are "site drawing" "floor plans" (with block or unit subdivision if big project)"section and elevation" "3D" "Details" (with distinction of plan and section) 5) What was modeled vs. what was drawn (2D only)? What level of detail was modeled vs drawn? modeled : site3D, general volume (exporte in SKP and serve as base for sections/elevation in some projects) gave up going to much in details since other 3D modeling quicker... but usefull in competition whe the project changes. DLVPs cause bugs (eg if DZ first set to X and then to Y, for some reason it memorise X and never goes back to Y so there are gap between floors) All the "decoration" is 2D (eg 3D human much to heavy to be useable) 6) Were Sheet Layers used? yes 7) How was printing of drawings handled? From which files were drawings printed from? Big file referencing all the files and using sheet layer with SVP => batch printing or batch PDF exporting we intend to change that and use those big files only at the very last stage and in intermediate stage to use local SVP and saved views... 8) What were you trying to do with the DLVPs? Reference floor plans from multiple files into a central model : yes or layers from a central model to multiple files? nop 9)Were there problems with visibility control of classes or layers? yes, mainly in competition, due to the fact that even if we have lot of classes there is always a special class needed for one particular project and when created it doesn't show up in the already created DLVP... makes a big mess since people try to "find" which is the missing class. Also becauses system is complex so there's always one of us who for some reason (mainly fed up looking for the source) just "force" one class setting in the DLVP rather then letting the setting controlled by the attribute in the main navigation... big mess too... + the strees of deadlines that makes people setting classes randomly under the last minute panick and then big mess to find out what has been forced where... 10) Were you using absolute or relative settings for the referencing? absolute. We have a big post on the intranet saying that the Zero should "never" be reset because of big mess experienced with projD. comming from VW12.5 the proble was not obvious but with DLVP lot of troubles, also because our first reaction when starting to use the DLVP was to chain reference them... very big mess... we don't do that any more, but still the files are quickly very heavy. and the absolute rigour necessary is quickly painfull for the team... (it's difficult to remember why we shouldn't do something that is possible : -why not chain references : because it causes problems later -why not reset the zero : because it causes problems later -why not make more than one layer visible per DLVP : because it causes problems later etc... 11) Were files being shared by a peer-to-peer network of computers, or was a central file server being used? Server 11) PC all the best. A.
  3. Hi everyone, I would like to have your opinion and experience with DLVP and your eventual conclusion concerning their usage. Here is our experience - our conclusion is :We give up using it in most of our workflow... We started using DLVP when we upgraded from VW12.5 to V2009. That was 18monthes ago. I think we really tried to do the thing well :reading extensively the Ellicott Height project structure and white papers... I myself was really enthousiastic at first (DLVP advertising being one of the reason we decided to upgrade). Also I feel that we have tried long enough so that the decision to give up is not made light heartly. Quickly everyone in our small team (but I) started to complain about DLVP and their complexity. Nevertheless the few of us continued brainstorming on its usage (convinced that whe had to do it since it was the new path Nemetschek had engaged on... )and probalby since I insisted so much we've been using the system all that time. However, I must now admit that we have never found again a nice workflow since introducing the DLVP (files are huges, computers slow down, 3D workflow full of various bugs, from Z uncoherence and export problem to non display of element..., also the complexity of the concept itself makes it heavy to use...) So we're spending some time now to debrief the past 18months, and it seems that one of the main conclusion is that DLVP are so uneasy to use that it actually has messed up completely our workflow (which used to be pretty fine). The conclusion is that we are abandonning definitevely DLVP for almost everything, going back to the old referenced layer system. The only part where we've decided to stick to DLVP is for sections and Elevations, since the ability to rotate the DLVP allows to rotate the plan in a much more flexible way that the with the layer link... and that's good for drawing the elevations. I'd be happy to read some other users opinion...
  4. Hi Pat "It MIGHT be possible to write a set of scripts to put the classes into a worksheet (as we have already done) and then a second script to write any changes back to the classes, but I don't have the time to work on that unless I hear a lot of support for that need." => I ran into this post. and even if it is an older post, Ijust thought I'd let you know I would find such a tool HIGLY usefull, if ever you were thinking about extending the idea!!! It can help while trying to set-up the organisation of teamworking with classes... Like conceiving in an excell sheet all the classes that would be used for a project, set their attributes and then "feed it in" all the VW files that are related to the project so to get uniform organisation.
  5. What kind of trouble? We've always renamed them... no problem reported though???
  6. oh ok. I've put it in a txt files and then used "run vectorscript" and it worked. thanks a lot
  7. Hi Yotarou I'm not sure how to use the script : when I'm running it nothing happens? (I've put it into >tools>script>vectorScript plugin Editor and then added it as a new tool) It doesn't make any error, but nothing happens?
  8. Thank you for the explaination Islandmon. What's the point of such a logic? I see no advantages and only anoying problem resulting ? In particular, you can't trace where's the Parent Origin unless you draw it yourself manually and lock it at the very beginning and if you're not aware this should be done (why should it? ) it's a big mess ! Basically it means that VW cannot "really" change the origin. The set origin command is in fact only an artifact that only makes it look as if the origin had changed while in fact it just a kind of make up that adjust the value of the rulers. Anyway if NNA doesn't intend to change this (or cannot) they should at least have a built in zero that is "unmovable", "unerasable" etc... sorry I didn't answer earlier (work work work :-))
  9. Yes, I give up. thanks anyway for feedback
  10. meantime I will sure lock the original origin as you advise. Thankx alot
  11. 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.
  12. 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...
  13. it is not as if the origin has migrated by accident. The problem happens whan the origin is set accurately with the set origin tools. The fact is that if you have a file that has his "new" user orgini set with the "set origin" tools, it DOES NOT behave like the copy of the file where the full drawing has been moved to match the same origin... >>> i'm not sure this is clear so put it this way : 1. we have file A and file B that are identical 2. In file A : we set a new origin by using the "set origin" tool at a distance x=100 and y=200 from the initial origin. 3. In file B : we select the whole drawing and move it by x=-100 and y=-200 => the result is that we still have 2 identical file (they look totaly the same except for the position of the "page") yet they behave differently. => If you reference them as RDLVP ia a first file called "reference.vwx" they superpose nicely with the same origin. => YET if you reference the file "reference.vwx" you will see that the files split considering each different origins !!!!!! BERK888 => if you reference them the old way and select "ignore source document origin" they split the same way In my view this behaviours is A BIG AND ANOYING PROBLEM.
  14. it is not as if the origin has migrated by accident. The problem happens whan the origin is set accurately with the set origin tools. The fact is that if you have a file that has his "new" user orgini set with the "set origin" tools, it DOES NOT behave like the copy of the file where the full drawing has been moved to match the same origin... >>> i'm not sure this is clear so put it this way : 1. we have file A and file B that are identical 2. In file A : we set a new origin by using the "set origin" tool at a distance x=100 and y=200 from the initial origin. 3. In file B : we select the whole drawing and move it by x=-100 and y=-200 => the result is that we still have 2 identical file (they look totaly the same except for the position of the "page") yet they behave differently. => If you reference them as RDLVP ia a first file called "reference.vwx" they superpose nicely with the same origin. => YET if you reference the file "reference.vwx" you will see that the files split considering each different origins !!!!!! BERK888 => if you reference them the old way and select "ignore source document origin" they split the same way In my view this behaviours is A BIG AND ANOYING PROBLEM.
  15. Well as an after thought : How come this mess happen at all? Am I the only one that find this origin problem REALLY anoying? How do you guys feel about it? I mean this could be called a BIG BUG or not? It's quite amazing that something as important as the origin of a file could'n't have a more fluid working process... !!! What do you think ? Would you agree or do I have to question my methodoly???
  16. Hi all, I've set new user's origins in many files and from my inquiries, that was a VERY BAD idea, since it seem that this tool mess up everything (see my post here : http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=125372#Post125372) .... Yet it ALAS has been done (one would'nt expect things to mess up like that)... now i'm wondering if there's a way to fix it up with a script that could "clean all the history of the origin reset" and put the file back to it's pristine state regarding origin (I would then move the whole drawing so to have the origin at the right place instead of using the "set origin" tool... Since I'm not a scripter at all, I'm posting this here, in case anyone did have the same problem and does have a ready made script I could try to adapt to my problem? Many thanks.
  17. I'm experiencing the same problem (as decribed here : http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=125372Post125372) I guess that mike m oz is right "one should never touch the origin => Moving the origin screws ups everything so never never do it" So i might try not to do it in the future, yet right now, i feel really bad. If anyone found an easy way to fix this up... that'll be nice... would there be any script that could reset origin (clean any changes made on origin for the whole history of the file? ) in a file and than try to MOVE the whole drawing manually with the move command???
  18. Yes but once it has been done??? (and on many many files)???? how can I fix it right? what's the use of "set origin" if we can't use it? woww... i'm in a big mess... i think.... (many many files...)
  19. Hi i've been fighting with RDLVP for a while now (see my past post on chained reference : http://techboard.vectorworks.net/ubbthreads/ubbthreads.php?ubb=showflat&Main=25754&Number=125369#Post125369)... I feel there's a "hidden" origin in the file somewhere that make them move when in chained references is that possible??? the problem typically occurs when the origin of some file as been "reset" with the "set origin..." tool ??? >> Is this possible??? 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 DONT 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???????
  20. 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???????
  21. i tried many time and it finally succeeded... I don't know why it didn't work and why it did at the end. It said something with plants... but I didn't have time to write it down... Anyway now the program says SP4 when i'm in. So i'm happy.
  22. Hi Did anyone tried to update to sp4? i just did it an it failed. It told me to look for the updaterlog.txt??? can't find that file nowhere??? I did a search on my computer and no such file??? Does anyone have an idea ? thanks
  23. 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...
  24. 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.
  25. Hi Tolu, Thank you so much. Yes this is exactly what I wanted to do. I dont really understand why I have to click on the small mountain though (beside that if I don't do it it doesn't work). What it the purpose of the function? To apply to the current file the class attribute of the referenced file? or rather the other way round to apply into the referenced file the class attribtue of the current file? Anyway, your indication allready helped a lot. Many thanks again yours,
×
×
  • Create New...