"Project Spark is a technology preview of a simplified 3D building information modeling (BIM) solution. Using Project Spark, building professionals can create designs efficiently with real world building objects, produce more reliable documentation faster, and share files with consultants using Revit or AutoCAD based products."
Naturally, I downloaded it and spent a couple of days fiddling with it. Unfortunately, I was largely disappointed with the implementation of the idea. Spark is really a pared down version of Revit. While I appreciate the idea, taking Revit and removing some core functionality isn't a way to make a "simplified" 3D BIM solution. It is a way to make a less functional BIM solution. But, the devil is in the details. So, what exactly did get removed?
That's the short list. I've got my analysis of each item below if you're interested, but the core problem I see is that the foundation of the project seems to be summed up by this equation: Revit - Features = Simplified, and Simplified = Better. The math geek in me doth protest. The problem with Revit generally isn't that it has too many features, it is that the features it has are too hard to learn and use consistently. If Autodesk really wants Spark to succeed they need to look at this differently: Revit - Inconsistency + Ease of Use + Ease of Training = Better. That's the key to making Spark really catch fire. Also, I question what success is in this context. Creating a new software offering or providing a tested to make the Revit platform easier to use? Either way it is an interesting concept, although I certainly prefer the latter from an end user perspective.
- No Worksharing – Makes perfect sense. I get removing this for a “simple” program and this does actually simplify things a bit. It works like sketchup, FormZ, Bonsai, Rhino, Etc...
- No Photorealistic Rendering – I wouldn't call the rendering in Revit “complicated” by any means, so it seems odd this was removed. Rendering is a basic function of most competing “simple” BIM tools as well. Since all the rendering related information is still in the materials dialog to support textured viewing, I really don't see the payoff.
- No View Filters – This is an overly complicated part of Revit, so I get removing it as is. However, the functionality represented in filters is absolutely necessary to get decent visual graphics out of Revit in an efficient manner. So, I really think the Labs team should spend some time “innovating” how that core functionality of selection sets and visual overrides are accomplished in a BIM environment. This would have a huge positive impact flowing back into Revit as well.
- No Groups – What? Again, grouping is a core “feature” for modeling in almost any application. Sketchup has a corollary, FormZ and Bonsai have a corollary, Rhino has a corollary. They aren't that hard to use outside of having to enter the group edit mode. Again, this is an area that feels necessary and just needs a little tweaking to be simplified and still available.
- No In-Place Families – who do I have to pay off to get this removed from Revit as well? Hehe. Happy to see this gone, we just need to be able to edit family content with the project context in the background. That's the only real benefit to In-Place Families.
- No Massing – I sort of get this, and sort of don’t. Massing can be complex, and this isn't targeted as a conceptual design tool since that's Vasari’s realm. However, it leaves Spark without the ability to create so many basic forms that are just necessary in today’s design/construction environment. Opportunity wise, this is another area where innovations in Spark to support "complex" forms like slanted walls without needing massing would benefit the core platform.
- No Analysis – I can see this as extraneous to those I see as the targeted end users of Spark, plus the analysis features are generally more easy to use than a lot of the core features are thanks to Vasari so they need less attention to make simpler.
- No Trusses – Personally I think trusses are the most important structural element to have in any design or production software as they are the element least likely to be hidden behind ceilings and most likely to be incorporated into the design direction. However, the truss tool in Revit needs some work to make it more usable and is quite complicated at the moment so the factory is probably better off removing it. Long term, this would be a good thing to simplify and include.
- No Shared Coordinates – I get that shared coordinates are complicated. However, by removing this Spark models are basically UNUSABLE in any downstream process. I want you to know that because I think it is an inexcusable omission. This is one place where the Revit platform could really use some UX level thought in making multiple coordinate systems less confusing to the average user. It is an absolutely necessary evil to be able to define multiple coordinate systems so you guys ought to be Labbing it up in my book.
- No Point Clouds – What? Why? Ok, it makes sense. But I love me some point clouds…
- No Sunpath – Makes some sense along with the analysis, although this is arguably one of the easiest things to use in the whole platform.
- No API - I don’t really understand the benefit to removing this other than it probably makes it simpler for the factory to work with. Unfortunately, it prevents us from using plugins that might make Spark even simpler than it already is..
- No Parts / Assemblies – I kind of get this one, although as the confusion about parts/assemblies/groups/etc… gets worked out in the main platform I would expect to see either assemblies or groups in something like Spark.
- No Design Options – Removing one of the most complicated and difficult features in the platform makes a lot of sense. With worksharing removed so it makes sense to run multiple sequential files from a workflow perspective anyway. However, I’d really like to see the factory take a look at this and make Design Options much much better long term. Spark may not be the project for it, perhaps Vasari is a better home for that project. One of those two projects ought to take a close look at the intent of DO and actually deliver upon it one of these days…
- No Adaptive Components - This makes sense in the light of massing and general conceptual design features being removed across the board, although as more of the main platform transitions to adaptive components as core content and not just design-centric content I might begin to question this decision sooner than later. AC’s are arguably simpler to build and more flexible content wise.
- Simplified Export – Makes sense in general, although again the no API thing means no exporting to things like NWC, and leaving IFC out is just inexcusable all over again. The implementation here once again really limits the use of anything created in Spark downstream.
- Simplified Links – I shockingly have no issues with this, though perhaps the factory didn't go far enough. I mean, what is that CAD stuff for? That's SO 1990's.
- Simplified Content – I'm not entirely sure what this references. I haven’t noticed a substantive difference yet outside of less categories being available. I’d love to know more if there are some changes I just haven’t noticed yet. I don't think removing categories should count as making the process of creating content "simplified", so I hope that something else is there.
- Simplified Phasing – Again, I didn't notice anything on the surface that was in any way simpler. Phasing is already pretty simple as is. Again, I think phasing could use a UX eye to make better, but it isn’t a high priority compared to some other features.
- Simplified Materials – Not really much simpler actually, it’s still pretty complex and since textured display is still supported the whole rendering backend which makes the materials dialog so complicated is still basically there. So, I question this being “simpler” outside of a missing tab and button or two that are outside of the core materials workflow anyway. There is a lot of opportunity here to make the materials dialog more like selecting a material in a material library in real life.
Revit Modeling
ReplyDelete