Intentions behind the Hide and Copy/Hide Cached functions

A few months ago I know I made the Drawing "cashed" and did a few hides+edits because I was in a hurry. And that haunts me now as I have, of course, forgotten where that edit was done, and I have no idea of how later changes to the 3d will come through under/over the CVE "hide".

When I first met CVE it was as a solution to Drawings not being "look through" as a wireframe is. Dynamic Views Drawings are all shapes and the cover everything "below".

But surely Bentley have had it cooking for other reasons. It is not a perfect world>not perfect models>not perfect Drawings > need for last minute edits, touch-up and I have heard the word "embellishments".

One could argue - heck, then we are back to DEM-cuts anyway.

Unfortunately not all the way back to simple lines I sometimes which.

(What if there was a fourth alternative in the CVE drop-down: EXPORT TO SIMPLE LINES IN NEW MODEL WITH TIME STAMPED NAME)

I am still puzzled about the nature of this CVEs and its content. Not 3d, but surely not simple lines easy to export to dwg drawings.

I begin to think I want a second/third alternative of it > > a pure (DEM-like) export to simple lines !

Simple to understand for everyone, simple to edit. No problems with dwg exports or hiding shapes that also stealing snaps all the time!

The drawback is of course it is a one way action and edits have to be redone.

Or could it be so that any touched and added element in this DEM-export remains, and only untouched elements are rewritten when re-cached ?

Robert, I don't know how to manage this, and have all the opinions you mentioned in my head.

At least some  of us will need to fix the output. We need fixing tools.

Unknown said:

I have, of course, forgotten where that edit was done, and I have no idea of how later changes to the 3d will come through under/over the CVE "hide"

Unknown said:

a fourth alternative in the CVE drop-down: EXPORT TO SIMPLE LINES IN NEW MODEL WITH TIME STAMPED NAME)

http://communities.bentley.com/products/microstation/microstation_v8i/f/19565/t/83333.aspx

- Bentley have created Managers to keep track of all sorts of things - why not this?

I can see myself superimposing 'overhead object' chain-dotted lines over just a few edges of solids (which are then all cache/hidden) in Back view; similarly 'existing removed' dashed lines in Cut and Forward view. Or is there a better way to do that (ordinary MS solids, not BA solids)

Haven't got onto this bit yet - but would History be relevant?

You can unhide these elements by first using the "Display Hidden Elements" icon in the Reference dialog (right side of icon row).  That'll grey out all elements that aren't hidden, making it easy to identify the hidden one.  Once in this mode you can Unhide individual elements.

But I can see your reasoning for some type of "tracking" with hidden CVE elements.   Can you log a ST for this?

In the interim, I would probably choose to Hide and Copy, select the copied elements and change their color to the background color, and then proceed.   When switching back to Dynamic the copied elements will hide those that are re-displayed.

I am still puzzled about the nature of the cached elements.

If I turn off the ref the geometry disappears from the view.

But if I turn off all levels for the ref the geometry is still visible.

Would be nice with some explanation off this.

When you open a file with a cached BV reference you get a warning down right and the text in visible edges column is red.

Could we have a similar warning/indication that something also is hidden/edited on/in the cached view?

I think you need to step back and take a wider view to answer your 'intentions' or 'where are we going with this' question.

Caching....Tracking...Hiding...Copying... are mentioned extensively in this thread.

All really profound functionality that I think the dev team are already looking at from a wider perspective.... beyond the needs of some last minute embellishment. After all, one of the big reasons behind CVE's is the need to provide portable re-symbolised graphics for i-models, which is a cornerstone of Bentley's info-mobility offensive.

Caching: Bentley projects tend to be infrastructure-related, therefore big. Even using CVE's, there will be a point where we need to have some sort of incremental or selective updating.... while we are waiting on the whole multithreading revolution thing to show up. If I have a big airport or hospital floorplan, I don't really want to have to 'recalc' the whole kaboodle just to show a few changes to a wall.

