Is there a way to provide a more object-neutral, savvy placement logic?
Aecosim is pretty flexible with what orientation its objects are placed with. A Wall etc can be placed on a sloping plane, according to how the ACS is defined. definitely an advantage over the competition.
But these 'system' objects will almost always be used as host for objects generated by PCS like casework, rails, skirtings, signage, fittings and equipment. There is a plethora of settings like base, side, depth, back, front offset, Rel. ACS etc, which will be helpful.
As it stands, it seems like the way that the PCS-generated object is oriented on the selected host object really struggles when the object is oriented 'unconventionally'.
Example of placing a Window in a sloping wall. The window object generated by PCS is placed as expected when the wall is placed on a levelly placed Wall. It seems to read the orientation of the wall properly.
But, when it is placed on a 'sloping' Wall, it seems to lose the plot completely.
Roughly speaking, there are three types of Triforma Forms host objects and an equivalent number of hosted objects that can be grafted on them.
Planar: Walls, slabs, roofs.
Recipe Inputs: P-Plane polygon, sweep operation; Outputs: Q-place polygon
Recipe Inputs: Polygon cross section, sweep vector
Linear: Columns and beam.
Recipe Inputs: Planar cross section. extrusion path
Recipe Inputs: Line/linestring/arc, sweep vector, thickness, P and Q-Points.
Point: Cells
Inputs: insertion point, rotation matrix
This makes nine possible combinations. It would be good to be able to provide both the Place Object tool and PCS the smarts to glue/graft the objects onto their hosts properly. Placing an object generated in PCS on a TF object in Aecosim like a Wall should be more like how the PCS object already behaves when placed onto another object in PCS. PCS already has some tools to define how an object is placed in Aecosim like _TF_Point3_Order, which is used by the Place Object tool to prompt the user to provide the necessary inputs in the desired order.
PCS should allow user to define what plane(s) or 'positioneer' or Path2D should be used to match a particular plane or edge/sweep vector on the TF host object. The Place Object tool may have to extract the face information via Parasolids and not the TF COM recipe inputs or methods. Maybe, the additional methods could be added to TF COM? The new Constraints tools would be great to leverage. Just 3d constrain the two planes or closed paths together.
1. Planar on Planar: Walls will have cladding or linings. Slabs would have plinths, insulation layers and screeds.
2. Planar on Linear: Similarly, columns and beams will need cladding. The Place Object tool should be able to infer the plane on which the profile polygon is placed; and cycle through the orthogonal planes.
3. Planar on Point: Cells have an insertion point and a rotation matrix that can used to define local planes, and be cycled through as above. Alternatively, the Place Object tool would look for a planar object within the Cell.
4. Linear on Planar: Movement joints on a slab or or mullions / transoms on a curtain wall. Rain water pipes offset from a wall.
5. Linear on Linear: linear battens sleeving a beam or column. Gutters running alongside with barge boards. Purlins running perpendicular to Rafters. Gaskets running around the edges of an opening in a wall. Handrails or stanchions that need to sleeve onto spigots. Nuts that need to fit onto bolts.
6. Linear on Point: Lighting columns placed on a plinth. Beams placed on a bearing. Multiple space frame members connecting to a node. Spindles or bolts aligning through or on a point.
7. Point on Planar: Walls will have lots of point objects like light fittings, signage boards, toilet paper holders etc that would need to be placed on or within its planar faces. Slabs and walls will need penetrations. There should be the option to access input parameters like thickness to feed parameters like offsets; and the option to switch to 3d constraints like plane to plane parallel, perpendicular etc.
8. Point on Linear: Linear objects like columns would often have point objects like corbels or pockets. It would be good to be able to constrain the point object's insertion point to the linear objects sweep vector or workline. Beams would have connections, cleats or joist hangers, penetrations etc.
9. Point on Point: A plumbing fixture like a hand wash basin would be placed as a Cell, hosted by Wall. At some point, the taps and other secondary fixtures would be placed onto the host point object (HWB, not the Wall). It would be good to be able to provide an offset constraint between both insertion points.
Hi Dominic,
We could reproduce the problem. However when we are defining an ACS with respect to the sloped wall and after that placing a window it seems to work OK. Can you please check this observation.
Yes. you are right. The Rel/ACS setting was on.
Just tried to place a Base Plate onto a sloping Slab using the U9.1 Place Object tool. Rel/ACS was disabled. The Place Object did not recognise the Slab's orientation.
Ran across this across this vid on the Curic Align plugin for Sketchup. Maybe the old Triforma placement algos should be updated to stop and show the user what frame of references it is proposing to use as it places objects onto its host? The vid is instructive as it highlights the usefullnes of exposing the local coordinate systems using bounding boxes, origins and centrelines when aligning or placing objects relative to other / host objects.
I am thinking of putting in an enhancement request for the Place Object Tool in the new OBD Ideas portal. Being aimed at generic Objects it doesn't get the attention it needs. Placing Objects these days goes way beyond just ACS / Accudraw and a few size, rotation etc parameters.
Even just looking at the geometric placement requirements, Curic clearly illustrates that more can be done. Mstn's placement tools are too heavily based on the active View and ACS info only. These days, it's more about inferring and handling multiple geometric coordinate systems including any host and associated objects. Each of them having their own attributes depending on whether they are planar, linear or point in nature.
This results in a huge amount set up work that needs to be repeated for each placement, making Accudraw / ACS tools very inadequate for anything more than a few tweaks. This is compensated by the smart tools having to build in the requisite parameters as part of their UI. See the MEP ducts etc. No need to rotate Accudraw or the ACS system to match your sloping pipe or duct. The pipe centreline etc info is already stored and any rotation around the axis can be done by changing some exposed parameters. This is of course not available if your Object is generic or user-defined.
Luckily, its probably easier to hi-jack an MEP tool and modify it to place some generic Objects. Looking at CARF's updated penetration tool is pretty instructive. Being German, it reminded me of course of the ProSteel tools... which can be a bit rigid, narrowly defined and ill-suited to something generic. No doubt that this detailed no nonsense approach is very very efficient... in the right markets.
Not saying that the Place Object tool should replicate all the CARF functionality. But I suspect it's a good 'supertype' (like Annotations, generally) that the Place Object tool could use parts of and be extended as required. The UI has different parts that support:
1.0 Different Object types / categories
1.1 Object type, expected host(s), gluing logic (see nine possibilities in the OP) which will also determine number of inputs required to place the Object.
1.2 Object size: definition by text inputs, by points, by matching another object etc
1.2.1 Object size: step value constraints, unit settings
1.2.2 Object position constraint (z-elevation)
1.3 Object insertion point. Now nicely enabled for all Cells with Mstn U16.1 Placement Points etc. Rotation
1.3.1 Object offsets based on the z-elevation or other objects or parameters (top / bottom of slabs etc)
The UI also builds in support for the inevitable annotation requirements. Yes, even in a model only deliverables environment, annotation will be a requirement.
2.0 Place / report on annotation element reporting the parameters inputed above.
2.1 Annotation format: assign / link to object by point, selection set etc
2.1.1 Annotation – format settings (scale, text height, units)
2.1.2 Annotation – re-calc / place to fix clashes
2.2 Define any associated elements that the annotation object will need to link to. In this case the Space the penetration is associated with.
There are also sub-menus / dialogs for linking and checking links between the incoming Object, any host objects and other associated objects needed for reporting etc. De rigueur in today's BIM crazy world.
2.1.1 Extract and display parameter from Object and assign / link parameter to objects by point , selection set etc
2.1.2 Highlight all Objects associated with Space (associate object); report penetration areas
You may argue that it is bit heavy, but obvious that they have listened to the users who have been banging away on the previous versions of the tool and added the heavily used bits rather than leaving it to separate 'generic' tools elsewhere.
CARF-Penetration-tool.pdf