Optimization rules produce suboptimal results when whole model is shown and some components are colored

[buildingsmart]

Optimization rules produce suboptimal results when whole model is shown and some components are colored

[ErikPijnenburg]

I consider huge viewpoints as one of the main drawbacks in the BCF system so option 2 is definitely not good: online systems need to send all those GUIDS making it unusable.

We have faced the same problems with selected objects: suppose view whole model, select only two.
In our current releases we implemented it like this to be robust:

• components flagged as selected or colored are consider as visible even when not flagged as visible or even when flagged as hidden.
• visibility list has priority over hidden list if both are there.

The result is this:

1. If no components are flagged as visible we show all. If additionally objects are flagged as selected, or colored that doesn't change visibility
2. if some components are listed as visible and others as selected or colored, we extend visible list with the selected/colored (In fact this can be considered as a bad export, but we fix like this)
3. if some components are listed as hidden we show all components except the hidden objects. If there are additionally selected or colored components, we consider them visible as well. So selected components canot be hidden.

[ErikPijnenburg]

Additionaly I want to make the remark that many BIM authoring tools do not support coloring of components without changing their properties... So the coloring cannot be supported in most BIM authoring tools (yet).

[pasi-paasiala]

@ErikPijnenburg
What is the exact rule how you suggest doing selection/coloring? Is it so that you suggest to turn the visible flag off when component is colored/selected.

[ErikPijnenburg]

When we recieve viewpoints we interpret as above
When we create viewpoints we save selected components also as visible ONLY if user didn't choose to link none as visible (= show whole model). So in this case selected components are not saved as visible (but neither as hidden so no inconsistencies here...)

[pasi-paasiala]

If you don't specify value for visible flag, it is default by true according to the schema, so you'd need to specify it false.

[GeorgDangl]

In the schema (visinfo.xsd), it is currently defined as this:
<xs:attribute name="Visible" type="xs:boolean" default="true"/>

So not writing the Visibile attribute is the same as writting it as true, we don't have the option currently to set it to null / undefined.

[ErikPijnenburg]

So then we have no problem ;-)

[pasi-paasiala]

How should we then word this rule?

[ErikPijnenburg]

We could define the priorities as I suggested above as "interpretation when using viewpoints" and also ask developers to respect these rules when saving viewpoints.
See also #66

[pasi-paasiala]

So is this interpretation correct:

When all components are visible and one component is colored, only send the colored component with visible flag false?

[pasi-paasiala]

And what about the situation when only one colored/selected component should be visible? Should the single component then be sent with visible flag true + the coloring/selected info?

[ErikPijnenburg]

Let me share below remarks which hopefully makes this clear:

Visible=false means the component is hidden. So Pasi on your questions the solution is:

When all components are visible and one component is colored/selected only send the colored component with no visible flag. Since: no components listed with visible flag means whole model.

Would you have send the visible=false we would neglect that flag since components listed as colored/selected always have to be visible.

Would you have send one colored/selected component with visible=true it means ONLY that component is visible AND colored/selected.

So it makes a difference if the flag visible is "mentioned" or not. This is the key to the solution.

By the way:

Visible = true by default ONLY has effect on components listed in the Viewpoint. If a component is not listed in the viewpoint at all the visibility is depending on the info in other (listed) components. For example if one component is listed with visibility=true it means for all the other components in the model to be hidden. If one component is listed with visibility=false it means for all the other components in the model to be visible.

How to deal with contradictions in viewpoints. We give lists of visible components priority over lists of hidden components.

In our view this is the correct logic when using a viewpoint:

1. Collect components with "mentioned" visible=true. If none it means show whole model.
2. If there is a list of components with "mentioned" visible=true: add all selected/colored components to this visible list
3. If list of visible components is still empty: collect hidden components: components with visible=false
4. If there is a hidden list: substract all selected/colored components. Then show whole model except the hidden components.
5. Select/color components

Finally we advice for creation of viewpoints:

• not to use the hidden lists (visible=false) since the visible components then will change over time when the model contains more and more components.
• use selected rather them colored since colored cannot be supported in BIM authoring tools (yet)
• list as little components as possible

[pasi-paasiala]

I don't think the "So it makes a difference if the flag visible is "mentioned" or not. This is the key to the solution." can be used in general as a way to make a distinction. If the value is not mentioned, it defaults to true and we cannot rely on people using a library that distinguishes between given and default values.

[ErikPijnenburg]

XML-'wise' you are right, but then the only solution is to change the XML-definition. Any other suggestion?

[pasi-paasiala]

I think we should use the visibility flag set false as follows:

Assume that you have a model consisting of three components, A, B, and C. The following table illustrates how combination of visibility and selected/colored flags would be used:

Case	Exported to BCF
All components visible	Export no components (already agreed and working)
Only A is visible	Export only A with visible=true (already agreed and working)
One A is visible and it is colored	Export only A with visible=true and colored (already agreed and working)
All components visible and component A is colored	Export only A with visible=false and with color information (new agreement)
C is hidden, A and B visible with default colors	Export C with visible=false (already agreed and working)
C is hidden A is colored, B is visible with default color	Export C with visible=false, export A with visible=false and with color information (new agreement)

This would cover the basic cases. What I don't like that we're misusing the visible flag in a counter intuitive way. Of course the current agreements already say that the flag can be ignored when color or selected information is present.

[ErikPijnenburg]

