Parametric Cell Studio - Perforators

By default, perforators have never created openings in walls from a vertical orientation (or other angles).  However, there is an undocumented variable (I know, I know) that does allow perforators to cut vertically: BB_PERFORATEALL.  Set this to a value of 1, restart ABD, then move the object in order to regenerate the geometry.   That should work.

Undocumented? Does that mean unsupported or just forgotten?

Thanks -  I'll give that a go.

The De-arcanisation of PCS.... this would fill a few threads, removed and otherwise, I think :-)

A bit of an aside at this point, but have a look at the Be Presentation of Civil Cells. I see a lot of PCS-like 'grafting' of components onto other elements using offsets etc.... all within Mstn. PCS 2.0?

Unknown said:

I will need to recreate these cells to suit each project specific wall build up.

I am slightly surprised to hear this. Reading the PCS user guide, when a component is 'grafted' onto another, it looks up all the top-level reference variables and reconciles them to the variables in the assembly.

Doesn't PCS do the same, when a PCS-generated window is inserted into a wall assembly,  Mstn-side? If the Wall thickness is declared as a /top-level variable in the PCS component, doesn't PCS look at the Wall thickness variable in the host wall, and copies the values thru? Same deal for F+P symbology info? This should cut down on the number of variations that needs to be generated.

Wonder how that GC UGF Bake-as-Compound-Cell option is doing?

As per my other parallel parameter cell studio thread; no it doesn't seem that part&family info within a paz cell can be updated VIA the datagroup system.

The wall thickness value within the paz cell only relates to a single leaf thickness ( graphic group off) or the entire compound wall thickness ( graphic group on ). There is no way to interrogate multiple leaves.

Similarly the peforators are universally driven by a single datagroup value.

While wallthickness and sensedistance are fine for simple single leaf walls, they are very limited for mutileaf compound walls.

Yes paramedic cell studiow allows you to nest hierarchical constructs of one component  within another but requires the to be user to be proficient in PCS. My users have a hard enough time editing dimensions styles.let alone delving into PCS.

One thing I found useful is the new part family utility in AECOsim.

It allowed me to change many of our SS2 part family assignments to the new versions.

The tool allows you to change individual parts that are nested in the cell over multiple cells.

The necessary cells would have to be copied from project to project. But changing the part of just

the return material would is pretty easy. Even on multiple cells.

Not automatic......

But maybe an option

Doh!

Nice workaround. I had only thought of that tool in its software upgrade guise...

I am a proponent of the stand alone project dataset. with an office "library "to feed generic information as/when needed. so coping cells is what I'm used to.

Hopefully, someone from the PCS team is listening.... I know, I know.... it 's on the list... that is in someone's drawer somewhere :-)

1. Maybe, it's a question of adding some tools for PCS to detect and read parameters stored in the F+P system, not only DGS, when inserting the component into its host. I think the compound walls catalog info are still stored in the F+P. Hopefully GC can read stuff as well, not just ECAttributes.

2. There should be some 'user interactivity' tools to allow the user to help match/glue together the reference parameters. This is pretty standard with MCAD apps that are based on parametric components. As mentioned elsewhere, the component is often packaged with a bit of scripting in to help cut down the work for the user, by automatically filtering for the best matches.

Maybe, PCS can't figure out what is 'outside' for the wall. It would ask the user, wait for the pick. and confirm etc. BBD already auto-assigns graphic groups to the wall. It should be possible to figure out how many walls to deal with. Usually done in VBA or some scripting language. Maybe, the fist step is build a bridge to Mstn VBA from PCS or GC.

GC has ElementSensors and Support switching tools. Maybe, the user would script up a window WITHIN a 'sacrificial' compound wall. He places the window-in-the-wall next GC BIM element next to the wall. He calls a Switch-to-External-Support tool, and switches the window's 'sacrificial' wall for the pre-existing wall.... click on GC wall... click on TF wall, and the window becomes a part of the TF wall.

Hopefully, someone from the PCS team is listening.... I know, I know.... it 's on the list... that is in someone's drawer somewhere :-)

1. Maybe, it's a question of adding some tools for PCS to detect and read parameters stored in the F+P system, not only DGS, when inserting the component into its host. I think the compound walls catalog info are still stored in the F+P. Hopefully GC can read stuff as well, not just ECAttributes.

2. There should be some 'user interactivity' tools to allow the user to help match/glue together the reference parameters. This is pretty standard with MCAD apps that are based on parametric components. As mentioned elsewhere, the component is often packaged with a bit of scripting in to help cut down the work for the user, by automatically filtering for the best matches.

Maybe, PCS can't figure out what is 'outside' for the wall. It would ask the user, wait for the pick. and confirm etc. BBD already auto-assigns graphic groups to the wall. It should be possible to figure out how many walls to deal with. Usually done in VBA or some scripting language. Maybe, the fist step is build a bridge to Mstn VBA from PCS or GC.

