Jump to content
  • 0
line-weight

Paste-in-place into symbols - unexpected results

Question

I'm aware there are various issues with symbols (and other containers) and internal origins and so on. But I'd like to know if the following is something that's not working properly, or the error is mine.

 

I thought that if I

 

(a) create a symbol

(b) leave the original instance in place

(b) specify the insertion point of that symbol as the drawing origin 0,0,0

 

Then

 

(a) that instance of the symbol should have its internal origin in the same location as the drawing origin.

(b) therefore copying something from outside of the symbol container, then doing a paste-in-place within the symbol, should result in that object staying in the same location

 

Is all of that correct? Because sometimes the paste-in-place ends up with the object somewhere else, and I can't work out why.

Share this post


Link to post

7 answers to this question

Recommended Posts

  • 0

Based on my limited testing, it appears that you are correct. I don't know why they are shifting part time for you.

 

If I Paste In Place into a symbol, the object gets pasted relative to the symbol 0,0 the same as it was to the drawing 0,0 point. The reverse when I copy out of a symbol definition and paste in place into the drawing.

 

All of this was only test in 2D in Top/Plan with very simple symbols.

Share this post


Link to post
  • 0
4 hours ago, Pat Stanford said:

Based on my limited testing, it appears that you are correct. I don't know why they are shifting part time for you.

 

If I Paste In Place into a symbol, the object gets pasted relative to the symbol 0,0 the same as it was to the drawing 0,0 point. The reverse when I copy out of a symbol definition and paste in place into the drawing.

 

All of this was only test in 2D in Top/Plan with very simple symbols.

 

Ok... thanks for the reply.

 

For me it's been happening in 3d space.

 

Might see if I can post the relevant file here if I get time.

Share this post


Link to post
  • 0
On 1/14/2020 at 11:38 AM, line-weight said:

I'm aware there are various issues with symbols (and other containers) and internal origins and so on. But I'd like to know if the following is something that's not working properly, or the error is mine.

[...]

Is all of that correct? Because sometimes the paste-in-place ends up with the object somewhere else, and I can't work out why.

 

When creating the symbol or copy/pasting the object was the user origin aligned with the internal origin for both? I know that in theory it should be relative to the active origin for both but it could be that the internal origin/user origin not being the same might be a factor to take into account.

 

Were both objects in the same top/plan view mode? If one was in rotated top/plan and the other was not it could explain some coordinate issues if the user coordinate system was not aligned with the rotated top/plan view, because the coordinates would then be different compared to non-rotated plan view though the relative location would be the same but when pasting from a rotated top/plan to a non-rotated top/plan the relative positions would no longer be the same.

 

Is the positional mismatch only in the X/Y plane or in any plane?

Share this post


Link to post
  • 0
2 hours ago, Art V said:

 

When creating the symbol or copy/pasting the object was the user origin aligned with the internal origin for both? I know that in theory it should be relative to the active origin for both but it could be that the internal origin/user origin not being the same might be a factor to take into account.

 

Were both objects in the same top/plan view mode? If one was in rotated top/plan and the other was not it could explain some coordinate issues if the user coordinate system was not aligned with the rotated top/plan view, because the coordinates would then be different compared to non-rotated plan view though the relative location would be the same but when pasting from a rotated top/plan to a non-rotated top/plan the relative positions would no longer be the same.

 

Is the positional mismatch only in the X/Y plane or in any plane?

 

Hm - it seems that the internal origin and user origin are not aligned, and it looks like this is the cause (judging by the offset).

 

I had not changed the user origin myself - but something must have happened when I imported a DWG file.

 

Thinking about it - in another file where I've been having similar problems, I had set the user origin myself (I think).

 

Is this therefore a bug?

Share this post


Link to post
  • 0
2 hours ago, line-weight said:

Is this therefore a bug?

Not necessarily...

 

e.g. I ran in to an issue when importing a dwg file where they had not only moved the UCS (user origin) but also rotated it. Apparently VW is using the WCS (= VW internal origin equivalent) when importing the DWG file, so the imported file would end up at the wrong coordinates. The probable reason for this is that the WCS/Internal origin is hardcoded and therefore a (fixed) reference point you can rely on.

 

My guess, without having extensively tested anything yet, is that the copy/paste is using the internal origin as reference as that is the only fixed coordinate point in VW because it can't be changed.  Based on one quick simple test where one object is at internal origin and one object at 0,0 of user origin offset from internal origin: when all objects are relative to internal origin (i.e. user origin and internal origin align) then things end up where they are supposed to end up. When the user origin is offset things end up relative to the internal origin anyway and not use the user origin (i.e. something on 0,0 of user origin will not end up at the 0,0/internal origin of the symbol).

 

Things like this, and also because of my use of GIS, make me a proponent of keeping the user origin aligned with the internal origin unless there is a very very good reason to do otherwise. Doing so should avoid most of the surprises related to origins/coordinates.

Edited by Art V

Share this post


Link to post
  • 0
2 hours ago, Art V said:

Not necessarily...

 

e.g. I ran in to an issue when importing a dwg file where they had not only moved the UCS (user origin) but also rotated it. Apparently VW is using the WCS (= VW internal origin equivalent) when importing the DWG file, so the imported file would end up at the wrong coordinates. The probable reason for this is that the WCS/Internal origin is hardcoded and therefore a (fixed) reference point you can rely on.

 

My guess, without having extensively tested anything yet, is that the copy/paste is using the internal origin as reference as that is the only fixed coordinate point in VW because it can't be changed.  Based on one quick simple test where one object is at internal origin and one object at 0,0 of user origin offset from internal origin: when all objects are relative to internal origin (i.e. user origin and internal origin align) then things end up where they are supposed to end up. When the user origin is offset things end up relative to the internal origin anyway and not use the user origin (i.e. something on 0,0 of user origin will not end up at the 0,0/internal origin of the symbol).

 

Things like this, and also because of my use of GIS, make me a proponent of keeping the user origin aligned with the internal origin unless there is a very very good reason to do otherwise. Doing so should avoid most of the surprises related to origins/coordinates.

 

It seems to defeat the purpose of offering the 'user origin', if stuff like this starts happening though. It seems like a bug to me - unless there is some good reason for it to work this way.

Share this post


Link to post
  • 0

It could be a bug, it could be working as intended but not as most people would expect it to behave. I guess @JuanP or one of his colleagues would have to answer that.

Share this post


Link to post

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.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×
×
  • Create New...