Parametric Cell placement issues with custom line styles

Hi Cory,

Thank you for reporting.The line style issue you pointed out is a known issue and is tracking with Defect 1037945. We have fixed it and change will be available in next update, along with some other enhancements about parametric cell levels.

Regards,

Grace

Oddly, when I open up the original Cell library the original problem (Defect1037945) still persists.

Hi Cory,

Would you mind sharing the original Cell library file? We'll take a look.

Regards,

Grace

Here's the cell library file. I should also reiterate that this issue is in OpenBridge Modeler 10.08.2.45 which should be using Power platform 14. If I'm not mistaken, that should be based on the most current version of Microstation Connect yes? if not, then maybe the issue is that the versioning is still behind any fixes that have been made to MS Connect._WSDOT_Girders.cel

Thanks for the file and all the other information, Cory.

We fixed defect 1037945 and also implemented some enhancements about parametric cell levels in Update 15. With those changes, when placing parametric cell, the cell display will use the level symbology(color, line style and line weight) defined in the definition(library) file.(Previously it uses the active level symbology), this requirement came from some users and also it will be consistent with normal cell and shared cells. The fix will also be available in Update 14 escalation release build. In your cell library file, the shape profile is on Default level, please select a different level then place it as cell in new dgn file, if you see the parametric cell display is consistent with what it's in the cell library file, that means the changes are in your build, otherwise, please wait for next update to check.

I tried placing your file as cell, didn't see the Cannot selection problem you mentioned earlier, but when checking your cell library file, I did see there is something wrong with level having custom line style, because it's not related to parametric cell place, can you please create a new post for it for better tracking?

Regards,

Grace 

Alright, I'll go ahead and create a new post to help better track this issue. I will say I did what you said and it still did not work. I will also point out (and maybe I misunderstood you) that I want the cell to take on the active cell attributes as these cells may be placed on different girder levels that we use (such as new or existing) and I wouldn't want to have to create the same cell multiple times just to be able to use different levels. From what I understand above, the new enhancement removes that capability and forces the cell library to carry the level?

