Hi,
I have imported a complex object from a newer version of the project file and wonder if its any different from the previous version.
rather than have to use the Mk 1 eyeball and run a spot the difference contest, can we not select two objects and have a command that shows any differences in red ?
Compare
Cheers
Steve
There is no such native Rhino command that I am aware of.
SelDup will select perfect duplicates.
SelShortCrv will select curves below a specified maximum length.
Hi John.
Thanks.
oh dear.
Such would be very useful at times.
having to visually look for differences is a little old fashioned and unreliable with such high end progs.
Are there any clever souls out there who can do a comparison script or something ?
Steve
You could color the new object(s) to facilitate visual inspection. Boolean operations might be useful if they are solids.
It would be helpful if you have an idea of what differences you want to measure. Volume? Area? Curvature? Patch count? Bounding box dimensions? The are many metrics you can extract from the geometry of the object.
So I guess that should tell you if they are identical, but won’t be of much help identifying the differences if they aren’t.
Several years ago I made a topic to request including the date and time of original creation and date and time of last modification of Rhino objects (obviously, not ones imported from other programs or file formats) in their properties. That way, Rhino users would be able to easily compare even almost identical objects that were last modified several seconds apart. However, my idea was scrapped.
Hi,
Bobi that would be so useful.
Do those scrapping ideas work with Rhino doing actual work against deadlines and really complex work.
They wouldnt scrap such a useful idea if they did.
date and time or original creation and date and time of last modification of Rhino objects
I vote for that idea.
lets see how many others do so.
meanwhile allocating a different colour is useful, but surely Rhino could show differences in red or something.
Voting for Bobi idea begins.
Steve
I vote for my idea, too. 
The ability to compare objects would certainly come in very handy in a lot of situations.
The date proposal will increase the storage required for every object, slowing performance on every operation and swelling file size noticeably.
A much better option, IMHO, would be to supply an object comparison tool in the spirit of WinMerge or the file comparison tool in Visual Studio 2022 which can be invoked only when necessary and would not require any additional storage in the .3dm.
I’m not a programmer, so I’m asking out of curiosity (no kidding at all). How much slower will be a join command that reads the date of creation and modification of 10 input objects and then only remembers the date of creation of the oldest input object and the date of modification of the resulting single polysurface (meaning it deletes the date properties from the test input geometry after the join is complete)?
My 10-year old PC from 2014 has:
Intel Core-i5 4460
16GB (4x 4GB) of DDR3 RAM
256 GB Sata 3 SSD
Nvidia GTX 1660 Ti
As far as I know, Rhino already stores plenty of information for every single object and that does not have a noticeable impact on the performance. How much slower will be Rhino when dealing with several extra numbers for the date and time that only update after completing certain commands that modify the geometry (like joini, scale, move etc)?
Maybe the extra data with time of object creation and last modification stored to each object it will not impact the performance and file size in a noticeable way? 