GC has ElementSensors and Support switching tools. Maybe, the user would script up a window WITHIN a 'sacrificial' compound wall. He places the window-in-the-wall next GC BIM element next to the wall. He calls a Switch-to-External-Support tool, and switches the window's 'sacrificial' wall for the pre-existing wall.... click on GC wall... click on TF wall, and the window becomes a part of the TF wall.

Yes, which kind of arcs back to a lot of older threads that indicate a root and branch reorganisation of the roles for parts&families, datagroup needs to happen.

Not really part of this thread but...from my (limited/current/selfish) point of view:

Parts (or Element templates) would be called PartStyles;
They would define the symbology drafting styles the application needs during extractions for elemental stuff ie Steel, brick, concrete.
They would be the fine grain, elemental version Display Styles and include settings for defining Outside/Back/Cut/Forward_Near/Forward_Mid/Forward_Far/Rendering material (which might include driving the projection maps, origin and orientation).
They might be saved as several PartStyles per material style to account for scale or theme. eg.  brick_lowres & brick_detailed
They would carry absolutely no geometric presets (width, height etc).

Compound Parts would have nothing to do with defining building objects;
Instead they would package PartSyles into Dynamic View themes eg for Plan, Section, Elevation, and 3D output for Scale, Task, Thematic options.
The needs of a plan cut are subtly different than the needs for a section cut, and certainly different for an elevation.

Families would simply add organisational/categorization criteria to do with function/system. Ie Door, Window, Wall.

The geometries of Component Walls & Slabs (single or compound) / Component Cells (single or compound) should be defined  as parametric building objects (GC or otherwise) whose dimensionality is driven entirely through the datagroup. PartStyles should be considered as a kind of dimension.

By Compound Walls & Slabs I mean the multi leaved structures we know and love. Perhaps driven by plane/surface rather than baseline. They could then be "glued" to simple mass model faces (in the GC element sensor workflow).
By Compound Component Cells I mean nested hierarchies of objects eg. a leaf.cel within a frame.cel within a wall closer.cel, each of which might have 2DPlan sub models etc. They would be far more reference like (Reference Cells), in that an edit to a base cell definition would automatically update all the models referencing that cell.

Hows that sound?

PartStyles:

Yes, it would be good to:

1. be able to selectively override the F+P system to get different outputs, without having to mess with the F+P system directly.

2. be integrated better with the display system. Especially now that things like hatches are handled by the rendering materials tools. LOD would be one for me.

3. move all the geometric pre-sets, functional tool-associated definition to the DGS....?

I would add:

4. Provide some sort of overriding/concatenation functionality to allow the DGS to override/extend the F+P pre-sets. Say, I have a material -aluminium- defined in the F+P, but have coated, anodised, satin etc, I shouldn't have to go all the way back to the F+P system to define it and reload it in the DGS. We should be able to make the change in one go. All these multiple dialog boxes are tedious.

Compound Walls + Slabs:

1. DGS parameter-driven components: Which Datagroup do you mean? 1.The template xmls in the dataset folder? 2. the Datagroup attributes that are stored with each element that you get access to with the Modify Tool or 3. the Datagroup info you see presented to the Datagroup Explorer?...which may not be synch'ed to item 2, and looks like item 1?

DG Ex could help things a bit by show the model path in its window bar, and model tree sorting, or at least grey out the stuff that can't be modified as they are in the Refs with visible set.

2. Compound Walls: are a bit of a disaster. Some info still defined in F+P, not DGS. Why? Really clumsy inflexible relationships with each other, that are hard to manipulate. No real baseline or control mechanism at 'compound level'. Once the C-Wall is placed, all the offset parametric/constraint info seems to be lost.

Maybe, Compound Walls should be re-implemented using the new Roof element's Morph Forms. The Roof elements are 'compound' assemblies of slab forms that are packaged with some logic and handles to ensure that the slabs mitre properly with each other. You can drop them and get individual Forms.

I could see multiple parallel 'roof slabs' tilted up and encompassed in a larger Wall/Linear Form volume. The 'parent' wall would be manipulated like a wall as usual, but when the manipulation is done, there would be some logic to process the 'children' slabs to ensure they join up/mitre with each other and other C-Walls/walls proper.

Naturally, the parent wall could be on a separate level so that we render/plot the C-Wall parent wall only when LOD demands.... with pink fill if desired to hide all those boring details :-)  

Morph Forms, like other Forms can also store multiple profiles to punch openings or pultrusions. Maybe, these could be used to store the baseline or used as clipping shapes.

3. Compound Slabs: Same deal rotated 90 degrees? One nice thing about the Pattern tool is that you can use 3d cells to pattern a shape. It should be possible to replace one of the slab layers with a shape and pattern it with some solids so that you could have a quick way to get timber joist or waffle slab floors?

4. Glue to model faces: Yeah, I like this idea. If you can encapsulate a Morph Form within a Morph Form.... I guess you could cook up some logic to 'mitre' stuff recursively. Make a boxy Morph Form, graft another Morph Form onto one of the faces (just like the Roof tool already accepts a shape as input). The only difference would be the need for the Morph Form to Extract the desired Face beforehand, but hey... there is code for that already.

Your boxy Morph Form could be a Space.

5. ...?