Here at Speckle, we have been busy over the past month, preparing a series of changes that have huge impact for Arch-viz workflows.
With the release of 2.4.0, most of our connectors have received some ❤️ in the render material department. We have extended our support for receiving geometry with materials in Rhino, Revit, AutoCAD, and enhanced our support for sending Revit and Unity elements with materials.
Even better, built elements such as Walls, Roofs, and Beams, now can have multiple materials - this makes your stream elements from Revit much prettier both in our viewer and also when received in other applications like Rhino and AutoCAD 😊
In 2.4.0, we have addressed the issue.
And, the Revit house has never looked better!
Shout out to Tim Hoffeller for his initial pull request, and RJ for helping us solve a related issue with wall mullions. 🙌
For a full list of changes, see our Public Change Log.
The technical details
Previously, within our Objects kit, Built Elements and Breps had a displayMesh property that was used to display the object in the web viewer, as well as a conversion fallback when receiving in connectors that don't have native support for that type.
Using a single Mesh has the limitation that only a single render material could be used per element (without having to resort to nested child objects).
With version 2.4.0 of our objects kit, Speckle objects that previously had a Mesh displayMesh property now have a List<Mesh> displayValue property.
The old displayMesh prop has been deprecated, and will stick around for a few releases to maintain backwards compatibility.
For maximum flexibility, all of our converters have been updated to accept the new displayValue prop, as well as the old displayMesh prop. We assume this prop could be a Base or a List<Base> (or subclasses of Base). This should provide maximum flexibility for those creating their own custom Base objects, as well as backwards compatibility, so you can receive your old streams the same in newer connectors.
What does this mean for my old streams?
Nothing, they will be received fine in newer versions of the connectors.
None of the changes related to materials and dislpayValues should break backwards compatibility.
What does this mean for my custom code/scripts/kit/connector?
If your code directly gets/sets a displayMesh property of a speckle object, and you are observing issues with newer commits, then you may want to make some small tweaks. Otherwise, you should be totally good to go!
For developers who are handling received objects' displayMesh property. You may need to check for a displayValue prop as well, and/or ensure your code can handle this property being a List.
Developers who are sending custom objects to speckle don't need to change a thing, since all of our connectors still accept objects with a displayMesh. However, you may want to consider using the "displayValue" property instead to align with our new naming.
Having issues? Let us know on the forum, and we can help!
What about other material improvements?
Our ambition to better support materials doesn't stop here. We have plans to improve support for different PBR shader models, UV coordinate improvements, Light objects, and (eventually) have full textured material support. We would love to hear your thoughts and wants on our forums!
