Parametric Cell placement issues with custom line styles

Hey all,

I'm working on creating some parametric 2D Cells for our detailing environment in Microstation Connect. I have the cells functioning properly, but I have run across an issue in placing them. I have noticed, unlike other cells, they don't take the active element template properties, and will only take the level name and color properties but will not take the line style properties when placed. I also noticed that if I use a custom line style other than the "out of the box" line styles Bentley provides, I am not able to select the parametric cell once placed. The only way to select it is to press Ctrl A. However, if I place it using any other element template or level with a default line style, I can select it and change it to the level I need with a custom line style and it works just fine. The issue only comes upon placement of the cell

Is anyone else having this issue? I'm trying to determine if I set something up wrong of if Bentley has yet another bug in their product. 

Parents
  • 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.

  • 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. 

    -------------------------------------------

    Currently using:

    OpenPlant Modeler - Version: 10.09.00.74

    [MicroStation - Version: 10.14.02.01]

  • Your proposal is 100% the functionality I would love to see. Thanks for the input here!

  • Not sure this proposal solves much. If I understand Cory's requirements, he needs to be able to place the same P-Cell on different levels depending on the particular need.

    This would work if the all the components of the P-Cell were on the same (Default) level and have the same symbology requirements. But the centreline example shows tha this will often not be the case. The beam would inevitably have connections or other components that will need to be on different levels. These attributes will also need to be re-mapped when the P-Cell is placed.

    Locking the symbology on the non-default levels to what is in the remote cel-lib sounds a bit too clumsy. At some point, I can see someone downstream needing to change the symbology. There is also the question of DWG mode compatibility.

    For ByLevel to work as a means to globally control symbology, you need a separate level as a 'key'. This kind of CAD level / layer way of organising things have their limits. Maybe it time to bite the bullet and look at using Element Templates to organise attributes.

    You should be able to retain the geometry and map the level etc attributes by changing the active Element Template when placing the P-Cell...??

    Each element can be assigned a generic ET: Beam, Connection, Centreline, Placement Point etc.

    The Place Cell tool would look up the active Element Template settings- say Existing Steelwork, and re-map the attributes and levels as necessary. For ByLevel to work you will need a separate level as a 'key'. If you are happy to have all centrelines on one level, you could remap to that level. Of course, you would lose the ability to turn the centrelines associated with either the existing or new steel beams.

Reply
  • Not sure this proposal solves much. If I understand Cory's requirements, he needs to be able to place the same P-Cell on different levels depending on the particular need.

    This would work if the all the components of the P-Cell were on the same (Default) level and have the same symbology requirements. But the centreline example shows tha this will often not be the case. The beam would inevitably have connections or other components that will need to be on different levels. These attributes will also need to be re-mapped when the P-Cell is placed.

    Locking the symbology on the non-default levels to what is in the remote cel-lib sounds a bit too clumsy. At some point, I can see someone downstream needing to change the symbology. There is also the question of DWG mode compatibility.

    For ByLevel to work as a means to globally control symbology, you need a separate level as a 'key'. This kind of CAD level / layer way of organising things have their limits. Maybe it time to bite the bullet and look at using Element Templates to organise attributes.

    You should be able to retain the geometry and map the level etc attributes by changing the active Element Template when placing the P-Cell...??

    Each element can be assigned a generic ET: Beam, Connection, Centreline, Placement Point etc.

    The Place Cell tool would look up the active Element Template settings- say Existing Steelwork, and re-map the attributes and levels as necessary. For ByLevel to work you will need a separate level as a 'key'. If you are happy to have all centrelines on one level, you could remap to that level. Of course, you would lose the ability to turn the centrelines associated with either the existing or new steel beams.

Children
No Data