Jump to content
  • 2

Graphical difference compare between two files


Wesley Burrows

Question

8 answers to this question

Recommended Posts

  • 0

Yes. BlueBeam do this with PDF.

VW can recognize coincident objects so it's not a stretch to identify non-coincident objects.

You can compare contents of design layers by assigning them with a color & an opacity of 50% and viewing both at once.

Eg DL 1 - Blue 50%, DL 2 -Red 50% coincident = Purple, everything else is new/removed.

Link to comment
  • 0

As bcd mentioned, Bluebeam uses this with PDF files, which is the route I take for comparing two files (create a PDF from both files and then use Bluebeam's comparison feature).

 

It would be nice if Vectorworks would have such functionality as long as it is user controllable for what it compares, e.g. compare specific design layers, or skip specific design layers of which you know they will be identical and contain lots of objects. If it has to compare two drawings each having 1 million+ objects and lots of layers and classes then you really need a fair degree of control of the comparison settings to avoid this feature eating away your work time.

Link to comment
  • 0
12 hours ago, Matt Overton said:

I love to also do this within a file. Have Viewports highlight changes since last update/refresh/issue. If only for visual highlighting to make sure things are done.

You mean open a file, make edits and then have it highlight those edits compared against the last save within the active file?  It might be possible to do that but I'd guess it will come at the expense of increased memory requirements unless VW takes a snapshot and saves that as a temporary file during the session to use for comparison.

Link to comment
  • 0
10 hours ago, Art V said:

You mean open a file, make edits and then have it highlight those edits compared against the last save within the active file?  It might be possible to do that but I'd guess it will come at the expense of increased memory requirements unless VW takes a snapshot and saves that as a temporary file during the session to use for comparison.

 

Don't rendered viewports already snapshot model data so they can background process. Then they get flagged if there are changes that may effect them. However the interface is very crude and only presents dirty not dirty.

 

Also most of the modern file systems use block copy-on-write to improve data security. This also means the system can produce two or multiple versions of the same file and the storage size cost is only the differences.  Expose versioning in the interface and we cut down on redundant copies we keep just in case, each having a fully redundant copy set of the common data plus the changes.

 

Given we already have a way of flagging important milestones within Vectorworks (titleblock issuing) the system would have the information it needs to purge versions between milestones and keep size contatined.

 

In short I don't think the technology is the limiting factor here.

Link to comment
  • 0
14 hours ago, zoomer said:

But for normal file comparison only,

wouldn't that work by using Layer Colors.

Set one Files Layers to Green, the others to Red :

=>  Same data = Yellow

=> Different in File 1 = Red

=> Different in File 2 = Green

 

Not ?

 

Or via Viewports ?

Yes, Bluebeam uses two methods of document comparison:
- Comparison, where it marks-up the differences with transparent clouds of a certain colur

- Overlay where you can overlay different documents and indicate the differences with colours for each file, e.c. red and green (though you can set them yourself), one colour for File 1 and the other for File 2 (and additional colours for additional files)

For PDF files it is a bit easier as you are only looking at the output. For Vectorworks files I can imagine it may be a bit more complex as you should be able to set what differences to look for (e.g. geometry only or also attached record contents in case the geometry has not been changed but the data in the attached record has).

Link to comment
  • 0
4 hours ago, Matt Overton said:

 

Don't rendered viewports already snapshot model data so they can background process. Then they get flagged if there are changes that may effect them. However the interface is very crude and only presents dirty not dirty.

 

Also most of the modern file systems use block copy-on-write to improve data security. This also means the system can produce two or multiple versions of the same file and the storage size cost is only the differences.  Expose versioning in the interface and we cut down on redundant copies we keep just in case, each having a fully redundant copy set of the common data plus the changes.

 

Given we already have a way of flagging important milestones within Vectorworks (titleblock issuing) the system would have the information it needs to purge versions between milestones and keep size contatined.

 

In short I don't think the technology is the limiting factor here.

I agree that technology is probably not the limiting factor, the question is if Vectorworks already  contains enough of the necessary functionality to easily implement it.
 

In my case file size and redundant copies are not the issue. If versioning is implemented I need to be sure it does it properly for my needs before I'm willing to do away with redundant copies (and the associated auto-backup files) for certain types of projects.

Edited by Art V
  • Like 1
Link to comment

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.

×
×
  • Create New...