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!”
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?)
I’ve been working on the Layout problem now for a few days (kind of off to the side when I’m not on something of more immediate importance).
The first step to automatically creating construction documents from the model is the scenes.
I will be creating a new toolbar within the Wall plugin that will be called Medeek Documents. This will be the start of the Scenes/Layout piece of the mdkBIM package. Eventually I will pull this out of the Wall plugin since it will be similar to the Medeek Estimator in that it will eventually work with roofs, floors and foundations.
I would say that:
Aesthetic detail (form) is important for marketing purposes and schematic documents/drawings.
Construction detail (function) is important for permitting and construction documents/drawings.
I am wondering about mdkBIM suite’s (including Medeek Documents) compatibility with Skalp? Or, is there an intent to have Medeek Documents to do similar things as Skalp does?
I haven’t gotten to the floor plan (module) yet but if it needs to do things that Skalp does then I’ll make it happen. It’s really too early to say yet.
I’m hoping for the U-shaped configuration without a workaround someday. But, mostly I’m asking about the gap in the steps. I’m pretty sure I could create a similar look using Profile Builder. However, I wanted to check with you first.
Sorry for not being more specific to start out with.
