constraint 2D cell, elements on different levels?

hi everybody,


as an architectural office, we would like to use the new microstation ce constraints to create 2d parametric cells like lets say doors in plan projection.

the new parametrics are a greate revival of dd-design, finaly easy to learn and use. thank you, bentley.

but some behavior is not usefull, or i don't fully undestand yet how it works:

we need those door cells with graphic elements on three different levels, there are construction lines needed to place the cell in the drawing that should never be visible in the final plan.

i created a cell  in that way, the constraints, variables and variations work fine.

only, when placing the parametric cell in the drawing, all graphic elements are placed on the active level, not as with normal cells or shared cell, where all elements remain on their levels. this behavior makes the cell unusable for us.

one can use elements of class construction in the cell definition, those disapear when the cell is placed, that is helpfull, but does not solve my problem.

is there any hidden switch/option/preference to change this behavior, to keep element on ther levels?

also, when creating cells, often there are drawings of standard profiles included, like steel profiles etc. one would realy like to place such as fix groups or cells inside a parametric drawing, with their position controlled by constraints. but i could not connect constraints with cells or groups in a usefull way. only if it is one group and the group itself is used as a fixpoint and oll other geometrie is parametric around this fixpoint. that seems to work, but is not usefull.
 so it seems one has to describe each profile also parametric, with many constraints and fix dimensions. this takes for ages and creates super heavy cells microstations needs to evaluate with a high performance impact.


i was so exited to find dd-design rewritten in a fast and usable way, but now it seems it's still more a promise for the future :(

or did i miss the right tricks to get it going?

thankfull for any hint

regards, konrad in berlin

Parents
  • Unknown said:
    only, when placing the parametric cell in the drawing, all graphic elements are placed on the active level, not as with normal cells or shared cell, where all elements remain on their levels. this behavior makes the cell unusable for us.

    Yes. This contradicts the expected behaviour with normal cells. Amazing that this got through QA. Hopefully it's all on the backlog.

    It would be interesting if  the devs solve the underlying need to preserve the level info or just solve the Drop problem. Also problems with exporting to DWG.

    Unknown said:
    only if it is one group and the group itself is used as a fixpoint and oll other geometrie is parametric around this fixpoint. that seems to work, but is not usefull.

    Yea. I got the same feeling during the beta. The devs had a very limited idea of how the PS cells would be created or why grouping and nesting would need to be integral to the whole enterpise... with some that were very sure that this wasn't needed.

    Unknown said:
    also, when creating cells, often there are drawings of standard profiles included, like steel profiles etc. one would realy like to place such as fix groups or cells inside a parametric drawing, with their position controlled by constraints. but i could not connect constraints with cells or groups in a usefull way.

    Yea. "The 2d constrained geometry contained in PS in a cell should be accessible. For example, this could be:

    a. A 2d line in a Cell (like the Legacy Feature Solids can already do) should be available to be constrained parallel (or perpendicular etc) to another line or edge outside the cell, or in another cell. See the way PCS' snap sets defined in one component can be constrained to another snap set in another component. The 2d constrained shape is part of the stair object/cell and also drives the 3d elements of the object/cell. After inserting the stair object/cell, the user constrains or 'grafts' the 2d constrained geometry to an edge on the landing (external to the stair object/cell).

    This kind of basic 'rigid body' behaviour was already being looked at with the old DDD Align Element with Point and Line tool.

    b. 2d lines declared as input or 'reference' elements that would be replaced on insertion of the Cell. See Template Driven Solids or Civil Cells example attached. See also the way Feature Solids also allow DDD profile cells to be swapped out. Revit version. As mentioned elsewhere, Catia also does this kind of swapping with its PowerCopies."

    Unknown said:
    so it seems one has to describe each profile also parametric, with many constraints and fix dimensions. this takes for ages and creates super heavy cells microstations needs to evaluate with a high performance impact.

    Heaviness: I think the geometric constraints solving that underpins all this will always want everything fully constrained as far and early as possible. I think all apps that do GCS have this burden; and have ways to 'lighten' the load for the user. This includes auto-constraints tools, inferring constraints when something is partially constrained and allowing constraints to be saved/preserved/re-used when copied or encapsulated as a cell and 'grafted' onto new geometry when placed.. etc etc.

    The 2d GSG solvers are mostly single threaded, and will choke pretty quickly. The 3d solvers are even slower. I think that this means that Bentley needs to build in tools that compartmentalise the constraints solving sets as much as possible without sacrificing flexibility. Some sort of rules-based approach like Civil Cells and a means to group constraints to be selectively de-activated like SolveSpace would be good.

    The other source of 'heaviness' is the cumbersome way that all internal variables have to given named variable defnitions BEFORE the cell is placed to be usable. This makes for large 'heavy' incomprehensible variable lists that will be difficult to manage.

