Unusual Behavior

[Dwight]

I'm just learning the annoyance and liberation of solid fills within elements.

The following two images show a column placed, and then the column layer is made invisible.

While the 3D is correct, the plan remains masked.

Am I doing something wrong?

[__archiben]

Link wrote:
The consequence of these intersection priority numbers are important in Solid Element Operations. Lets say for example you use a white beam (or any other 3D non-wall element) to subtract a recess out of a brick wall. To make it a white recess, you would set the SEO subtraction so that the 'New Surfaces of Target will: Inherit Attributes of Operator'. However, if the layer of the beam has the same intersection priority number as the layer of the wall, the recess will still appear as brick. You will need to change the intersection priority number of one of them (say the beam) to get the recess to show up white.

link, link, link!

where were you a couple of weeks ago when i was struggling over just this problem! i gave up then. i think i'll have to re-open the case . . . i was trying to get an object i'd built to subtract from a wall and give the wall it's properties. just wouldn't work!

thinking this through logically, though: if the intersection priority is different the SEO shouldn't theoretically work anyway, should it???

~/archiben

[Anonymous]

Link wrote:
They are VERY useful! To add to Matthew's post, some other important things to note are:

Thanks for expanding on my brevity. You have just reminded me that I ran into this behavior with the SEOs a while ago (in 8.0 as I recall) and to me it seems a bug rather than a feature. Since the SEO has the ability to define the inheritance of material settings, the intersection priority is just an added annoyance.

Overall the intersection priorities seem like a first draft solution to fixing the wall intersections. It is a further attempt to stretch the limited concept of layers to accommodate the organization of the virtual building.

I am hoping this improves as we go forward.

[Link]

link, link, link!

where were you a couple of weeks ago when i was struggling over just this problem!

Of all the people.... you can always feel free to bounce things off me, via email, mate.

If this feature is documented, I never noticed it ...

You have just reminded me that I ran into this behavior with the SEOs a while ago (in 8.0 as I recall) and to me it seems a bug rather than a feature. Since the SEO has the ability to define the inheritance of material settings, the intersection priority is just an added annoyance.

I agree with you on the annoyance issue Matthew! I don't see why we should have to allow for layer intersection priorities when doing solid ops, and (even though it is early on a Saturday morning), I can't see how not using this function would be a problem. However, I just checked the Help menu, (ArchiCAD 9 Reference Guide > Techniques > Solid Element Operations > Restrictions and Remarks), and it would indicate that this is not a bug, but actually by design:

-------------------------------------------
Restrictions and Remarks
Roofs participating in Solid Operations will behave as any other elements, unlike when trimming elements to Roofs.

Bypass automatic intersections: Solid Operations do not affect the results of automatic intersections, for example those created with Walls and/or Columns, if they are included in the same Layer intersection group. Before performing a Solid Operation on such elements, change the Layer intersection number of one of them.
For a detailed description, see "Layer Intersection Group".


Beams: If you intend to apply an operation between Beams, the Operator must have at least the same 3D Intersection Priority number as the Target. If the Target's priority number is higher, the operation will appear to have no effect.
For a detailed description, see "Beams and Other Elements".

Nested operations: If the desired shape can be only be obtained through a number of nested operations, pay attention to the order in which you apply them. For example, an Operator element may affect a Target that is also an Operator affecting another Target, and so on.
-------------------------------------------

Overall the intersection priorities seem like a first draft solution to fixing the wall intersections. It is a further attempt to stretch the limited concept of layers to accommodate the organization of the virtual building.

I am hoping this improves as we go forward.

Me too!

Cheers,
Link.