Classical collision control (in Tribon Mx)

Collision control is important when user goes for detailed design and Tribon has this feature well developed.

In order to check for collision user should go for Tools>Model>Collision Control… function.

Collision control function

When going for this function user is prompt with a window called “Collision control”, having title “Collisions between” and three options:

1. Indicated models

2. Indicated models and view

3. Restrict on model types

A little bit strange, user should go first for 3. to choose the type of model items that have to be checked. I repeat: type of model items, not the items - these are collected using options 1. or 2.

Regarding these two options, I think is useful to add here some aspects that are missing in both Training Guides and Documentation:

1. lets the user to collect all items from a model view(s); that’s happening when he/she is choosing the level 1 for the subpicture. Moreover Options (++) will return the collecting loop to the choosing level step; and this can be very useful when user like to see collision of all items in one view with only one item from another view (example: user had added a new structure in the model and wants to check collision between this one and all the other existing items in the surroundings).

2. permits the user to collect one by one model items (in my opinion the option name is wrong and confusing, since selection is no view dependent - till now I don’t have an explanation for it).

After selecting the model items that have to be checked (all of them should be in one view of the drawing, in order to get collected), we have some “Result” options (from a window named also “Collision control”), as follow:

1. “List”: user will be prompt with a window having all interferences presented simplified. Example: PJ-MOD1-BL23 and PJ-MOD2-CO5 collided 2 times. In the same time in Message Window is written total no’s of interferences found.

2. “Highlight all”: allows user to see in view or shaded mode/viewport all clashes. Here also the total no’s of interferences are written in Message Window.

3. “Highlight one by one”: allows user see one by one all clashes and to take a closer look (only in shaded mode) to them. This time into Message Window can be read more details on each collision, like: PJ-MOD1-BL23 (7, HARD) interfere with PJ-MOD2-CO5 (25, SERVICE AREA )! , where 7 and 25 are part id’s.

4. “List on file”: the detailed list of interferences will be saved into “lst” directory of the project as a file having “lst” extension and free name (up to user).

5. “Set (none) shaded mode”

Note: the above list of options is slightly different in M1.

Collision control of what?

Many people just ignore the collision control build-in feature, and they are going only for visual inspection, since this kind of check looks reliable enough and much faster than the Tribon collision control. In fact using shading mode/shaded viewport (or Design Manager, as alternative) user can see all possible interferences. Apparently it is all about his/her eyes and experience, but in Tribon virtual world doing so might be wrong.

The reason is complex, and has the origin not in the model itself, but in the entire “industry” that is hidden behind of… the presentation of the model.

Let’s make an experiment:

- open a new drawing in your current project (no format needed) , add all panels from a section (select one section with ‘problems’) in a new model view. Make a check and have the result as a list. Please note the number of interferences.

- go to Tools>Preferences… and choose Model Draw Code/Panel, change the default values for the codes to ‘No’ for Brackets, Cutouts, Profiles and ‘Thin’ for Panels. Go back to your view and exchange it ‘from Defaults’.

- use again collision control function and compare the new number of interferences with the old one. The new number is smaller, isn’t it?

This boring experiment was needed to prove my point: the collision control is not only about the model but also about graphical presentation of it. And the presentation is not unique; it depends of the above-mentioned drawing codes that control the 3D appearance of the model.

What is happening behind the scene?

The system is picking the position of model part (not for the entire item!) and recreates the 3D-shape of it according to drawing codes used for the model items selected. That means the system collects the on-view instance of the model, having actual position.

Note: If the model is missing in db (the view is not valid) the user is prompt with a warning message or window. Also if the model is obsolete (and need exchange), the all model items, not only selected for checking against collision, from the view are automatically exchanged if as Result options are used 2. Highlight all and 3. Highlight one by one (‘Repaint’ could be needed here, depending how user left the function).

However, the best result is with valid views on drawing (all items are updated and no ‘phantom’ item in workspace).

Drawing codes and presentation

I think is clear now: clash management is controlled by the model presentation via drawing codes. But not only!

Drawing codes are handled by Drafting default keywords – for more information please refer to Documentation: Tribon M1(M2/M3) Drafting/Drafting/User’s Guide/Appendices/Drafting Default File Keywords/Drawing Codes.

For outfitting items things are more complex here. Just go to Tools>Preferences… and choose Model Draw Code/Cableway or Model Draw Code/Pipe.

Since I would like to have as example from this point a globe valve, please allow me to discuss only on valve drawing codes (controlled by the keyword PIPE_VALVE_CODE_DRAW from SBD_DEF1 Drafting default file also). In this case we have 6 codes available (the no’s in front are actual values of the keyword!):

1 - Centre line

2 - Material: draw 3D-symbol (font 0), known as default volume, if exists, else draw centre line; also this is the default value of this keyword

3 - Material & centre line: draw both symbol and centre line

4 - Symbol & centre line: as 3 (is relevant only for pipes!)

