[Wynott]

Seems to me the lightweight block seen in the viewports doesn't change layers until you change the style from nurbs to point cloud and back or whatever.

[Wynott]

Wait hold off. Working now. Need to figure out what I did.

[kami]

Yeah, it's a bit weird. Since the 'block instance' itself can sit on one layer and the point cloud (or mesh) it generates will be put the active layer if you change the display type. A bit dangerous since it will not show up in the render if either of those layers is turned of.

[JDHill]

I believe the problem is rather the opposite of that: it is possible for an MXS reference to be rendered, even when you can't see its representation (i.e. point cloud, etc) in the viewport. Specifically, this would happen when you hide the layer of the point cloud, but not the layer of the MXS reference. The same thing would happen in normal Rhino use, but you just wouldn't notice, since an instance of a block containing only hidden geometry, while not actually being hidden itself, is also effectively not visible.

In order to emulate that perceived behavior, in the next build, I am scanning through all the geometry in the MXS reference's definition, and not exporting instances of it if nothing in the definition is visible. I'm not yet certain whether this might possibly produce other confusing situations, but I don't think so.

[Wynott]

OK Not sure I'm quite understanding what's happening here.

When I select a point cloud, and change it's layer... The MXS reference is changing layers too, right?

Hypothetically how would one get the MXS reference and the representation point cloud onto different layers?

[JDHill]

When you create a new MXS Reference, the plugin does two things: it creates a new block definition, and it inserts one instance of that definition. Inside the block definition, it creates a point cloud (or set of wire frames, or NURBS surfaces). Changing the layer of a block instance does not affect the geometry in its definition; it is no different than if you were to:

• a) Draw a box.
  b) Block it (this creates a block instance).
  c) Change the layer of the block instance.

The instance is on a new layer, but the box is not; you could hide it (what you see in the viewport as a box) by hiding either the layer of the box, or the layer of the block instance. When you do the former, the instance is not hidden, but you have no way of detecting it's still there, since with the box's layer hidden, its definition doesn't contain any visible geometry. When that instance is an MXS Reference, though, you do have a way of detecting it: by rendering the scene.

[Wynott]

So I'm confused why we're generating the point cloud on the active layer instead of the same layer as the block?

[JDHill]

There is not really any such concept as putting them on the same layer, since every instance can be on its on its own layer. Insert a new MXS Reference, make ten copies of it, and put each of them on a different layer; if you then update the point cloud detail, which layer should be assigned to the newly-generated point cloud? You could check the layer of the old point cloud and use that, you could check the layer of the instance that happens to be selected and use that, or you could put it on the current layer. The plugin happens to choose the last, but I don't think one answer is necessarily better than another. One thing, though, is that the plugin does not mess with the geometry in the definition, except when you change the proxy type or detail, so if you want it on a particular layer, you can use BlockEdit to put it there (or even add other proxy geometry -- nothing in the reference's definition will be exported), and it will stay put, unless you update the proxy.

[Wynott]

OK sorry to keep going on about this but I must be missing something fundamental. Let me describe a simplified fictional scenario and maybe you can clear up how I would approach this...

Let's say I'm designing an office building. I want each floor of the office building on a separate layer so I can toggle them and quickly see each floor plan in the top view.

All the floors use the same desks. So I have a desk model which I export as a MXS file.

I fill each floor with desks. I put them on their corresponding layers (1st floor, 2nd floor, etc). All the point clouds are on the layer that was active when I created the first MXS reference, so my layer toggling organization for quickly viewing each floor doesn't really work. It's not possible to have each floor's point clouds on each floor's layers as I understand it now.

Is it possible to achieve what I'm describing? I think by having a dedicated "point cloud" layer that is top-level and never gets hidden I can always generate the point clouds on there and then should avoid issues and have the desired functionality in terms of layer toggling... But this seems like a bit of a clumsy workaround rather than the intended method with these things.

[JDHill]

All the point clouds are on the layer that was active when I created the first MXS reference. [...] It's not possible to have each floor's point clouds on each floor's layers as I understand it now.

The problem with these statements is that there is only one point cloud; each copy of the MXS reference is an instance referring back to the same definition.

I fill each floor with desks. I put them on their corresponding layers (1st floor, 2nd floor, etc). All the point clouds are on the layer that was active when I created the first MXS reference, so my layer toggling organization for quickly viewing each floor doesn't really work.

The problem is actually the reverse of this. Let's consider this simplified scenario:

• 1. Create a new 3DM.
  2. Create a layer "X" and make it current.
  3. Insert a reference to desk.mxs.
  4. Make one copy of the new reference.
  5. Create two new layers, "desk1" and "desk2".
  6. Put the first instance on layer "desk1".
  7. Put the second instance on layer "desk2".

What is rendered, if you hide layer "desk1", "desk2", or "X"? With layer "desk1" hidden, only the instance on layer "desk2" renders, and vice versa, as expected. However, if you hide layer "X", this is where the unexpected behavior occurs: since the point cloud created in step 2 is on layer "X", both desks disappear from the Rhino view when you hide "X", but when you render, both of the desks still render. Reason being, though the instances created in steps 3 & 4 are not hidden, the geometry (the point cloud) in their definition is.

So the problem is not that you can't selectively hide all the desks on a given floor, but rather that it's possible to for you to hide all the desks from view in Rhino, but still have them render in Maxwell. This won't happen, though, as long as you don't hide the point cloud's layer.

Another way of looking at this would be to consider how By Parent and By Layer work for the color and material of instances and their definitions. If you look inside the MXS Reference definition, you'll find that the color of the point cloud is set to By Parent, such that each instance can appear to have its own color, or inherit the color of its layer. However, were you to use BlockEdit to change the point cloud's color to By Layer, you'd then find you had the same "problem" with the color of the point cloud: regardless of the color you assigned "desk1" or "desk2", the cloud would continue to use the color of its actual layer, "X". The only real difference between this, and layer visibility, is that there is no such "By Parent" mode for an object's layer.