I have come to the conclusion that despite there being a phasing attribute in AECOSIM there is no scope to leverage this in the application other than as an output.
In the event that we have modelled an existing building it appears the only way to manage the removed and retained elements is to put them in sperate files. Does anyone else have a better way to do this?
Ironically I have tried using named groups to knock out existing to demolish but the space flood tool sees the walls that are in the existing to demolish named group, see image (the green area is a space flood). Annoying really... I know its been said before, but named groups would be great if they were properly integrated with AECOSIM.
I had understood that space floods were going to be improved to flood only on the plane identified, is there a timescale for this to happen - I thought it was meant to have been doen for AECOSIM.
Unknown said:Ironically I have tried using named groups to knock out existing to demolish
How are you doing this? Sounds interesting...
Simply put within the existing model you have element in an existing to be retained group and an existing to be demolished group. When you attach the file as a reference it is possible to attach a named group within a file. Sounds great until you realise that AECOSIM ignores the namedgroups.
R
John
why not for levels? separate Saved Views>DV/BV will do.
But it is much easier to do with DEM as there are no way of "bulk editing" BVs
regards / Thomas Voghera
Robert J
Fire rating etc can do with resymbolisation.
But demolished is different as it must NOT interact with other geometry.
You can do that really easily with thematic mapping Rob, however if you have TFpart applied materials it fails to override the materials.
I think the broader point is correct though, we've got at these attributes we're adding to elements (the I in BIM) and yet we can do anything with them other than spit them out. Effectively we have information rich models, but can't get at the information usefully.
ps. Don't like the idea of a QS getting their hands on colour by cost :)
Yea.... I think another way of saying it is that there is no way to make the attribute data drive ABD's CAD data... without manual input thru the various dialog boxes like the Info panel and DG Explorer....and even if you do this, it is not clear how you would be able to store the changes so that you don't have to repeat them in future..?
Maybe referencing by Item Sets should be a dev priority... Named Groups seem to pop up as Item Sets anyway.
"In DEM I use to shift elements to a separate level (or levels) and then use the Group-Model to filter demolished out from the main cut, and then make separate Group-Models and cuts with only demolished. A bit hands on but in DEM it was easy to just copy the DEM-definitions and change Group-Model."
Not sure, but if the demolished elements are on a different level, then this should be possible with DV/BV's as well?
One aspect that DEM has and DV overlooks is the 'composability' angle, which is pretty powerful... as Thomas and others have mentioned previously.
DEM expands on the way Refs can be collaged together, while DV/BV seem to take a 'one shot does it all' approach, that is probably necessary due to the 'immediate display mode' that DV/BV's introduced. The old DEM process was always a bit more of a 'deferred' extraction process.
I don't see why we can't have the best of both worlds... hopefully? I think the current DV tools are a tad too restricted to an overly simple idea of how drawings and sheets are created. One drawing model on one Sheet model that have one 3d 'composition' model as the root. DEM allowed that extra flexibility in terms of combining models that has proved indispensible 'in the trenches'.
With DV's existing 'back-referencing' capability, we should be able to back-Ref any 'composited' Drawing or Sheet models back into the 3d model. I don't think this is possible at the moment. Not sure...
1. Say you generate an DV with a group of Refs and a Drawing model.... and need to add a bunch of Refs.... when the DV is back-Ref'd in the 3d model, does Mstn look at the Ref list stored in the SV... or does it look at the Drawing models for the Ref list and level mask? I suspect it looks at the SV only. Any additional Refs added in the Drawing models are not processed. This misses out on the flexibility that DEM-style compositing provides.
2. What happens when you need DV's from two different composition models? Can you composite them in the Drawing Model? I suppose you could 'apply' a couple SV's in the Drawing model. But, would the Marker menus in the different 3d models now be able to find and back-Ref the updated Drawing model(s).
3. It's fairly normal for detail sheets to have multiple detail 'view ports'. Each 'view port' would need a separate Drawing or Sheet model. The Drawing model will be likely to be referenced and 'composited' in multiple Sheet models. The DV creation tool doesn't seem to recognise that we need to be able to place multiple DV's in a Drawing or/and Sheet model... on a regular basis. Will the Marker menu find all of these linked models and back-Ref them properly?
4. DV View Presentation: DEM allows the extracted graphics to be overriden/omitted by whether it is cut, forward, reflected. DV's have their equivalents. It would be great to be able to have the option to turn this on/off in the Ref Dialog. DEM allows the multiple extractions to saved as separate models. Maybe, the Create Drawing tool dialog should allow targeting separate models in the Drawing dgn. DEM even allows different xml files to be used for the F/R Part mapping....
5. DV Drawing models that are generated from the 3d model can not be back-Ref'd back into the original 3d model. I think the thinking is that the 3d model will be more up-to-date, and Mstn should be dynamically 'cutting' or generating the Drawing model's contents anyway. But, there is often stuff that it parked there which is useful, especially when compositing. Also runs counter to Mstn's longstanding ability to deal with self Refs. A big advantage over ACAD which can't handle circular Refs very well. Even CVE's are not allowed to be referenced back which I think is a real problem...
Maybe the DEM should be re-configured to produce and manage SV's that generate MVE/CVE's that can be used to replicate the various *.s, *.f, *.r models that are/were generated with DEM. This would be a good way of dealing with the fact that DV/BV's and the Level Display panel are not geared to deal with re-symbolising elements onto different levels 'in the same model'.
I guess, at some point, this can be enhanced as 'Element Handlers' so that when you activate the re-symbolised 2d elements, they will sprout some handles and let you modify the originating 3d elements from their 2d 'proxy geometry'..... like the old Triforma 2d-3d Bridge.
"Not sure, but if the demolished elements are on a different level, then this should be possible with DV/BV's as well?"
TV: sure. But with the addition/complication that you have to make the DV/BV wireframe.