Correct me if I’m wrong, but I believe the api already enables you to create LayOut documents and LayOut entities from within SketchUp. So you could theoretically have a button that extracts all the floor plans, elevations, as well as all the dimensions into a new LayOut file. I can’t imagine the complexity of programming something like that, lol.
That is kind of the level of automation I am hoping to get to. Yes, its going to be fun to program.
This makes me think of when I bought a multi-tool and had the hard decision whether to take the one with 16 or 20 functions (more expensive). And now I still have to take both my new and my old multi-tool with me because 1-2 functions are missing and 90% overlapping.
The challenge for a developer is to draw a line between user requests (“It would benefit me if your tool could also do …”) and focus on the main task of the tool (and also what is feasible, maintainable).
Good tools have a narrow, well defined scope of what they do (strong cohesion), and do it well, and can easily be combined with other tools and workflows (simple interfaces of input/output). If tools are not too similar or overlapping, users can more easily distinguish them.
I wished the developer community could define a standard to interface between extensions. Because that is currently what requires (slow) manual user interaction (selecting input/previous output, clicking menus/buttons). If extensions could be connected like SketchUp core Ruby API methods, it would be so powerful. There was once a guy who started a visual node editor for applying parametrized, composited operations on a model. It is a too big effort for an individuum, and it only gets traction if the wealth of the extension ecosystem is also accessible for such an editor.
Other users of the Medeek plugins please share your opinions about my following comment:
Valuable features for/to me are code compliance integrated modeling (IRC or possibly https://codecheck.com/ instead), drafting standards LayOut tools (https://www.nationalcadstandard.org/ncs6/), and estimating process cost codes integration (https://www.masterformat.com/).
Most of my examples are US-specific, but I do want features that are also useful for those living outside the United States.
I agree that it would be very nice if all plugins or at least a majority of them could interact well with each other and even share data using a common protocol.
I have been contacting other developers in regards to having their window and door plugins interact with my wall plugin, with very little success.
The biggest problem I see is the lack of interest really and also the incentive. It takes a good bit of energy and time to debug and test plugins as it is, then you throw a third party plugin into the mix that you have no control over. Making sure that your plugin interacts with that plugin seamlessly is even more work.
I just think that no one wants to take the time to do this sort of tedious checking especially when the reward is questionable at best.
How is the process on the overarching vision?
Reading through John’s book right after Christmas I happened upon the section on electrical, mechanical and plumbing (chapter 15). This is what gave me the initial idea to add an electrical module to the Wall plugin, which of coursed has recently morphed into the Medeek Electrical extension.
I didn’t intend to spend too much time on it but two weeks later I now have the makings of another full blown extension.
One could just as easily download models from the warehouse and drop them into the model but a few flaws in this workflow quickly jumped out at me:
1.) Adjusting certain parameters such as height and vertical vs. horizontal mounting would be much easier if handled by a plugin.
2.) The plugin can automate the 2D symbol generation, again speeding up the workflow.
3.) All of the electrical components I was finding in the warehouse were too big (high poly). To model all electrical elements of a building and still have a manageable model the size of these components needed to be drastically reduced. Hence I spent some quality time putting together some low poly count models.
This new plugin, even though in its infancy, is actually quite well put together, even thought it is still lacking in certain features. It will form the basis for the next Medeek extension suite, mdkMEP.
Have you, by chance, contacted John Brock about collaboration, instead of reinventing the wheel for an estimating tool?
(Sorry, you may have already given me an answer about this.)
The estimating tool I am including in the Wall plugin will eventually be moved to a separated plugin within the mdkBIM package.
The Medeek Estimator is drastically different than either the Estimator by John Brock or Quantifier. Those two estimating extensions are general estimators and are designed to work with any geometry. My estimator will only work with Medeek geometry and more specifically with the Medeek extensions and their attribute libraries (databases).
These other more general estimators can be used with Medeek geometry however the information gleaned from them will probably not be as organized or specific as the information that one can obtain from the Medeek Estimator.
The Medeek Estimator plugin will be specific to mdkBIM, but the Medeek Electrical plugin is NOT specific to mdkBIM?
(The estimating feature is fairly easy to implement if assemblies are already parametric, right?)
Yes, the Medeek Estimator is specific only to the mdkBIM.
The mdkMEP suite is a completely separate suite of plugins and will work with or without the mdkBIM suite.
The estimating module primarily works with the information stored in the attribute libraries of the geometry created by the plugins. However it does use other methods and means that I won’t dive into in this thread , suffice it to say that it only works with Medeek geometry and that is the sole purpose of this estimator at least until I decide that I need to change it.
“Building Information Modeling is a big deal in the building industry and SketchUp is a big part of BIM! Take a listen as Aaron and Matt talk about the history and the current state of BIM before they invite Bill Allen from Evolve Lab into the studio to get an expert opinion on what is happening in the world of BIM!”
Assembly data to LayOut using Scrapbooks tray for symbols?
Where did you get this idea?
I was just quoting the description of the video.
I’ve been giving some thought to potential customers of the plugins and based on what I am seeing so far I think there is a definite pattern.
Most, if not all, of the plugin purchases are made by customers who are already SketchUp users versus new users who are converting to SketchUp because of the plugins.
For a designer/architect to convert to SketchUp (and the plugins) is a very difficult and big decision for them. It involves changing their entire workflow and possibly a major disruption in their revenue and output. I personally still have not fully made the switch from AutoCad to Layout.
For a designer who is already using SketchUp as their primary design tool it is a much smaller hurdle to incorporate the plugins into their existing SketchUp workflow. For many of these users the plugins offer an incremental increase in productivity and efficiency even if they are not fully parametric or still have certain limitations.
For a new user who is converting to SketchUp from some other software the bar is much higher and as a result the chances of a conversion is quite low in my opinion. Also these new users are looking for a turnkey solution and not a plugin ecosystem that is still in the process of development. Another hurdle is the fact that Layout is no where to the level that it needs to be for many designers (I just spoke to another designer in Canada who puts the majority of his dimensions directly on the model rather than trying to work inside of Layout). The Layout issues will impact the adoption of the plugins, there is no doubt about it.
That being said I think the people most likely to purchase the plugin suites will be current users of SketchUp who have already integrated SketchUp into their workflow and understand its limitations and advantages. They will accept the plugins even in their imperfect state simply because they already are substantial enough to increase a designers efficiency and save them considerable time.
Once the plugins are fully parametric, with the ability to handle complex roofs , complex foundations, gable/shed walls and a number of other improvements, then we might begin to see some people actually convert from other design software packages. I do not think that many will convert to SketchUp on account of a plugin suite that is still far from finished or should I say a “Diamond in the Rough”.
P.S. To be fair a complex project like the mdkBIM is never truly “finished”. What I mean by this is a product that can adequately handle 90% or more of what you throw at it. I guess what I am saying is that even though the plugins have progressed in leaps and bounds there is still much to be done. Unless I can somehow bring on additional programming help I am at least two to three more years away from what I would consider a mature product. If things keep on the up-and-up I will be recruiting individuals who are better at what I do than I am.
Optional automatic layers for assemblies (e.g. OB_WALL, OB_SUBFLOOR, OB_FOUNDATION, OB_ROOF)? Layer examples from Nick Sonder’s workflow. Also, Nick does location layers (LO_1ST, LO_2ND) for levels/stories of a house. I’ve tried using location layers only a few times.
(I have layered vector linework SectionCutFace as SP_LW 1ST & SP_LW 2ND. 2D and label layers in nested groups with location layers could replace my vector linework process.)
Ceilings can be creating with Truss assemblies, correct? But a subfloor assembly that is part of the second level/story will have a ceiling under it that is actually part of the first level/story. I believe that this is not a issue for a roof assembly because it would be included within the top most level/story.
(Ceiling module that creates ceiling group/component based on the Wall assemblies? Wall plugin recognizes closed loop of exterior walls?)
How to Generate Report after creating assemblies?
Oh my…it would still need to be based on the Truss assembly also, because of stairwells!!