topic Re: Unusual Behavior in Modeling

Unusual Behavior

Dwight — Fri, 26 May 2023 10:54:32 GMT

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?

Re: Unusual Behavior

Dwight — Wed, 20 Oct 2004 16:55:20 GMT

Re: Unusual Behavior

__archiben — Thu, 21 Oct 2004 05:53:08 GMT

you're 'rebuilding' after hiding the layer?

sounds like a bug to me . . . although it could be quite useful . . .

~/archiben

Re: Unusual Behavior

Dwight — Thu, 21 Oct 2004 06:00:38 GMT

Absolutely.
And repeatable.

Playing with it again, I have discovered that between walls and columns with identical intersection priorities, this masking will occur, but dissimilar priorities fixes it.

Since I am unfamiliar with this feature, I see the error now.

Are intersection priorities important to many other users?

Re: Unusual Behavior

Anonymous — Thu, 21 Oct 2004 10:52:54 GMT

Dwight wrote:
Are intersection priorities important to many other users?

Now that we have to deal with them, they are very important.

Failure to set them correctly can result in embarrassing drawings (as you have seen). The feature was added in 8.0 to correct problems with the previous automatic system, such as walls on hidden layers (i.e. demo walls) continuing to clean to visible walls.

The general rule is that any layer containing walls or columns that is hidden should also be set to a different intersection priority (in the layer combination; manually managing this is unmanageable).

Re: Unusual Behavior

Anonymous — Thu, 21 Oct 2004 14:24:36 GMT

Are intersection priorities important to many other users?

Yes. Especially for remodel jobs and you use a wall to be removed layer. Without intersection priorities the hidden walls "clip" existing or new walls that are showing in the plan.

Re: Unusual Behavior

Link — Thu, 21 Oct 2004 15:01:40 GMT

Are intersection priorities important to many other users?

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

Like locking/visibility/wireframe, intersection priority numbers are layer combination specific.

Intersection priority numbers do not increase in value (like 3D Intersection Priorities), so that a 1 is not any stronger than a 3 or vice versa. As long as the numbers are different the elements on that layer will not heal with elements on a layer with another intersection priority number.

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. Attached is an image of what I am talking about. It has also has a recess subtracted by a red column.

Cheers,
Link.

Re: Unusual Behavior

Karl Ottenstein — Thu, 21 Oct 2004 19:25:10 GMT

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.

Ah, Link my man! That deserves a tip-of-the-month! If this feature is documented, I never noticed it ... but I've wondered why sometimes I couldn't get the "inherit attributes of operator" to work and other times it did. Thank you!

Karl

Re: Unusual Behavior

Karl Ottenstein — Thu, 21 Oct 2004 19:49:36 GMT

Dwight wrote:
Are intersection priorities important to many other users?

Really important. Without them, I'd have to use the patch tool quite a bit to get my drawings to look right. (If I used composites more, I'd still have to use the patch tool, but that's another story....)

Karl

Re: Unusual Behavior

Link — Fri, 22 Oct 2004 14:54:02 GMT

Ah, Link my man! That deserves a tip-of-the-month! If this feature is documented, I never noticed it ... but I've wondered why sometimes I couldn't get the "inherit attributes of operator" to work and other times it did. Thank you!

Thanks Karl. It seemed like a little find, in the grand scheme of things! Sometimes I submit posts that I find extremely valuable and no one blinks an eyelid. Then times like this when I flop in front of my laptop, before my morning coffee, and tap out a sleepy wake up post, it turns out to be pretty useful. Ahhhh - this is the beautiful thing about ArchiCAD-Talk. You never know what your going to get!

I always enjoy your posts, so it's a pleasure to return the favor once in a while! Hope all is well up north and you get to attend Robert Bissett's Art Gallery opening. That guy just keeps impressing!

Best regards,
Link.

Re: Unusual Behavior

__archiben — Sat, 23 Oct 2004 08:28:17 GMT

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

Re: Unusual Behavior

Anonymous — Sat, 23 Oct 2004 13:31:32 GMT

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.

Re: Unusual Behavior

Link — Sat, 23 Oct 2004 16:25:12 GMT

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.