Tracking: Caching and CVE's mean introducing a latency 'gradient' into the information. 1. Active model - zero latency 2. Normal Ref models: incl. new bi-directionally linked ones generated by DV's - low latency. 3. CVE's - high latency (especially with hide+copied elements; ie with manual update overheads). This means robust and granular version control. Something based on DH to track what is in synch, deleted and modified would be good. You wouldn't want a totally separate tool for CVE's, which are really just 'cached' Refs... albeit full of proxy graphics/element enablers etc that may be mixed in normal elements, and their proxies etc.

Hiding: It would be great to see this CVE functionality spill over into regular non-cached models. Display Sets are great, but it doesn't really replace the ability to Hide elements. In any case, hiding is an integral 'first step' of any embellishment excercise. To cut down repetitive manual embellishment, we need to be able to 'filter' what we need to hide using the usual suspects like Ref/model:levels, the clip volume cut/forward etc components, fences etc... and in these day-centric days, rules-based criteria sets, categories etc as well. More importantly, we also need to be able to hide at the element/granular level.... in a persistent way!

• By Clip Volume Cut / Forward / Reflected / Outside: DEM allowed the user to define different Ref:level combinations to be used (by associating different views to cut,forward etc extractions). This can be replicated by making multiple copies of the CVE ref and using the settings in the Ref Dialog's Presentation submenu. Bravo!
• By DGS Parameter, by Element
• By Category, Criteria Set etc
• By Named Fence (Clip fence is great, but inside/overlap would be more usable)

Copying: Associatively?

One productivity-robbing pain point is the lack of persistent associativity between the 'extracted' graphics and the embellishment graphics, between sessions.

Types of Embellishment Tasks:

1. Hide: masking, filter or suppress individual elements... per se or as a precursor to replacement.
2. Re-symbolise elements: By category, Ref:level etc is largely catered for. What is sorely needed are tools that aid those little fiddly manual re-symbolisation tasks.... and make them persistent betrween sessions. These include:

• Paintbrush tools: View 1- latest CVE. View 2 Hidden or DH elements. User paintbrushes from View 2 to 1. User zooms in one view, the second view zooms to the same camera point. *
• Fence or rule-based Criteria Set, Thematic Display re-symbolisation. A lot of embellishing is forced upon the user because of those 'long tail' type situations that the regular controls like Ref:levels don't work.
• Display-system based tools:

1. Things like Depth cue-ing, silohoutting can be provided by accessing the graphics pipeline to pick out the 'Outer' edges for a roof or massing 'silohoutte'.
2. Differentiating 'Occluded' edges to reduce all those redundant overlapping, underlapping linework that we currently get with CVE's, which makes snapping/embellishment a pain.
3. Piranesi or Pointools-style plane based selection allows the user to select all elements that are on a particular plane or view depth. 
4. Display Priorities: is disabled in 3d. I think is a bit of hasty. The user should be able to give 3d elements a Display Priority that would be useful when the 3d elements need to be displayed in 2d 'print'-oriented views, and CVE's (with or without Drawing Rules). Most models have both 2d as well as 3d information. It may be also be useful to sort out those pesky problems that come up with Compound Cell 2d Drawing Symbols that need to overprint visible edges, or other Drawing Symbols correctly. When a circular duct  or door is cut, does the symbol get placed at the bottom or the top or at the cutting plane or at the centreline or at the cell origin....? I forget don't want to remember already :-) I suspect it's a good thing that we have 'pre-processed' CVE's. I can see the BV engine going spare trying to sort out which Drawing Rule to sort out -in which sequence- in those inevitable multiple-discipline situations.

• Tools for 'one-off' element-level Overrides or embellishments will always be needed. Sense distance etc related to the cut will catch most things, but there will be inevitable exceptions. The kitchen sink link above is good example. Getting 'outlier' objects that are above the sense/view depth to show like roof scuppers, overhead windows etc are other examples. This kind of 'polishing' is probably too 'ragged' for the 'Qvision pass' which needs to be fast / responsive, but hopefully OK in the CVE / Drawing Rule end of the pipeline, especially if we do get incremental CVE's eventually.
• Ignore grouping mode: a lot embellishment is the result of not being able to re-symbolise what is nested in grouped/orphan cells. You end up having to hide, copy, drop and resymbolise.... thereby creating another loose-end that needs to be mopped up the at the next CVE run.
• Unification clean-up: Wall joins, column/wall (columns cut walls) and other unification clean-up are big part of embellishment. We need to be able to locally override what the unification engine comes up with globally.... in a granular and persistent way. Again, H+C provides the raw functionality, but this needs to be coupled with some tracking or associative functionality that would spare the user having to re-do the same 'correction' for the same wall or whatever, even the wall hasn't been changed.... again and again.

