Hippocode Posted November 28, 2013 Share Posted November 28, 2013 (edited) Trying to create a PERFECT vertical 3D pipe with a 3D path based object. When placing the secondary point, snapped on point 1 the Z-axis turns blue, I can now go up or down and it should give me a perfect vertical segment right ? It often doesn't and shifts about 1*10^(-12)mm. Coordinates at the bottom look correct though. How is this possible ? My first thought is that it might be the loci I'm snapping on ( for both points ). Is it possible that the loci can be snapped on different places ? I thought of it as a point.. Edited November 28, 2013 by hippothamus Quote Link to comment
Vectorworks, Inc Employee PVA - Admin Posted December 2, 2013 Vectorworks, Inc Employee Share Posted December 2, 2013 If Snap to Grid is enabled, it can behave this way. You can also make sure that "Offset Duplications" is disabled in the Edit tab Vectorworks Preferences, then duplicate the point and move it via Move 3D, giving the exact Z offset you want. If it seems to not move in a straight line in Z after that, let me know and send in the file. Quote Link to comment
Vectorworks, Inc Employee PVA - Admin Posted December 2, 2013 Vectorworks, Inc Employee Share Posted December 2, 2013 (edited) Is it possible that the loci can be snapped on different places ? I thought of it as a point.. This is a brilliant question... JimW why don't you ask the obvious next question! What obvious question do you mean? Edited December 2, 2013 by JimW Quote Link to comment
Hippocode Posted December 2, 2013 Author Share Posted December 2, 2013 (edited) If Snap to Grid is enabled, it can behave this way. I never use that setting and it seems to be turned off. You can also make sure that "Offset Duplications" is disabled in the Edit tab Vectorworks Preferences, then duplicate the point and move it via Move 3D, giving the exact Z offset you want. If it seems to not move in a straight line in Z after that, let me know and send in the file. Offset duplications is disabled but can't be any part of my issue. Its a 3D path i'm drawing, not copying or duplicating. I've added a 2013file: The top of the bottom pipe appears to be exact on the bottom of the middle pipe. But It isn't when I check it scriptwise The top and middle pipe are correct. There is no difference visible, but since my object is able to "couple" with others its of importance to have exactly shared points.. EDIT: This seems to appear when I Snap on distance of a loci, create a first point and place the ending point on that same Loci. ( did this for the bottom pipe ). Edited December 2, 2013 by hippothamus Quote Link to comment
Hippocode Posted December 2, 2013 Author Share Posted December 2, 2013 I ran a script to compare the begin/endpoints between the bottom and middle pipe and this is the resulting shift : Quote Link to comment
Vectorworks, Inc Employee PVA - Admin Posted December 2, 2013 Vectorworks, Inc Employee Share Posted December 2, 2013 I cant speak to the results of the script or this custom object, apologies. I didn't know this was a customized plugin object and not just the relocating of 3D loci to use in the creation of a path. Quote Link to comment
Kevin McAllister Posted December 2, 2013 Share Posted December 2, 2013 Interesting thread. I heard from someone last week that VW has an inaccuracy with the origin when directly coding an object. He told me 0,0 is not exactly 0,0 but off by some small amount like you're seeing. He hard codes solutions for a living. Not my area of expertise but Jim there may actually be a bug here. Kevin Quote Link to comment
Hippocode Posted December 3, 2013 Author Share Posted December 3, 2013 (edited) Did some more testing and I've found the issue.. and has nothing to do with the 3D loci. Picture 1-2 show in which order I'm forming the bottom pipe, trying to make a connection between the two. Picture 3 shows that they don't fit, yet the coordinates are the same. The more I think about it, it has to do something with snapping so I zoomed in on the existing pipe.. Look at the last picture 'wtf' where the midpoint of the bottom circle of my object is not the same as the isertionpoint. This is strange as the right line is the Path axis ( which can't be deleted with 3D paths ) and the midpoint is the midpoint from the nurbs (extrude along path). vw can't extrude properly, I guess that's my conclusion. Its a tiny tiny tiny shift ( zoomed max) but when you compare 2 points even that matters :'( Edited December 3, 2013 by hippothamus Quote Link to comment
Hippocode Posted February 25, 2014 Author Share Posted February 25, 2014 (edited) Its been a while and after more testing this is a snap bug. When snapping on the Z-axis a "next" vertex can be placed a tiny bit off. I'm currently using a lot of functions to bypass the problems that come with it. I havn't come up with a solution to fix it. I thought about correcting the vertex if they are off with the following script. I do get the alrt to run but can't change the vertex it seems. Does SetPolyPt3D even work on an object path ? Same for the nurbs funtion PROCEDURE Valid3Dpath(F_Obj3D :HANDLE); VAR Alert,ChangeIt :BOOLEAN; F_Path3D :HANDLE; a_vector :INTEGER; v1,v2,u2 :VECTOR; BEGIN Alert:=FALSE; F_PAth3D:=GetCustomOBjectPath(F_Obj3D); a_vector:=GetVertNum(F_Path3D); FOR i:=0 TO a_vector-1 DO BEGIN IF i <= (a_vector-2) THEN BEGIN ChangeIt:=FALSE; GetPolyPt3D(F_Path3D,i,v1.x,v1.y,v1.z); GetPolyPt3D(F_Path3D,i+1,v2.x,v2.y,v2.z); U2:=v2; IF ABS(v2.x-v1.x) < 1mm THEN BEGIN U2.x:=v1.x; ChangeIt:=TRUE; END; IF ABS(v2.y-v1.y) < 1mm THEN BEGIN U2.y:=v1.y; ChangeIt:=TRUE; END; IF ChangeIt THEN BEGIN SetPolyPt3D(F_Path3D,i+1,U2.x,U2.y,U2.z); NurbsSetPt3D(F_Path3D,0,i+1,U2.x,U2.y,U2.z); Alert:=TRUE; END; END; END; IF Alert THEN AlrtDialog(concat('Kleine afwijking gecorrigeerd tussen de vertices (',a_vector,').')); END; Edited February 25, 2014 by hippothamus 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.