Materials in the linked file are lost, Tweet

[SamuelAB]

Can you not use the Material name instead of the material ID?

It would be totally inconceivable to merge files for rendering purposes. This workflow would make the plugin useless compared to the competition. Merging Revit files interrupts the workflow, makes the model useless for live collaboration and takes a lot of time.

[prehabitat]

This issue seems very similar to [duplication risk] when loading materials into parameters within families (to then be loaded into a project) or even possibly nested families into (parent) families (then into a project).
The issue becomes the invisible ‘ID’ that Revit keeps but we never see.
For materials, my rule is always set <by category> in the family and apply the material from the project.
Could links have project material parameters which could be controlled by the container? Not sure, not a workflow I use enough to have tested it (yet).

For nested families it’s harder, you basically need to insert the nested family into two parent families which contain it - in the same session - to not get that silly ‘do you want to overwrite..’ message.

I understand these examples are a little OT & neither of these probably help, but they highlight how sensitive Revit is to its own internal (largely invisible) unique identifiers for elements.

[jimho]

Dear Paul，
Thank you for your quick respond and your great efforts to improve the plugin,
before getting into more detailed discussion, please allow me to highlight again the importance of the workflow I mentioned.

The plugin was not specifically designed for the workflow you are using, so you may have some challenges using it this way.

I have to say, it is NOT only a personal preference, I would say it is critical for Entire revit world, and ALL revit user, which you can not reject.

The reason I emphasis on this issue is that the advantage of Octaine enable itself great potential to becomes a powerful tool to help designers developping their design,
Octane is not only for final production rendering like traditional render engines. (before rendering to merge everthing, this is that type of thinking) It is much more powerful.
To make the potential becomes true need right workflow.

Though there is some others walking along this way already, and doing quite well, like Enscape/ Twin motion and lumion, even Vray is catching up soon,
Yet personally I do prefer Octane, which potentially can be the best, to achieve this, there is major barriers to conquer, quite a few of them I have to say which are even really painful....

Paul,
Hope you read the above, and this bug is a critical one I believe you will get it resolved in a perfect way.

Thanks again and best regards,

Jim

[jimho]

You could probably get around this by having all your Revit material pre-defined in the startup .rvt file which each team uses. Then the material Id will all match.

this is not practical,
reason 1, element ID is difficult to use, kind of invisible to users (though not really invisible, but too difficult )
reason 2, for the design process for projects are moving on, number and types for the materials are not controllable. new materials are introduced and created every second.
reason3, it is a software level issue not a user level issue, should be resolved by software.

Another idea would be to have group 1 use "1_MyMaterialName" and group 2 to use "2_MyMaterialName", then the materials will likely be unique.

I did try this before the very first post, the problem remains, actually you have expained already, revit regonize the element ID instead of the nameof the material.

I feel it is a mistake that to search and compare the material's element id when loading links, as you had mentioned. two different material may have same element id because they are from two different revit file.
why can't we just simply load all materials from link and keep the material name and creating new element ids for them in the containers file?
eg. in link 1 Material A (name) is water, element id is 000666(just for example), in link2 Material B is glass element id is also 000666, it is obviouly wrong because in the link1 there is water, then the glass from link2 is therefore ignored, sound quite strange, but this may happens.

Jim

[face_off]

I understand the importance of what you are asking. However that is not the way the plugin works currently and it would take some effort to rework the way materials are loaded from linked files which is outside of the scope of the support I provide. May I suggest you post this as a feature request via the Resources->Feature Requests menu at the top of this page so that OTOY see it and can action it.

Thanks

Paul

[jimho]

Dear Paul，
Thank you for your suggestions, we do appreciate your great supports
I am doing the request rightaway.

Jim