extrusion.__copy__() fails if there is a material

[BruceSherwood]

The test program below shows that something is wrong in general with copy of an extrusion, related to the material. Depending on the material, the copied extrusion typically lacks the material entirely, but in some cases something else happens. In particular, for materials.marble, the copied extrusion is indeed black. There is no such problem with other objects, such as box or sphere.

There doesn't seem to be an easy work-around, as in this test program if I don't assign a material to the first extrusion, I can assign it after the copy operation, but trying to assign a material to the second extrusion fails, which is pretty strange. Evidently one should not use copy for extrusion objects if materials are involved.

from visual import * f1 = frame() E1 = extrusion(frame=f1, pos=[(-1,0,0), (1,0,0), (1,0,2)], shape=shapes.triangle(), color=[color.red, color.green, color.blue], material=materials.rough) E2 = E1.copy() f2 = frame(pos=(0,2,0)) E2.frame = f2

Note: wherever you see "copy" in bold, it's actually underscore underscore copy underscore underscore.

[BruceSherwood]

And there is a suggestion that we should support copying of entire frames.

[glarrain]

@BruceSherwood perhaps what's needed is deepcopy

import copy

...
E2 = copy.deepcopy(E1)
...

[BruceSherwood]

Nope; deepcopy fails with RuntimeError: Pickling of "visual_common.primitives.extrusion" instances is not enabled (http://www.boost.org/libs/python/doc/v2/pickle.html).

[glarrain]

I see. Didn't know the underlying object was a Boost one.

Without knowing specifics about this code I would say this is an objects references error. The method visual_common.py_renderable.__copy__ doesn't seem to take into account all the complexity existing in its constructor (which, I regret to say, is hideous).

It's kind of difficult to diagnose without code documentation. I do not understand what's the purpose of _other (nor why does it have a prepending underscore if it's a kwarg). Sorry

[BruceSherwood]

I have to admit that I myself do not know the function of the _other parameter that one finds in VPython objects, and it would obviously be good to know. I've always been in a situation where I didn't have time to study those parts of VPython that weren't broken.....

I implemented the extrusion object, which is by far the most complex and the most dynamic of all the VPython objects. If you have not already done so, I encourage you to run the example program extrusion_overview.py to see what it does. A major issue is that setting almost any of the extrusion attributes involves driving various update routines. If you see a better way to organize the constructor or other aspects, great!

I wouldn't call the extrusion object a "Boost object". Nearly all the VPython objects are implemented in C++ (with Boost used to connect to them from Python code).

Bruce

On Sun, Oct 13, 2013 at 6:44 PM, German Larrain notifications@github.comwrote:

I see. Didn't know the underlying object was a Boost one.

Without knowing specifics about this code I would say this is an objects references error. The method visual_common.py_renderable.copy doesn't seem to take into account all the complexity existing in its constructor (which, I regret to say, is hideous).

It's kind of difficult to diagnose without code documentation. I do not understand what's the purpose of _other (nor why does it have a prepending underscore if it's a kwarg). Sorry

— Reply to this email directly or view it on GitHubhttps://github.com/BruceSherwood/vpython-wx/issues/19#issuecomment-26231059 .

[glarrain]

I'm afraid right now I don't have the time to dig into VPython's internals to understand what's going on. It, almost certainly, would require a refactor, which is always dangerous to do when there is no test suite