Internal / External Material Referencing Priorities: Update?

AFAIK...

1. MS_LOCAL_MATERIALS=1; If set to 1, rendering materials and their associated assignment tables are copied into the design file rather than using external files. Local material support is new in MicroStation V8i (SELECTseries 3) and is not supported by earlier versions (MS_LOCAL_MATERIALS).

2. MS_DEFAULT_TO_EXTERNAL_MATERIALS =1 "This should override all instances of using internal materials where possible (some portions of MicroStation are designed to only work with internal materials)". "Setting this environment variable will not automatically convert your local materials to external". It "should keep (most) functions from generating local materials". "After setting this variable If you export to external materials you should then stay in external mode. If you create a new model and open the material editor you will be in external mode".

3. "Internal material attachments are associated by an unique id. So they are independent of the name of the material."

3.1 "If you use internal materials when opening a .pal file when the material is used that version will be internal but it will still be linked to the external .pal file and if the contents of the .pal library version of the material change again the icon with the material will identify that the material is out of date."

3.2 It would be good to have a list pop up that offers to sync to the external dgnlib or pal, Assigned materials will be stored externally and 'referenced' from the external dgnlib/pal as much as possible. Does the Copy Materials Locally On Use toggle do this? Local materials will override competing external ones?

3.3 " internal materials will always have to deal with elements which use the name based attachment system (i.e. External material attachments + solids faces ?) As these elements can be copied into the file via a number of different methods."

3.4 "Here's the features I'm aware of that will create internal materials:

1) Material overrides specified in the Level Manager.

2) Materials from OBJ/SKP/3DS files that are imported into a model.

3) Captured GE terrain."

3.5 " Every time I change anything in the Material Editor, it converts the material to a Local Material.

To change it back to a Library Material, I have to first "Copy to Library" then "Remove Local Copy". But when I try to "Remove Local Copy", it gives me the following message "Are you sure you would like to delete the selected local material[s]?  Deleting a local material will also delete all assignments and attachments for the material." If I say yes, it deleted the assignment, which is not what I want. I have to close V8i and open the file in XM and then "Remove Local Copy" Most of the time this works, but if I use any of the Luxology features not compatible with XM, I lose them."

4." External material attachments are associated by material name and the alphabetically first palette containing that material name is the material thats applied. If you want the ability to switch materials based on name by using different palettes then using external materials is currently the way to go." 4/3/13: Shouldn't this be more discerning? Some Refs may be using different external mat/pal/dgnlibs, or have internal mats. How do we track down the duplicates? Italics indicate duplicates  but where?

4.1 "If a material is not an internal attached material (ie external?) then renaming the material should cause it to be un-assigned/attached from the elements in the file. "  Do we have a tool to quickly scan through and identify these 'lost' elements? Rules-based healing tool? 4/3/13: Test. seems like attachment system does not allow 'resymbolistaion' very rigid. See also Item 7.1.

4.2 "Changes and updates to the material can then be applied to the dgnlib version and this can be copied into the file when the user notices that their version is out of date. You can also use a (.pal) file as your library"

5. "One thing to note here is that currently face attachments to solids, smart solids, feature solids use the material name regardless of the internal/external material setting."

5.1 Does this mean that if a material is attached to one face of a solid, the other faces will still be dealt with by the assignment system?

6. Cells: "when placing cells or copying elements in from external files which will also copy the material across too, as your element may use the copied material to display or use the material with the same name in your current file to display depending on the palette name. We have made this material copying more robust in SS3 where if you copy a material with the same name into your current file we compare the 2 materials and if they are different we change the material name and the name on the attachment."

6.1 The Material Definition or Table Management dialog should have folders that cascade to show material used by each cell or cells by name (listing also  the deviants). Cell level management is in many ways more important than the model level in the component-reliant BIM world.

7. Hybrid assignment (look up) v. attachment tagging: "The specific functionality of wanting to use different versions of the same (named) material applied to the same elements doesn't match up well to element based material attachments with multiple internal material tables. I think a solution for this should possibly be re-visited."

7.1. Reference files with internal mat tables are preserved (still?). Those without get assignments in the master model. Should the same happen with .pal files? Shouldn't the Ref's mat assignments show up in the Define Materials dialog box in tree form as well? 4/3/13: Select Ref: Update mat/pal library or setting for auto update on (re)loading.

7.2 Should there be a 'dataflow' view so that the user can 'step through' the assignment/attachment process? Parametric Frame Builder Material Painter? Use Crosrail's asset code paintbrush tool as starting point? 4/3/13: This would also allow 'ignore attachment etc' combinations. item 9.

7.3 What if there are multiple palettes, some internal to the Ref, some pointing to multiple external pal or dgnlib's? The Dialog should list these paths for management and 'debugging'.

