2D Block - 3D Symbol Inconsistencies

[Joe Carrick]

Idaho, we have a problem!

Symbols allow for the 3D origin to be adjusted but the 2D_Block doesn't adjust accordingly - and it can't be fixed by recreating the 2D_Block. This results in inaccurate 2D Plans vs the Orthographic & 3D Views (Elevations, Sections, Perspectives, etc) which are sent to Layout.

When the 3D origin is modified in the General Tab of the Symbol dbx it results in the Bounding Box of the Symbol being moved. In addition, the size of the Bounding Box can be adjusted in the sizing Tab of the Symbol dbx so that it's not just the limits of the object. These are very useful tools to control how the 3D object is positioned relative to Walls and other objects in the model.

However, the 2D_Block representing the Symbol in Plan View is always located at the center/back of the Bounding Box. There's no way to change this behavior so that the Symbol and 2D_Block are consistent with each other.

Here are a couple of examples:

Toilet are typically located about 1" away from the wall so we need to set the y-origin value to -1". This causes the 3D Symbol to be correctly located 1" away from the wall because the Bounding Box stops at the wall - but the 2D_Block is right up against the wall.

A prefab fireplace or stove might require clearance from the wall behind it - maybe as much as 18" in some cases. If the Symbol origin is set to y=-18" the Bounding Box will be moved back 18" (the y size should then be increased 18" so that it's at least large enough to enclose the symbol plus that offset) but in Plan the 2D_Block would still be against the wall.

There are other cases where clearances are required on the sides or fronts of Symbols which can be accomplished by in increasing the size of the Bounding Box but if the clearances need to be different from one side to another it requires the x-origin to be something other than zero. That again means that the 2D_Block will not be in the same location as the 3D_Symbol.

CA suggests simply rebuilding the 2D_Block. This function doesn't fix the problem. In fact, the 2D_Block created from a Symbol with a Bounding Box larger than the 3D_Symbol results in a 2D_Block stretched to the extents of the Bounding Box - and it's still located incorrectly in Plan View.

It's way past time that this be fixed. The Plan View MUST be consistent with the 3D Model.

[Joe Carrick]

These things can be fixed as follows:

1. The 2D_Block should be located within the Bounding Box with the same offsets as are specified for the x,y origin of the 3D Block.
2. Re-creating a 2D_Block should be at the size of the 3D Symbol, not the size of the Bounding Box.
3. If a Symbol is resized in any way, the 2D_Block should automatically be recreated to match. (maybe that should be an option in preferences or defaults or be a setting in the Symbol dbx)

[Gene Davis]

I think a redefinition of the term "bounding box" is in order.

Scott's recent discussion and video about toilet placement and clearances is a good example of how and why the "bounding box" term ought to be called something else.

[Gene Davis]

It is interesting to look at the behavior of a dishwasher symbol. Points out how Chief has built code to handle placement of symbols, using the various options they list for symbol classes. Dishwashers are meant to mount into the front face of a base cabinet.

Place the dishwasher on the floor, no cabinet. Look at it and see how the symbol relates to the bounding box. Then place it in a cab and view again.

[Joe Carrick]

Gene,

The "Bounding Box" is actually a 3D Region that's used as a "Bump Limit". Perhaps that would be a better name but the name isn't the issue - 2D_Block and 3D_Symbol consistency of size and position is the real problem. When the 2D doesn't match the 3D then it creates problems in the CDs.

[Gene Davis]

Joe, I think "bump limit" is only in play when the symbol is a simple fixture, and it appears that bump limit has no meaning when the symbol is categorized as "fits into front of cabinet."

I'm seeing that Chief has code with rules for placement, when certain options are specified for symbols.

[gteacher]

FYI – Changing the term bounding would create a huge amount of confusion as this is the term historically (good/bad) used since the beginning of graphics on computers and simply means the area containing the graphic object. Internally, it’s required as a quick way to prevent other objects from intruding in its space and a shortcut to identify collisions and/or possible connections. Without its use, even modern computers would slow to a crawl.

Joe: you might want to take a look at Chief’s symbol “professional dishwasher” in the library. It correctly locates both the 2D and 3D symbol bounding box, although, in that case, the relocation is still in a positive direction. However, if the user tries to insert that same 2D symbol, the bounding box is generated incorrectly.

IAE, it implies that Chief is using two sets of tools – one for them and one for the rest of us. Something they have long denied doing. Whoever programed the Viking symbol for Viking just used the wrong set. It would be nice if they would just let us out of the “cave”.

[Joe Carrick]

Gerry,

Dishwashers are Special Symbols with flags set via the "Options Tab". Those flags are interpreted by the software to perform whatever adjustments are needed. For most other symbols I firmly stand by what I've said in posts #1 & 2 of this thread.

[gteacher]

Hmmmm - then what differentiates the two since the same options are set for both? Only diff is Y origin. I believe that "inserts into cabinet front" only controls the insertion point in ref to the origin in cabinets. In this respect, the two are identical. Soo what's your point?

[Gene Davis]

Chief has obviously written code that handles placements and cutouts depending on the "options" specified for the symbol. I attached a screencap of the options spec showing what it looks like for one of the dishwashers in the library, the two-drawer thing that looks like the Fisher and Paykel.

For the furniture-like symbols specified (and this is the default) "sits on floor," with no other option taken, the bounding box seems to handle bump placement, i.e., a "stops against walls and other objects" sort of thing.

But if the symbol is specified as one of the "inserts" things, some code comes into play that results in all kinds of interesting things. If the object inserts into a countertop, the 2D block needs a polyline specified as "hole in countertop" to work as expected. If the object inserts into the face of a cabinet, all the face elements of the cabinet (doors and drawerfronts) are removed in an area equal to the height of the symbol (not the height of the box sized in the sizing tab part of the symbol spec, and a cutout goes into the cabinet equal to the width specified in that sizing tab.

It is for this reason, this behavior of certain classes of symbols that cut holes and mount into objects, that I think the "bounding box" term needs some discussion.

[Joe Carrick]

Hmmmm - then what differentiates the two since the same options are set for both? Only diff is Y origin. I believe that "inserts into cabinet front" only controls the insertion point in ref to the origin in cabinets. In this respect, the two are identical. Soo what's your point?

Gerry,


Some time ago I wrote up a set of rules for how the options work. I will see if I can find it but I'm not at my main computer this week since I'm in Las Vegas exhibiting at the KBIS/IBS Show. It's probably in some post regarding Symbols and if you do a search you might find it.

As Gene says, there are various things that happen depending on what options are set. OTOH, you are correct in that the Viking Dishwasher has an incorrect origin. CA sometimes gets some things wrong

[gteacher]

I'd be interested in your list. I did several searches but came up with nothing. Chief's explanation is worthless and I doubt if the tech writer understands the process either.

So if you think about when you get back and have time, I'm sure others would also be interested.