Nice blog post on open source arch tools from Dimitrie from speckle works

Nice that they understand that it's better to keeps Speckle's code open sourced
https://speckle.systems/blog/opensource-aec-speckle

MoultpaulleeJesusbillDarth_BlenderCyrildimitriekaiaurelienzh

Comments

  • Trying to understand what it does by reading the https://speckle.systems/docs/essentials/introduction/what

    Seems too abstract for me :oops. Any simple usecase anybody can explain a bit ?

    Thanks.

  • @paullee: @dimitrie would be able to provide a more accurate description but in my own experience :

    One line description

    Speckle allows you to transfer data and geometry through network. It defines a common geometry language.

    Use case example

    Architect which works in Rhino want to send his geometry to Civil Engineer which is working on Blender
    1. Architect creates a stream and send it to a remote database (Speckle Server) using Rhino or Grasshopper Speckle plugin
    2. Civil Engineer retrieves the stream from Speckle Server using Blender Speckle plugin
    3. HVAC engineer which is stuck on Revit join. He connect to Speckle Server and retrieves the stream using Revit Speckle plugin.
    Engineers are now happy to be able to work with a model from a software which currently do not have native export to IFC.

    Current opinion

    Pro : You can transfer geometry and data with ease and in short time. It works with common AEC softwares. Easy to communicate a model. git (git like ?) model versioning.
    Con : Data-structure is not normalized (IFC schema could help this matter in my opinion). You cannot work on same objects (eg. security engineer cannot fill in fire protection data in an architect's wall).

    paulleebasweindimitrie
  • Thanks, so it achieve something IFC want to do

  • They want to bypass the overhead of exporting/importing IFC to & fro different software, because not all of them are IFC-certified. They also want to focus on geometry and just what data you need to transfer. I think that's good for collaboration. But maybe not so good for data storage.

    paullee
  • It's essentially a hosted database with a very open API that could be used as simply as transferring over a few curves from Rhino to Revit to being a database for a whole construction project, software agnostic. So, yes similar to IFC in some ways, but could be as simple or as complex as one wants it to be without having a "standard" per se. But it is good for data storage, in fact it should be the place for data storage, for projects and teams committed to it, with each team and software having access to the central database living in the speckle server.

    paulleedimitrie
  • Hey @dimitar! (fellow namesake here 👋) Thanks for posting our article on OSS here 🙇🏻‍♂️I'm a bit late to the party... @paullee, I see both @dimitar, @htlcnn and @Cyril already gave you super good spiels on Speckle's sauce - do let me know if any extra questions!

    @Cyril, good points there!There's nothing technically stopping us from having an IFC-based Speckle kit, and personally I really hope that will come to be in the future. Let's see!

    PS: To clarify what a "speckle kit" is, it's basically a schema and its implementations to and from a given set of software apps. Think there's a doc page somewhere, ah yes: the high level piece and the more techy one. The fun part is that Speckle is "kit-agnostic", so people can swap-in-and-out object models and their implementations. And you can extend any Speckle object dynamically (but this is just getting things more confusing).

    CyrilMoultpaulleedimitarJesusbill
  • @Cyril could you maybe improve this page? Your concise explanation is great. https://wiki.osarch.org/index.php?title=Speckle

    Moult
  • @duncan said:
    @Cyril could you maybe improve this page? Your concise explanation is great. https://wiki.osarch.org/index.php?title=Speckle

    I added some info and references.

    MoultduncanJesusbilldimitrie
  • Engineers are now happy to be able to work with a model from a software which currently do not have native export to IFC.

    Soon it will support IFC and IFC EXPRESS natively

  • The day you shared the EXPRESS add-on for VSCode, didn't guess the possibilities? :))
    https://github.com/AlanRynne/ifc-syntax-express-parser

  • Thanks @dimitrie , would like to see IFC is supported :)

  • @dimitrie said:
    Hey @dimitar! (fellow namesake here 👋) Thanks for posting our article on OSS here 🙇🏻‍♂️I'm a bit late to the party... @paullee, I see both @dimitar, @htlcnn and @Cyril already gave you super good spiels on Speckle's sauce - do let me know if any extra questions!

    Hi @dimitrie. We met at one of the breakfast events at Arup (I'm friend of Maggie's and the other Dimitri). Anyways, really happy to hear that you have reasoned out a business path for speckle and that keeping it open source is indeed the best way forward.

    duncandimitrie
  • @dimitrie how do you see the future of data models like IFC in a world where an API to API direct approach is more immediate and now more feasible?

  • edited November 17

    @duncan, trick question there!

    Schemas and validation will always have a role to play, but it's going to be a much more decentralised affair - completely against the stated ideals of IFC. I spent half my PhD thesis on this, but it's actually common sense: aiming to create a complete standard describing the built environment is a babelian affair, doomed to fail. The successful examples from outside our industry always harness composability over completeness.

    As such, I see IFC as yet another standard - one of potentially many; this is maybe something that you hinted at through the indirection in your phrase at "data models like IFC" 🙇‍♂️


    @dimitar - wow, the days at Arup! I secretly miss going back to the office, and the people there!

  • IFC is just a small part of the whole picture
    And maybe even doesn't have any role in the new future
    The industry needs new standards, schemas and file formats, and new means of communications, ...
    And for sure we work on them, but like any technology, we won't introduce them publicly very soon

  • @dimitrie said:
    Schemas and validation will always have a role to play, but it's going to be a much more decentralised affair - completely against the stated ideals of IFC. I spent half my PhD thesis on this, but it's actually common sense: aiming to create a complete standard describing the built environment is a babelian affair, doomed to fail. The successful examples from outside our industry always harness composability over completeness.

    This touches on something I've felt for a while especially with IFC. I understand the need to have a set structure for organisation and compatibility purposes but it feels too complicated sometimes - especially when trying to go between software and if missing part of the IFC foundations (site, building, storey, etc), the whole file doesn't translate.

  • edited November 18

    I thought I'd weigh in a little on this discussion. Speckle and IFC are two different concepts, both of which are complementary. One cannot replace the other. Both address interoperability, but from different angles.

    Disclaimer: I have not used Speckle 2.0,so I'm hesitant to make these statements, so these statements are based on my understanding of what Speckle does only - not practical experience, and certainly not any in-depth knowledge of Speckle. I toyed briefly with Speckle 1.0. I could be totally off the mark here.

    Speckle defines a method of transferring data from one tool to another, but is agnostic of schema. You can use any object model, although I think Speckle comes out of the box with a basic object model. This means that Speckle is technically optimised and great for "getting data to where you need it right now". Because it is agnostic of schema, it also means that you can technically use the IFC schema as your object model to describe the data, then use Speckle to transfer it from app to app. But what it isn't so good at, and doesn't try to be good at, is locking down a standardised schema.

    IFC is almost the opposite. It defines a schema, and is increasingly agnostic of the method of transfer. You can use any transfer method, but it comes with a few well supported ones, such as the IFC-SPF, which is the atomic file-based data store that we all use. This means that IFC is great at very richly describing the built environment in an internationally standardised manner that you can view in 30 years time and know exactly where to look for a particular piece of information. Because IFC is agnostic of transport, you can actually ignore IFC-SPF and the whole complexity of the full IFC schema, and only send a little portion of what you need. This is actually how MicroMVDs and some of the native element roundtripping in the BlenderBIM Add-on works. In IFC5, the single monolithic IFC SPF will break down, as it will now support linking and referencing. This means that IFC SPF can now be tiny little pieces of data. If you don't want to wait for IFC5, you can probably do this right now with IFCJSON.

    In theory, you can use the BlenderBIM Add-on to absorb an IFC, and then use Speckle to transfer portions of IFC data to another app. I haven't done so myself, though.

    When it comes to a more practical situation, Speckle is tackling a technical issue - quick, compatible, data exchange. In contrast, IFC is actually primarily tackling a political issue - putting on a suit, dealing with building laws, international standards registration, engaging government bodies, and all the rest of it. Spreadsheets are great for quickly tossing some data. However, once you're dealing with a huge real estate portfolio, standardised spreadsheet templates really help.

    Both are, in my opinion, valuable pursuits that are necessary for the industry. That said, IFC has had an absolutely shocking history (and current state of affairs) of poor implementations which have left a bad taste in everyone's mouth. Remember the early web and "works best on IE"? The organisation model of buildingSMART does not help either. There are also some very clear cases of reinventing the wheel poorly (MVDs, materials, lighting data, scene descriptions) - hence I also completely agree that trying to centralise all schemas into a single one is notoriously difficult, though not without precedent (have you seen the spec for the web? How complex is the codebase of a browser? It ranges, doesn't it? The web is a crazy mishmash of specs - for better or for worse - hint: I use mutt, and I went through a phase where I browsed with w3m). If buildingSMART continues down this path and succeeds, a huge kudos to them to accomplishing an incredible feat. If buildingSMART fails... well, there are a few open data standards to replace IFC when the time comes. Also, by that time, at least we'll have tools like the BlenderBIM Add-on to ensure that all the IFC data that is currently being produced en masse by the industry can be captured.

    brunopostledimitarCyrilMeetlattlangkaiaurelienzhpaullee
  • Is it permitted to post in this thread if your name is not dimitri*-based? :) i think this all works like public transportation in cities. If you come and say "only subway can solve city transportation issues!" you probably will end up making problems worse. And more and more, crossing layers of different modes (bike, subway, bus...) is seen as bettering things. Here too i think, having many different communication layers between apps is the way to go... What i find really interesting in speckle is the versioning and transactions management, you can really imagine being able to have many people working simultaneously on a same "model" (or dataset) with it.. Also high time that i have a new look at it :)

    dimitarpaullee
  • Hi @yorik! We're in the tight spot of moving from 1.0 to 2.0 now, so docs are scarce for the new things. But re the last things you mentioned - versioning and management - i'm super excited too - 2.0 is for us a big investment in a solid base for the future.

    The gist is that we've enabled transports and dynamic decomposition of objects into those. Transports can be anything from writing to disk, sqlite, s3, as well as the canonical Speckle Server. The server allows for querying as well out of the box, even across 100k+ objects.

    The user land models that we've strapped on top are very git-like - a bit dumbed down, no merkle trees for commit history integrity, etc. - but I expect this to be next year's search based on what our users will say. Anyway, docs some useful links:

  • Thanks for helping me better understand the aims and uses of these two approaches.

Sign In or Register to comment.