7.4 Should there be an option to temporarily override all attachments... in favour of assignments... with the Define Material dialog box listing the cells... or/and levels that have elements with attachments that haven't been picked up by an assignment?

8. Assignments: currently by level+colour only. What about recognising any kind of attribute / schema info? It would then be more 'Thematic Display'-like. 'Materials' has an important physical not just visual aspect. Should have consistent approach that bridges across to both  F+P and DGS, ET etc.

8.1 I-models with materials from other verticals or apps? There will always need to be changes made. Attaching materials won't work without write access, so assignments are the way to go? IFC? Bentley DataManager or i-model Transformer integration? Is there a way to redirect the material attachment unique ID-based attribute tagged onto every element/face to a table in the master model, like the Ref tool creates its own level mask for each Ref so that the user can turn levels on/off and save them independently...?

9. What are the default priorities? All attachments to win over any assignments... unless 'Ignore Material Attachments' is set? Need a 'Ignore ByLevels' switch as well? And Ignore or Force 'ByElementTemplate'...? I think ABD has by F+P. Convert to ET's for 'mstn mode' using i-model Transformer?

10. Assign + Attach materials: could do with being able to leverage SelectByAttributes to temporarily override and re-map material assignments/attachments. i-model Transformer Rule sets?

11. Material: less copying, more cascading parent:child management and storage? I-model Transformer-style rules based under the hood? It should be a one click operation to swap low to hi res materials for rendering. Not manual drag+drop.

Updated: 4/3/13.

  • Hi,

    I will go over your questions below.

    What version of Microstation are you using ?

    3.2 Copy Materials Locally On use is no longer in the interface. If you are working with local materials and .pal files they are automatically copied. Local and external materials are treated the same so there is no one will override the other.

    3.5 It should not do this if you have default to external used. Do you have a testcase ?

    4.1 If you rename a material then the external attachments should be maintianed if you choose yes in the dialog box. If this isnt working its a bug which needs fixing.

    5.1 Yes this is correct.

    7. Yes there are some problems with using multiple internal material tables when dealing with local attachments. This does need reworking.

    8.1 Yes I can see how specifying a material to use for an element based on buisness data will be useful. This is something we can look into.

    9. Yes attachments have priority over assignments, assignments have priority over level assignments. There is no Ignore material attachments.

    Regards

    Paul Chater



  •  Could all these if/then options and thier consequences be captured in a neat little table.

    .

  • Hi Paul,

    Thanks for the reply.

    Your responses 7 + 8.1 + Mstn V8i help>Surface Material Definitions>External Materials: Where materials are attached as attributes, the material assignment table still is required, to define the palette file(s) used” have got me wondering.

    I am wondering if maybe the material attribute used by the attachment workflow should be bypassed altogether... in favour of a mechanism based on assignment. Not sure, but it seems the attaching an attribute is only required for those complex elements like solids with subslements like faces that seem to be opaque to whatever the assignment system uses.

    I am guessing, but attaching an material 'name' attribute to a face will still require an offset/address/ID to the subelement in question, mapped to an address/key to the material name...which is currently stored with the element?

    What if all of this info is stored in an enhanced .mat table instead of with the element? The .mat table is text-based and contains a list of human-readable level:colour combinations per material. It can still have this, but also contain a list of addresses to specific 'faces' that will be keyed to a material.

    The assignment system already has to scan the elements sequentially and assign/map materials based on its level and colour, based on the .mat table. I guess a follow-on thread could be chomping through the list to reset the material ID's based on the stored face-specific 'attachments'.... after the 'ByLevel' and by .mat table assignment and by Element Template passes (reverse order of Materials Priority).

    This would then avoid having the system access each element for write access to i.e. 'touch' each element directly. This would also provide a single mechanism to assign materials that can use any kind of data... level, Element Template, business data, model name, cell name etc as criteria for mapping materials to. Not having to write directly to the file would also provide a way to deal with i-models that are read-only?

    I guess the enhanced .mat tables would normally be internal to the file so that any changes can be updated and error-trapped by the tools making the mods immediately, and versioned (Design History?). Any mods done externally will need to be done as a concatenation of .mat tables.  

  • bump... looking at the last Viz SIG, a long overdue overhaul of the Materials assignment/attachment system is underway. Hopefully, there will be some learning from the past. The existing Materials system has gotten a bit too complicated over the years.

    PBR / Vue Render integration is looking pretty exicting. The ability to work in a realistically rendered environment is very cool and chimes in with Bentley's immersive AND engineering-ready environment offer, led by ContextCapture, point clouds, geo-coordination etc.

    The ability to work in a 'realistically' rendered environment reminds me of the Italian BIM app Edificius. Only, you wouldn't have to export / synch to an external rendering app like Enscape, Fuzor, Lumion, Twinmotion etc... unless you wanted to.

    Maybe, the upcoming Progenio Maxx will do for the marine and internal fitout market what Edificius does for the Italian bungalow market.