Objects in the stream are made by me and not a connector.
Revit 2022 v2.5.2
The input argument "name" of function Autodesk::Revit::Proxy::DB::MaterialProxy::Create or one item in the collection is null at line 699 of file E:\Ship\2022_px64\Source\Revit\MaterialDBAPI\gensrc\APIMaterialElementProxy.cpp.
Parameter name: name
I’ve done the bare minimum beyond instantiating a Base Object with displayValue and RenderMaterial.
Do all materials need a name applied in order to be read by Revit? The same data read into Grasshopper imports but has no materials.
I think @Jedd can give you a better overall explanation on how materials should work, but afaik:
There was an issue reported around IFC imported materials causing trouble, and it was due the material missing a
(sorry, can’t seem to find that thread now). (found it! Issues receiving IFC in Revit · Issue #1261 · specklesystems/speckle-sharp · GitHub)
As for Grasshopper, since it doesn’t really understand Materials (you can only paint things with the Preview Geometry node) any geometry will be converted without it.
I have some thoughts on improving this to enable better access to an object’s material… but haven’t gotten to it yet.
So for now, I’d suggest to try and add a name to your materials, or wait for a better explanation from @Jedd
I should read the Objects library more thoroughly to spot mandatory fields.
Henceforth all materials will be called Bob as a fallback.
I believe Revit materials to have a Unique name, as Revit uses the name to check for identity.
So different materials must have different names otherwise you might run into issues with the wrong material being applied. (untested)
You could name your materials a random string, or more ideally, some sort of hash.
We could consider supporting “nameless materials” in our connectors, and fallback to using the speckle id / hash if no name was given.
Changing this line to:
ElementId materialId = DB.Material.Create(Doc, speckleMaterial.name ?? Guid.NewGuid().ToString());
Did the trick for me when testing locally
Mhmm, that would be a reasonably effective.
Although, this would lead to lots of duplicate Revit materials being created right?
(e.g. with multiple objects with the identical
RenderMaterials and when the model is re-received)
It might be better to use the ID of the
RenderMaterial, since this is a hash of the object, only one Revit material with that name will be created (and reused for when converting other materials with the same name)