Could Bentley please set the Local Materials functionality back to the way XM handles them.
With V8i it assumes you want to make all materials local materials, and tries it's hardest to make you use them this way.
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.
I have the variable MS_DEFAULT_TO_EXTERNAL_MATERIALS = 1 set in my ucf file, but it doesn't make any difference.
I'm getting a bit frustrated with this and my wintab troubles, making the whole Luxology rendering experience a bit of a letdown.
Don't get me wrong, Luxology is a great new feature. But my experience so far has been a bit of a struggle.
Regards
Michael Komnacki
I take your point Michael, I think its the visualiser way of doing things. However in the context that Robert describes, where you're flipping between files its pretty frustrating.
Thats every project for me, because our models are BA and for design and construction as well as vis.
Robert,
One thing we always supported und suggested is the 3 (resp.4) layer search strategy that Bentley supports in most cases. So you almost have System-Site-Project-User/Drawing with reverse search order (libs/images only in the first 3, mats/config in all 4).
In your described cases (and believe me for fair trade stands it is almost the same) I would create a global (site-specific) dgnlib for common materials (beside those delivered by Bentley = system), and in a project you can create a project specific dgnlib.
I do not care about the materials becoming local material. As long as you make no changes they know where they where taken from, and after changing a single one in a specific drawing you will be happy that this change (i.e.scale) is only locally. The case that you change materials for a whole project as the project grows, is somewhat like playing and not the best style. I do not say that there are no changes at all, but basic things like company logos (the most often case for project wide mats at our clients) or floor finishes are (normally) are no subject of evolution. Standards like metals and glasses should be site specific.
There is currently for most of us a great need to test and try, but after that some standards should be fixed and the need to save back in lib and provide changes to all other drawings should be minized at all. I agree that such a case should be supported by the software, but not by killing the local mats, instead the knowledge of the last stat (sync/unsync with lib/pure local - when leaving a drawing) might be used to provide an option to update those mats that where lately in sync with the lib to be updated automatically when the lib mat changes.
Edit: Robert & Robert :-), I currently do not work with BA, so your experience might be different here, but then BA should go further and support mats better. At all it is always good to discuss the different sights
I'm with you on this Rob K and others.
The old MAT/PAL method was simple and genius. You could even edit all this in notepad if necessary.
I would welcome for both methods, a switch to use either MAT/PAL approach, or local.
The local method is easier for beginners or users translating from other rendering software for sure.
In Max there is no easy way to reference materials so there is consistency (there is a way but it is overly complex)
Michael,
I'm not saying do away with local material, rather use as last resort. If there is no office or project library than local it is.
The precise problem with office standards is that they arnt and can never be absolute. The software evolves as does taste and style. The best office standards can do for me is act as a start point for project libraries. Project libraries at least are standard to the project, and don't hurt any other projects.
I agree too. We are constantly being caught out by inconsistent materials across multiple files in the same project. Despite saving to external material files. It keeps jumping back to local.
In regards to archiving, it is still problematic with local materials as the bitmaps aren't saved in the file anyway.
Pal and mat files were a great way to manage options and multiple rendering files.
Guy