5 - Volume: draw volume if exists, if not same as 2

6 - Insulation: insulation, if added, is drawn also (there are some limitation here, not subject for this article)

In 5 - Volume we have first contact with Detail level. As you know in Volume group of component properties are found, beside name of the volume(s), the type of it/them (in our case is 2, since valves are allowed to have only actual volumes as 3D appearance), scale factor, usage code (we are talking about modelling, so it is always 2) and… detail level. This detail level let us to have ‘attached’ as reference more than one volume, depending on our purposes. Important: one detail level per volume, please.

Usage of softness, material alias file and detail levels

In order to have a clear understanding of detail levels, I will go to the origin: volume primitives’ softness.

The default value of softness is 0 (the common hard area, solid, impenetrable), and is controlled by VOLUME_SOFTNESS keyword in the same SBD_DEF1 file.

When creating/editing a volume, user can change the softness of an existing primitive, using Volume>Softness>Modify… function, or can set the softness for further inserted primitives by Volume>Softness>Default…

Softness value can be from 0 (this should be reserved to hard area) up to 9, according to rules established in SB_MTRL_ALIAS file. This is a text file, usually having the name ‘mtrl_alias’ or similar, with extension ‘def’, commonly found into ‘def’ project directory. Bellow we have an example of a possible content of it:

HARD = 0

SERVICE AREA = 3

DISMANTLING SPACE = 4

MAINTENANCE SPACE = 5

INSULATION = 7

As result some primitives can be declared ‘soft’ and having a dedicated type of softness, according to the designation of the modelled space.

Important: if in volume some primitives are declared having softness e.g. 8, which is missing in SB_MTRL_ALIAS, then the system will automatically declare it ‘Hard area’ (this is exact spelling of it!); therefore primitive will be recognize as solid, and not soft area.

In our case (a simple valve) we need to provide service area (for movement of the hand wheel) and, if necessary, insulation. That means we have to model one volume (all primitives are hard) that will have added some other primitives, for service, which have to be soft with softness 3. The new volume should have same name as the all-hard one, but with suffix ‘S’, in order to be easily recognized - but this is not a rule.

Now our valve as component has 2 volumes, one all-hard (real appearance) and one with service area. We have to manage to use them both, according to our needs, incl. from collision management point of view. For this we have detail levels.

In our example we have to use only two detail levels, i.e. 9 for full detail volume (all-hard) and other one, for servicing.

Note: always use all-hard volume as first volume, since ‘any level’ (detail level -1) used mostly for graphical presentation leads to first volume.

There is no file with rules for using detail levels; however the best is to have established for all projects the same rules, and posted to all designers/users, as follow:

0 - not used

1 - just the box

2 - simplified volume (can be used for complex equipments)

3 - volume with service area included

4 - volume with dismantling space included

5 - volume with maintenance space included

6 - volume with another kind of space

7 - items with insulation

8 - volume with soft spaces all together

9 - full detail

Like for material alias file, this is just an example, with the remark that you have to preserve 9 for full detail (all-hard) volume.

Back to Collision control

Let’s summarize first: we have a valve and two volumes, first one is full detailed (all primitives have softness 0), and is related to detail level 9. The other one is full detail plus service area (some extra primitives are added and have softness 3); for this I recommend to use detail level 3 (there’s no coincidence, in our example I used same no’s for type of material).

Going to modelling: the default value for piping items is 2 (Material), as already presented. Due to that is possible to have in drawing, as appearance, just the 3D symbol (font 0), given automatically by the system when saving the component. Checking for clashes now can be plain futile, as long as parts of valve (e.g. rod, hand wheel) are not shown. The best is to have an accurate 3D presentation of it, by volume modeling.

But we have already 2 volumes by two different detail levels. If we change the drawing code from Material (2) to Volume (5), we can see the detail level -1, actually first volume. I suppose that we followed me and first volume is detail level 9 - this one will be exchanged into drawing. Now we can proceed to interference checks if we’d like to see if my valve is clashing to something else as hard/solid item. In order to check if valve can work in its specific environment, we have to go for detail level 3, to exchange the model item again (its owner pipe) and to use again Collision control function.

There are known following types of clashes:

1. hard area/hard area (the items cannot be mounted on ship)

2. soft area/hard area (e.g. coolers may need space for dismantling/maintenance; ignoring this, even a visual checking of the model is made, it’s hard to be 100% that there is enough space for maintenance)

3. soft area/soft area (e.g. two valves, like ours, hand wheel up - soft area/service space).

As you noticed, only 1. is important, but other two also, which are defined by Documentation as soft collision.

Final remarks:

Oh yes, Tribon collision control is complex and cannot be ignored by a good designer, due to its versatility and accuracy.

In fact concepts as material alias/softness, detail level and drawing codes are build around the collision control (also known as clash management), to serve it. Secondly is about the appearance of the model - after all, we need 3D capability to see items on ship, in order to place them correctly, without clash, isn’t it?