I would see benefit in the ability to export all the current streams from the online viewer as a single IFC.
Is that something that would be possible? Am I missing something that would prevent this from being developed easily?
Thanks for your time, and feedback,
Regards,
~Fubar
Hey Fubar,
What is your goal for this?
Well we get a federated viewer on the screen that has streams coming from multiple different models and softwares… But if we could export a single IFC to be transfered back as the federated model with all the models included it would be a way to transfer the BIM information without having to provide the native file source
Why not create a “published” stream on which you do updates?
If this is only for transfering, this is what Speckle does best: without needing the native files, transfering data so collaboration is improved and SSoT can be maintained.
If coordination is your purpouse, it would be much more beneficial to have connectors for i.e. navisworks where you will do your clashtests etc.
If you are looking for contractual baselines, pulling in your coordination software and saving the model would be my preference
IFC is a handy format, and not all software is equally good at exporting to this format or combining multiple files to one IFC. I agree it could be very handy to be able to output a whole stream to a single IFC file.
Hi @Niels, @Dickels112 and @Fubar!
Thanks for the feedback, and sorry to not have replied sooner! Unfortunately, exporting IFC files from Speckle is not something we’re planning on supporting (@dimitrie, do weigh in if you need to correct me! 
):
The reason behind it is that while IFC has a very strict way of structuring the data, while at Speckle the data you send can be of any shape/structure, we don’t really care what you’re sending.
This leads to key problem, which is that we cannot ensure that any commit is fully IFC compliant, and if it isn’t, then it’s not possible to convert it to IFC.
We do (and will continue to) allow for importing IFC files into Speckle, as converting a structured format like IFC is pretty simple to do.
I think it’s important to mention that, once your IFC files have been imported into Speckle, they are no longer in the IFC standard format, although they do contain the same data, it is no longer in the same structure:
Base objectsSorry to be the bearer of bad news! 
But our goal at Speckle isn’t really to align with the “Industry Standard”, rather to free you from it.
Hi Alan,
Thanks for reply. I see your points and agree all but to the last. I see IFC as an open industry standard, not something to be freed from, in some aspects the information and structure is important in IFC, in those cases one would of course need to export from native software, though you might be able to transfer information already contained in speckle, in other cases it is nice to just being able to combine geometry to IFC and i think it would be a nice extended feature of speckle.
But all in all, you are doing great job so not complaining, just input and needs
\Niels
@Niels your feedback is much appreciated! 
P.S.: Don’t take my personal stance on IFC as a company policy 
I hated IFC as a user, and when I tried to develop for it it got even worse 
I agree with Niels here.
IFC is only the vehicle of information. I work with a software that doesn’t have a speckle connector but they do export and import IFCs. This part of the collaboration is participating by providing their IFC which gets uploaded into speckle. But we never have a federated model to return to them, and they are forced to export all the native files as IFCs in order to return the other collaborators models into this software. Therefor removing the major benefits of using speckle to collaborate.
Allowing the user to export a federated model as many file types and possibly allowing the user to define mapping and structure of those files would open up many opportunities to use speckle in workflows where softwares don’t have a direct connection but still want to participate in the collaboration that speckle offers.
Thanks for taking the time to hear my 2 cents (they are in CAD so not worth a lot!)
Cheers
Hey All,
@AlanRynne so happy to hear you guys are not forcing to an impossible mission.
@Niels I agree, it is positioned as a standard, though in this mission to be a uniform standard, it has created so many exceptions and workgroups it is hard to keep track of the ‘standard’ itself. Even Native software hardly support it properly.
We can ask ourselves if it is worth the effort to make Speckle fall into place into existing workflows, or is it more interesting to centralize workflows around the new concept that Speckle brings.
Speckle format can always become the new standard
That being said: being able to export everything as BREP instead of the correct classes, is I think an easy compromise.
Cheers!
I agree the IFC “standard” can be hard to keep track of. I’m not personally the biggest fan of the format and how it is used in the industry, but I experience an increasing demand for the format, and also fall to use it in lack of better. As you mention alot of software doesn’t natively support IFC very well or in some cases not at all. So I think Speckle could provide a great hub here and fill a gap.
To your self asked question; I would say speckle could do both, but of course effort should match results and will not be judge of when it is worth it.
And as to whether speckle could become the new standard, it probably could, but I personally think IFC has some good things coming with IFC.js among other things, which there might not be reason to compete with?
But I must admit, I lack full overview of everything so I might be wrong
Cheers!
This summer Leo van Berlo invited me to give a small talk at the BuildingSmart technical gathering in Zurich, in which I detailed Speckle’s stance. We’re not adversaries here! The pdf is below, and it becomes interesting at around page 20 onwards.
https://drive.google.com/file/d/1sJUS8c5rABgCVNySG-ybQqqDHQwh9PFC/view?usp=sharing
The tl;dr:
- Speckle, at its core, is object model (or standard, or schema, however you want to call it) agnostic.
- You can use Speckle as a serialisation and transportation framework for IFC data.
- Speckle can write to any number of databases, disks or even a tape if you want it to.
For this to work though, and for us to be incentivised to migrate to IFC as a standard for the data we’re shuttling around, we would need (a) more developer friendliness and tooling, and, most importantly, (b) actually legitimate efforts by software vendors to properly implement IFC conversions, without intentionally using, or extending, obscure features that work only in one walled garden or another.
Without (b) specifically, IFC is nothing more than an archival format.