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.

Very cool.

You are correct that having control over depth of each cut would be important.

And I do dislike the way the placement Sense distance overrides the default

values of all the perforators during placement.

A variable defined perforator depths disassociated from sense distance

is definately what is needed.

And I do like your concept of subtractive 3d perforators.

Sounds like CR time to me.

CR submitted.

Great job Robert. I hope you re-use the windows again and again.

Oh no congratulations yet. Still battling with the PAZ version of the cell - both the process of creating the cell and the cell istelf are very flaky.

The PCS tool (if it has a future) has to become much less arcane.

This particular wall closer will only work for this particular wall type. I will need to recreate these cells to suit each project specific wall build up.

Expecting general users to do this fiddly PAZ editing (and re-editing) is unfeasible. They already have a lot to do that shouldn't include retrofitting a dozen perforators, and/or reapplying parts&families, and rebuilding the PAZ cell before swapping out all the existing cells in their model, just because a last minute design change is made to the outer cladding material...

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?

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.

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?