Copy will typically be slower when the type is a value type. But more important is that you are aware of that if you update the copy (i.e “pt0” in your code above), that doesn’t mean that you have updated the value in
Pts. This may be a problem if you plan to use the point in the list (
Pts) later in your code, and expect that it has been updated if you update the
Look at the following picture. It shows the output of
pt0 after all the values of pt0 are set like so: (1,1,1) while Pts keeps it’s original values, which is (0,0,0):
And here’s the test code snippet so you can se for yourself what result you (may) expect, and the actual result (pictured above) :
private void RunScript(ref object OUT_Pts, ref object OUT_pt0)
var Pts = new List<Point3d>();
Pts.Add(new Point3d(0, 0, 0));
// Now copy the point
var pt0 = Pts;
// ... and modify its value
pt0.X = 1;
pt0.Y = 1;
pt0.Z = 1;
// and compare the two if they still are equal
OUT_Pts = Pts;
OUT_pt0 = pt0;
At the moment I don’t have the time to look deeper into your code (but someone else may have an extra minute or two), but check your code if you have this bug (expecting to have updated point residing in a list while the changes were made only on the copies).
If you did this mistake I say only; welcome to the club. You’re not alone.
In any case, you asked about copying values. Feel free to do so, but watch out for making copies of value types if a copy is not what you expect (Point3d is not a class, it’s a struct, which is a value type, and thus it gets copied, not referenced).
Regarding copying Meshes, I most often copy meshes like so:
var meshcopy = OriginalMesh.DuplicateMesh();
That’s equivalent to this:
Mesh meshcopy = OriginalMesh.DuplicateMesh();
… but the compiler will figure out that the
DuplicateMesh() command will return a
Mesh type, and so the “
var” will actually become a Mesh.
Same thing with the first example above; the compiler deduces that “
pt0” needs to be a Point3d.