Hi Cory, making parametric cells to honour the bylevel symbology of their contents - and not forcefully taking up all the settings of the level they are placed on - was one of the most asked change from our user base (and of that of other Open products') in this product area.

The vast majority of our users would work with catalogs where each component has been defined with either bylevel or per-element symbology and the need is for these standards to be maintained when the cell is placed in the design file as both the cell libraries and the design file generally follow the same standards. This behaviour is also now aligned to that if other types of cells.

The cells display status can be toggle on-off for the whole part through the level onto which the cell is placed on but you can also control the display status of the cells sub-components through their own levels.

I am not sure I understand correctly but the cell can still be placed on a level but it won't change its definition symbology to that of the active level of the design file. In this case you need to have two copies of the girder box, one for the "existing" and one for the "new" levels with the correct symbology, This could be done by importing the levels in the cel file and simply applying the right level to each model.

Hi Cory, making parametric cells to honour the bylevel symbology of their contents - and not forcefully taking up all the settings of the level they are placed on - was one of the most asked change from our user base (and of that of other Open products') in this product area.

The vast majority of our users would work with catalogs where each component has been defined with either bylevel or per-element symbology and the need is for these standards to be maintained when the cell is placed in the design file as both the cell libraries and the design file generally follow the same standards. This behaviour is also now aligned to that if other types of cells.

The cells display status can be toggle on-off for the whole part through the level onto which the cell is placed on but you can also control the display status of the cells sub-components through their own levels.

I am not sure I understand correctly but the cell can still be placed on a level but it won't change its definition symbology to that of the active level of the design file. In this case you need to have two copies of the girder box, one for the "existing" and one for the "new" levels with the correct symbology, This could be done by importing the levels in the cel file and simply applying the right level to each model.

Unfortunately, the parametric cells aren't taking on ANY level attributes, whether they are assigned within the cell, or if being placed on an active level, it will come in with everything set to "0". Other cells seem to work either way. I can set levels and styles within the cell OR I can set everything to "by level" and it will take on the active level attributes of the level I place it on. that's the way it SHOULD work. But if you are saying that I need to make multiple versions of the same cell library in order to place them on different levels, that  creates maintenance and change management issues as now if parameters or variants of certain cells change, rather than change it in one library, I have to change it in 2, or 3, or 5 different libraries. Levels shouldn't dictate geometry, only style and visibility. Unless I'm misunderstanding things here. I would imagine that if the level attribute defaults in the library are set to "(by level)" they should take on the active level attributes when placed, otherwise if attributes are defined in the level, they should retain that when brought into a dgn. 

Hi Cory, the only scenario where the behaviour you describe happens for graphic cells (and not for Parametric) is when the cell is completely drawn on the "default" level. If the cell is drawn on any other level then the bylevel symbology of the cell is retained when placed in the active file. Parametric Cells do not use this "default" behaviour as there was no request for it and I am not even sure it is 100% correct for graphic cells. Definitely the previous parametric cell behaviour was not satsifying the vast majority of our users and had to be corrected.

Are all your libraries created using all geometry on the "default" level?

Thanks

Everything was built on the default level. However, the problem still persists even if I pre-set the levels in the cell model. I guess this raises the question then, why can't the cells be built to have any geometry set to (by level) take on the active level attributes on placement and anything pre-set in the cell itself remain static? again, I think it's highly inefficient and honestly, approaching things the wrong way to have to build multiple cell libraries of the same object just to be able to place them on different levels. I guess I should specify why I am using parametric cells over graphic cells. we have multiple configurations of similar objects such as bridge girders or traffic barriers that change in height or general size but maintain the same shape. an existing WF58 girder and a new WF58 girder are the same exact thing, just one is already on the existing bridge, and one is being added to an existing or a new bridge. there are times when during design our engineers may have to resize the girders because we may have to increase the span due to geotechnical concerns. in that case you can select the cells that are already there and in the properties, select the variation and the all update, rather than deleting them and bringing a new cell in. It's all about efficiency. 

Cory, the bylelvel setting of the cell elements, in their definition model, refers to the level setting in the same model, not to that of the file they will be placed into. It has been working this way for a long time and I guess is because in the majority fo cases, when creating librareis, these will have cell elements on proper levels (not everything on Default) which also include the standard symbology and the requirement is for this to be persisted in the design files they will be placed into. As I said, the only difference we can see now between the behaviour of graphic and parametric cells is when the whole cell is drawn on the "Default" level. We haven't heard any specific feedback on this until now nor any request to reisntate the previous behaviour. I am glad you are using parametric cells, I can't say the previous behaviour was right but I understand it somehow fit the way you have been working and we will see if there is something we can do about it.

This post got a little bit longer, so if you do not want to read the whole background story, the main proposal to the discussion is in the second part after the horizontal split.

Background and behaviour that I do not in Update 14:

So I finally upgraded to update 14 (in the background of OpenPlant Modeler Update 8) and can join this conversation now with all the latest "improvements" in the field of parametric cells.

What really bothers me is that graphic cells and parametric cells behave differently regarding the symbology.

Marco, you are right, regarding the initial placement of graphic cells.
When something in the cell-lib is laying on the default level it gets moved to the active level when placing a graphic cell.
This is the first point where the behaviour of the two cell types differs.
If you place a parametric cell where something in the cell lib is on default, it stays on default when placing and it does not move to the active level.

For my example I use 3 different lines. All of them have the color, linestyle and lineweight set to "by level".
The left one is laying on the "Default" level in the cell-library, the other two are lying on other levels with different color and linestyle.
Default in my case has the color "0" so it is white.

When I place these lines as a graphic cell on a green level, the "Default-line" gets moved to this green level and takes the symbology.
When I place it as a parametric cell the "Default-line" stays on default and does not take the active level.

The second point where the cell types differ is when you move the cells, after they have been placed in the file.
For this example I copied both cells (graphic and parametric) and moved them to a pink level.

Now all of the elements in the graphic cells take on the symbology of the pink level and the parametric cell does not change.
That behaviour has been different in previous versions. The parametric cell would take the level symbology for every object that was set to "by level" in the cell lib.
What I did not like about the old behaviour was: If you wanted to have centerlines in your cell, you would have to make these lines independent of any level symbology and you were not able to change the look of the centerlines afterwards via changing the level symbology.
I understand that this has been changed and I think it is good. With this behaviour centerlines can stay on a centerline level and the symbology of these can be altered, even if the parametric cell is used on different levels.

What I do not like and this has to changed again: I have to make several version of a parametric cell in the cell-lib, with the exact same parameters, for every level I want to put them on afterwards.

Proposal:

As Cory already wrote, there will be situations where the "status" of the cell and its symbology have to change during engineering. Planned vs. existing. Hidden vs. visible. Concept 1 vs. concept 2 and so on...

So my proposal would be: Make use of the special behaviour of the default level.
What I would imagine is: Everything that is drawn on any other level than default in the cell library, keeps its symbology. May it be "hardcoded" symbology or by level symbology.
Now the twist: Every object that was drawn on "default" in the cell-lib will take the symbology of the level the cell is placed on.

And additionally: When dropping the cell the "default-objects" keep the symbology of the layer and are not "moved" back to the layer they were drawn on in the cell lib.

This way I can predefine certain geometry in my cell-lib or catalog to have the same look throughout my files, but I can use the default level to have geometry which can switch its symbology regarding to the level the cell is on.
In our usecase that would be hidden lines vs visible lines in many drawings. I would have the centerlines predefined in the cell-lib on a centerline level but the main geometry would be on default. When placing the cells I would move them to the visible-edges level or the hidden-edges level but the centerlines would stay as centerlines everytime.

And when I want to send the customer a dwg and the parametric cells will be dropped the hidden lines would stay as hidden lines and the visible as visible lines.