That could be a solution but still changes the definition. The documentation tels us about the visible flag: "This flag is true when the component is visible in the visualization. By setting this false, you can hide components that would prevent seeing the topic from the camera position and angle of the viewpoint."
This would create a contradiction.
So then we also have to agree on "visible=false" does NOT mean the object is hidden....
Or do you suggest this: "visible=false" means the object is hidden UNLESS it was selected or colored. I dont like that,

[pasi-paasiala]

I don't say that I like it either, but that's the only solution I can think of without changing the schema.

[ErikPijnenburg]

OK, let's agree on we don't like it and let's give it some more time to decide. To be sure we didn't miss any situation or upwards compatibility issues against those thousends of viewpoints currently existing.

[theoryshaw]

Or we make the architectural decision not to accommodate backward compatibility.

Or only do it, for limited amount of versions back.

[pasi-paasiala]

It'd be good to be compatible within BCF 2.0. Compatibility with BCF 1.0 starts to be questionable.

[gschleusner]

This is were a relation based system would come in really handy. We are seeing this issue as well. I have generated a few 100mb BCFs when automating some rule checks. I know changing the schema is painful, but the reason the BCFs are so big for us is that each one of the viewports lists nearly half of the model elements as being part of the view port vs, having a single list of elements and then a flag/relation indicating if its part of a number of view ports. So you end up with an elment be writen 10s of times in the same BCF.

[ErikPijnenburg]

Pasi, I suppose you propose above to use for selected=true the same logic as for colored ?
Question about backward compatibility:
If a viewpoint contains only "B: visible=false and selected=true" it will mean show whole model and select B
If a viewpoint contains only "B: selected=true" (can exist in existing viewpoints) it means in our current implementation show whole model and select B, but in new situation is will mean show only B and select B ?

[ErikPijnenburg]

What shall we do with this discussion ?
Currently we see the most problems with large viewpoints coming from Solibri where a few objects are selected (or linked to a slide) and the whole model is visible. Solibir then exports to BCF all components with visible = true. Current record we have seen is 308.000 (!) components in one viewpoint.

[ErikPijnenburg]

Would it be possible to reach a decision on this matter soon ?
Currently there are two suggestions for solving this:

1. introducing a VisibilityBase like suggested in #68
2. Pasi's suggestion above to export with visible=false and with color/selected information as new agreement to show all and select/color a few.

If the first one does not change BCF 2.0 definition I am in fovor of moving forward with that one.

[rahulsule]

I have identified following cases for tests. (Additions and corrections are welcome)

Assume there is a model that contains 12 components.

case 1 : All components visible
Result : no components sent

case 2 : Only two components visible (10 components are invisible)
Result :
Component IfcGuid="A" Visible="true"
Component IfcGuid="B" Visible="true"

case 3 : Ten components visible (2 components are invisible)
Result :
Component IfcGuid="A" Visible="false"
Component IfcGuid="B" Visible="false"

case 4 : Only two components visible out of which one selected one colored
Result :
Component IfcGuid="A" Selected="true" Visible="true"
Component IfcGuid="B" Visible="true" Color="66CCCCFF"

case 5 : All components visible and one selected one colored
Result :
Component IfcGuid="A" Selected="true" Visible="false"
Component IfcGuid="B" Visible="false" Color="66CCCCFF"

case 6 : Four components visible (8 components are invisible) and one selected one colored
Result :
Component IfcGuid="A" Visible="true"
Component IfcGuid="B" Visible="true"
Component IfcGuid="C" Selected="true" Visible="true"
Component IfcGuid="D" Visible="true" Color="66CCCCFF"

case 7 : Ten components visible (2 components are invisible) and one selected one colored
Result :
Component IfcGuid="A" Visible="false"
Component IfcGuid="B" Visible="false"
Component IfcGuid="C" Selected="true" Visible="false"
Component IfcGuid="D" Visible="false" Color="66CCCCFF"

[ErikPijnenburg]

The problem with hidden-lists like in situation 3 and 7 is that it only works well when all aspect-models were loaded at the time the viewpoint was created. When extra aspect models are added in viewing software, a zoom-to the viewpoint will cause too many components be visible. We don't use/recommend the hidden-list solution for this reason: it can cause un-clear communication.

To prevent big viewpoints it is better that software warns users when they are about to create big viewpoints. And teach users best practices.

[pasi-paasiala]

I don't think the solution I proposed works with spaces and openings. They are invisible by default. So how can we distinguish between a viewpoint where all components + two spaces are visible from one where only those two spaces are visible?

[ErikPijnenburg]

IF (no components, no spaces, no openings have visible=true) THEN it means show all components, hide spaces, hide openings
I think a very simple addition to the interpretation can solve this:

IF (one component or space or opening is exported with 'visible = true')
THEN show only the items with visible = true (whatever type they are, component, space or opening)

This means:

If you want to show two spaces an not the rest of the model
= export two spaces with visible = true

If you want to show two spaces + all components
= export all components and the two spaces with visible = true

It is not optimal but still possible in the current definition.

[pasi-paasiala]

In a telecon between me, @jasollien, Pieter, and, Yoram, we came up with the following suggestion:

We export components, spaces, and openings as different sets in the visinfo. Each of these sets can have a flag for default visibility. The values are:

• HideAllExcept:
  • Use this value when the invisible set is smaller than the visible set.
  • List here the components that are hidden, colored, or selected
  • For hidden components, set the visible flag false. For selected or colored components the visible flag is irrelevant.
• ShowAllExcept
  • Use this value when the visible set is smaller than the invisible set.
  • List here the components that are visible, colored, or selected
  • For visible components, set the visible flag true. For selected or colored components the visible flag is irrelevant.

[linhard]

#85