3. LOD-based embellishment: We need to be able to glue/offset 2d embellishment graphics to the extracted graphics. We model a brick wall in 3d.... we make a cut/CVE through the wall... we insert a high LOD brick cell/pattern/linestyle that is aligned horizontally/vetically with the wall. Wall moves... new cut/CVE... all your details are messed up. It would good to be able to use the array tool or associative snap the detail graphics/annotations to the extracted wall's TF guideline or edge, making a persistent link between the elements.

In these BIM/3d working times, It is essential to think about 2d drawings (complete with embellishments/annotations etc) in context with 3d models. In the AEC space, the emphasis has been on 3d models, with 2d drawing seen almost as a 'byproduct' of the 3d model. I think this is a bit too simplistic, and Bentley's more balanced Hypemodeling approach is big improvement and -so far- a fairly unique proposal. To work effectively, we need tools that 'fuse' 2d and 3d info together in a spatially-aware way. SS3's back-referencing tools provide a 'beach head' do this in big way down the line.There are also some pretty impressive 2d/3d stuff that are popping up in PowerCivils and Descartes STM development that will hopefully spill over.

Working with 2d drawings now means having to be able to flip between the 2d and 3d model. A lot of 3d TF elements like slabs already store their 2d cutting profiles, and local coordinate info locally. There needs to be minor tweaks to the display system to allow the user to 'tunnel' into a 'sketch plane' container/environment quickly, greying out the rest of the model etc, and allowing the user to edit 3d elements from a 2d drawing. Handles? Copy profile, mod using standard tools, replace and regen solid/surface...?

The fact is that a lot of embellishment work will merge with normal annotation/dimensioning and detailing work... and become increasingly dominant as the design develops. A lot of problems will be picked up in 2d (regardless of how much clash detection you do) and a lot of decisions will be made in 2d first, before being propagated to the 3d model. It's not a '3d first' one-way street. This means frequent activating / flipping between multiple 'working'  models... Most models are really assemblies of multiple submodels. Say you need to develop the design of column. The column is in the structural frame model, the walls are probably in the architectural model. And you have your 2d drawing/sketch with all your dims/hatch/annotations etc. Changing the cladding means flipping through at least three models. This is one advantage Revit's everything-in-one-file approach avoids. Multiple Active Refs, please :-) 

* I know of a large ongoing rail project where the model is too large to cut in one go. The team has 'tiled' the model into 25+ areas in order to get any extractions at all. The extraction still has huge problems and needs to be embellished.. repeatedly. The same roof line has to be corrected 25+ times... multiply that by all the other corrections... over the life of the project.... not great for a cutting-edge tech company's reputation.... in one of its 'own backyard' sectors, IMHO.

I think you need to step back and take a wider view to answer your 'intentions' or 'where are we going with this' question.

Caching....Tracking...Hiding...Copying... are mentioned extensively in this thread.

All really profound functionality that I think the dev team are already looking at from a wider perspective.... beyond the needs of some last minute embellishment. After all, one of the big reasons behind CVE's is the need to provide portable re-symbolised graphics for i-models, which is a cornerstone of Bentley's info-mobility offensive.

Caching: Bentley projects tend to be infrastructure-related, therefore big. Even using CVE's, there will be a point where we need to have some sort of incremental or selective updating.... while we are waiting on the whole multithreading revolution thing to show up. If I have a big airport or hospital floorplan, I don't really want to have to 'recalc' the whole kaboodle just to show a few changes to a wall.

Tracking: Caching and CVE's mean introducing a latency 'gradient' into the information. 1. Active model - zero latency 2. Normal Ref models: incl. new bi-directionally linked ones generated by DV's - low latency. 3. CVE's - high latency (especially with hide+copied elements; ie with manual update overheads). This means robust and granular version control. Something based on DH to track what is in synch, deleted and modified would be good. You wouldn't want a totally separate tool for CVE's, which are really just 'cached' Refs... albeit full of proxy graphics/element enablers etc that may be mixed in normal elements, and their proxies etc.

