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!
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.
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
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!