Reply
  • Unknown said:
    only, when placing the parametric cell in the drawing, all graphic elements are placed on the active level, not as with normal cells or shared cell, where all elements remain on their levels. this behavior makes the cell unusable for us.

    Yes. This contradicts the expected behaviour with normal cells. Amazing that this got through QA. Hopefully it's all on the backlog.

    It would be interesting if  the devs solve the underlying need to preserve the level info or just solve the Drop problem. Also problems with exporting to DWG.

    Unknown said:
    only if it is one group and the group itself is used as a fixpoint and oll other geometrie is parametric around this fixpoint. that seems to work, but is not usefull.

    Yea. I got the same feeling during the beta. The devs had a very limited idea of how the PS cells would be created or why grouping and nesting would need to be integral to the whole enterpise... with some that were very sure that this wasn't needed.

    Unknown said:
    also, when creating cells, often there are drawings of standard profiles included, like steel profiles etc. one would realy like to place such as fix groups or cells inside a parametric drawing, with their position controlled by constraints. but i could not connect constraints with cells or groups in a usefull way.

    Yea. "The 2d constrained geometry contained in PS in a cell should be accessible. For example, this could be:

    a. A 2d line in a Cell (like the Legacy Feature Solids can already do) should be available to be constrained parallel (or perpendicular etc) to another line or edge outside the cell, or in another cell. See the way PCS' snap sets defined in one component can be constrained to another snap set in another component. The 2d constrained shape is part of the stair object/cell and also drives the 3d elements of the object/cell. After inserting the stair object/cell, the user constrains or 'grafts' the 2d constrained geometry to an edge on the landing (external to the stair object/cell).

    This kind of basic 'rigid body' behaviour was already being looked at with the old DDD Align Element with Point and Line tool.

    b. 2d lines declared as input or 'reference' elements that would be replaced on insertion of the Cell. See Template Driven Solids or Civil Cells example attached. See also the way Feature Solids also allow DDD profile cells to be swapped out. Revit version. As mentioned elsewhere, Catia also does this kind of swapping with its PowerCopies."

    Unknown said:
    so it seems one has to describe each profile also parametric, with many constraints and fix dimensions. this takes for ages and creates super heavy cells microstations needs to evaluate with a high performance impact.

    Heaviness: I think the geometric constraints solving that underpins all this will always want everything fully constrained as far and early as possible. I think all apps that do GCS have this burden; and have ways to 'lighten' the load for the user. This includes auto-constraints tools, inferring constraints when something is partially constrained and allowing constraints to be saved/preserved/re-used when copied or encapsulated as a cell and 'grafted' onto new geometry when placed.. etc etc.

    The 2d GSG solvers are mostly single threaded, and will choke pretty quickly. The 3d solvers are even slower. I think that this means that Bentley needs to build in tools that compartmentalise the constraints solving sets as much as possible without sacrificing flexibility. Some sort of rules-based approach like Civil Cells and a means to group constraints to be selectively de-activated like SolveSpace would be good.

    The other source of 'heaviness' is the cumbersome way that all internal variables have to given named variable defnitions BEFORE the cell is placed to be usable. This makes for large 'heavy' incomprehensible variable lists that will be difficult to manage.

Children
No Data