Hiding: It would be great to see this CVE functionality spill over into regular non-cached models. Display Sets are great, but it doesn't really replace the ability to Hide elements. In any case, hiding is an integral 'first step' of any embellishment excercise. To cut down repetitive manual embellishment, we need to be able to 'filter' what we need to hide using the usual suspects like Ref/model:levels, the clip volume cut/forward etc components, fences etc... and in these day-centric days, rules-based criteria sets, categories etc as well. More importantly, we also need to be able to hide at the element/granular level.... in a persistent way!

• By Clip Volume Cut / Forward / Reflected / Outside: DEM allowed the user to define different Ref:level combinations to be used (by associating different views to cut,forward etc extractions). This can be replicated by making multiple copies of the CVE ref and using the settings in the Ref Dialog's Presentation submenu. Bravo!
• By DGS Parameter, by Element
• By Category, Criteria Set etc
• By Named Fence (Clip fence is great, but inside/overlap would be more usable)

Copying: Associatively?

One productivity-robbing pain point is the lack of persistent associativity between the 'extracted' graphics and the embellishment graphics, between sessions.

Types of Embellishment Tasks:

1. Hide: masking, filter or suppress individual elements... per se or as a precursor to replacement.
2. Re-symbolise elements: By category, Ref:level etc is largely catered for. What is sorely needed are tools that aid those little fiddly manual re-symbolisation tasks.... and make them persistent betrween sessions. These include:

• Paintbrush tools: View 1- latest CVE. View 2 Hidden or DH elements. User paintbrushes from View 2 to 1. User zooms in one view, the second view zooms to the same camera point. *
• Fence or rule-based Criteria Set, Thematic Display re-symbolisation. A lot of embellishing is forced upon the user because of those 'long tail' type situations that the regular controls like Ref:levels don't work.
• Display-system based tools:

1. Things like Depth cue-ing, silohoutting can be provided by accessing the graphics pipeline to pick out the 'Outer' edges for a roof or massing 'silohoutte'.
2. Differentiating 'Occluded' edges to reduce all those redundant overlapping, underlapping linework that we currently get with CVE's, which makes snapping/embellishment a pain.
3. Piranesi or Pointools-style plane based selection allows the user to select all elements that are on a particular plane or view depth. 
4. Display Priorities: is disabled in 3d. I think is a bit of hasty. The user should be able to give 3d elements a Display Priority that would be useful when the 3d elements need to be displayed in 2d 'print'-oriented views, and CVE's (with or without Drawing Rules). Most models have both 2d as well as 3d information. It may be also be useful to sort out those pesky problems that come up with Compound Cell 2d Drawing Symbols that need to overprint visible edges, or other Drawing Symbols correctly. When a circular duct  or door is cut, does the symbol get placed at the bottom or the top or at the cutting plane or at the centreline or at the cell origin....? I forget don't want to remember already :-) I suspect it's a good thing that we have 'pre-processed' CVE's. I can see the BV engine going spare trying to sort out which Drawing Rule to sort out -in which sequence- in those inevitable multiple-discipline situations.

• Tools for 'one-off' element-level Overrides or embellishments will always be needed. Sense distance etc related to the cut will catch most things, but there will be inevitable exceptions. The kitchen sink link above is good example. Getting 'outlier' objects that are above the sense/view depth to show like roof scuppers, overhead windows etc are other examples. This kind of 'polishing' is probably too 'ragged' for the 'Qvision pass' which needs to be fast / responsive, but hopefully OK in the CVE / Drawing Rule end of the pipeline, especially if we do get incremental CVE's eventually.
• Ignore grouping mode: a lot embellishment is the result of not being able to re-symbolise what is nested in grouped/orphan cells. You end up having to hide, copy, drop and resymbolise.... thereby creating another loose-end that needs to be mopped up the at the next CVE run.
• Unification clean-up: Wall joins, column/wall (columns cut walls) and other unification clean-up are big part of embellishment. We need to be able to locally override what the unification engine comes up with globally.... in a granular and persistent way. Again, H+C provides the raw functionality, but this needs to be coupled with some tracking or associative functionality that would spare the user having to re-do the same 'correction' for the same wall or whatever, even the wall hasn't been changed.... again and again.

3. LOD-based embellishment: We need to be able to glue/offset 2d embellishment graphics to the extracted graphics. We model a brick wall in 3d.... we make a cut/CVE through the wall... we insert a high LOD brick cell/pattern/linestyle that is aligned horizontally/vetically with the wall. Wall moves... new cut/CVE... all your details are messed up. It would good to be able to use the array tool or associative snap the detail graphics/annotations to the extracted wall's TF guideline or edge, making a persistent link between the elements.

In these BIM/3d working times, It is essential to think about 2d drawings (complete with embellishments/annotations etc) in context with 3d models. In the AEC space, the emphasis has been on 3d models, with 2d drawing seen almost as a 'byproduct' of the 3d model. I think this is a bit too simplistic, and Bentley's more balanced Hypemodeling approach is big improvement and -so far- a fairly unique proposal. To work effectively, we need tools that 'fuse' 2d and 3d info together in a spatially-aware way. SS3's back-referencing tools provide a 'beach head' do this in big way down the line.There are also some pretty impressive 2d/3d stuff that are popping up in PowerCivils and Descartes STM development that will hopefully spill over.

Working with 2d drawings now means having to be able to flip between the 2d and 3d model. A lot of 3d TF elements like slabs already store their 2d cutting profiles, and local coordinate info locally. There needs to be minor tweaks to the display system to allow the user to 'tunnel' into a 'sketch plane' container/environment quickly, greying out the rest of the model etc, and allowing the user to edit 3d elements from a 2d drawing. Handles? Copy profile, mod using standard tools, replace and regen solid/surface...?

The fact is that a lot of embellishment work will merge with normal annotation/dimensioning and detailing work... and become increasingly dominant as the design develops. A lot of problems will be picked up in 2d (regardless of how much clash detection you do) and a lot of decisions will be made in 2d first, before being propagated to the 3d model. It's not a '3d first' one-way street. This means frequent activating / flipping between multiple 'working'  models... Most models are really assemblies of multiple submodels. Say you need to develop the design of column. The column is in the structural frame model, the walls are probably in the architectural model. And you have your 2d drawing/sketch with all your dims/hatch/annotations etc. Changing the cladding means flipping through at least three models. This is one advantage Revit's everything-in-one-file approach avoids. Multiple Active Refs, please :-) 

* I know of a large ongoing rail project where the model is too large to cut in one go. The team has 'tiled' the model into 25+ areas in order to get any extractions at all. The extraction still has huge problems and needs to be embellished.. repeatedly. The same roof line has to be corrected 25+ times... multiply that by all the other corrections... over the life of the project.... not great for a cutting-edge tech company's reputation.... in one of its 'own backyard' sectors, IMHO.

This tool, whilst interesting seems to be a bit of a blunt instrument at present. For instance here I'd like to clean up this failure of wall an roof to unify (as a workaround while I find a better solution!). Hide just turns off the whole wall, whereas I would like to just mask clip the unwanted parts of edges. Copying in the whole roof and wall elements would be like going back to manual drafting.

Then once the element is turned off the only way to restore it is to revert to Dynamic. There is no trace of the hidden element to turn back on.

Maybe this is another toggle or panel to add to view attributes? A 'Show Hidden CVE Elements' toggle at it's most basic or preferably a list with a field for 'reason for hiding'.

Marc, see my response from the 1st below - you can turn on the display of these hidden elements from the reference dialog.

Beg pardon, you did point that out. Ignore my last two sentences, the first one still stands though!

No problem!  I do see your point in that example, where turning off both elements probably is the best/only way to make use of the Hide function,

This is something that should be addressed in the modeling and not in "tricks" like hiding something.  If this was done with forms there would not be the issue.  Walls and Forms, roofs, etc, need another leap, in that (just like in this example of same materials) are just basically forms.  And during placemnt top and bottom are relevant HOWEVER after that sides are sides. Top side should be able to merge to end side.

Though I note that if both are the same material they should display as one in DV.

If they are both the same material, but different pours or constructions, would there not be a expansion joint or construction joint of some sort  - and then that should be modeled.