I am starting this thread for the continued encouragement of Mr. Wilkerson in his creation and development of Medeek extensions. Feel free to post general ideas here. (Please post specific ideas about any individual extension to the appropriate thread.)
While I’m OK about encouraging @Medeek’s continued development, I’m starting to worry that he’s likely to work himself to death! Witness my just posted critique of his forthcoming Medeek Electrical plugin’s load center detail.
Don’t get me wrong - I love what he’s doing!
I think his vision of a coordinated series of extensions that interoperate to turn SketchUp into architectural modeling software with intrinsic BIM is a superb idea.
It’s my sincere hope that his economics in the sale of his extensions soon allow him to hire another programmer or two to share the load. Without that, I fear burn out.
We’re I not so set in my ways, with any experience in using Ruby at all (much less within SketchUp), and my general programming skills not so rusty, I’d be reaching out to him right now to see what I could do to assist him. With a particular emphasis on keeping his eye on the overview and starting to take on partners/employees to sweat the details.
Yes, I work hard but not any harder than anyone else out there.
Most of you wake up every morning and have to go to work somewhere, perhaps a long commute, possibly at a job that is tedious, dangerous or even boring. You may have to deal with a boss who makes your life tough, or a corporate culture that dictates too much of your life. Maybe your job requires you to travel and you can’t spend very much time with your family, I know how it is I’ve been there, done that.
I wake up every morning, and sit down in front of my computer which is exactly 25 feet from my bed and start crafting SketchUp plugins… my life is simple, what’s not to like?
Whose life is harder? I actually think I’ve got the easy end of the stick.
And to be perfectly honest, its hard to call it work when its so much fun.
My only complaint right now is I’m not making as much (financially) were I to pursue a more conventional career track, but I would argue that the extension ecosystem that is slowly unfolding is still in its infancy and the rewards will come in time.
Right now I am only laying the groundwork. As my efforts snowball I do hope to take on some additional help so I can further accelerate the development and the scope and magnitude of what I am doing.
Right now the biggest help for me would be technical feedback from industry experts and perhaps some skillfully constructed low poly models of certain electrical and framing hardware.
At the bottom of each plugin page I have created a sponsors section. At the top of that list is a section for Development Sponsors, if you are interested in becoming more involved and having a listing on each of these pages, please contact me and we will discuss this in more detail.
@Matt, my workflow is based on the book that you and Nick Sonder wrote together. I have been learning the Medeek plugins for a few months now and thinking about how best to integrate them into my workflow or change my workflow in order to best utilize the plugins.
The workflow from SketchUp & LayOut for Architecture can really be applied to anything. The big difference when using the Medeek plugins is that your level of detail has now increased quite a bit. But that’s ok because it’s all automated due to the plugins. You’re just going to have more layers and more scenes since you now also have structural in the model as well. So just take the same principles you learned in the book, and apply them to those additional objects in your model. Once you’ve developed something you like, you can save those scenes and layers as a template, to be used on future projects.
Does your SketchUp to LayOut book have more information about construction documents compared to the SketchUp & LayOut for Architecture book? If there is a good existing thread discussing this, please suggest it to me. Thank you!
(I feel that Sonder’s info about construction documents might be beyond what I need because I work for a construction company and not an architectural firm.)
I get this question a lot, and sometimes feel like maybe I should have chosen a different title for the book I wrote with Nick Sonder, in order to better differentiate it from my first book ,SketchUp to LayOut.
SketchUp to LayOut explores the relationship between your SketchUp model and the viewports that you create inside LayOut. It defines distinct steps for you to go through when creating each scene, in order to help you understand all of the degrees of control you have over the look of your model in LayOut. Although it assumes a basic knowledge of modeling in SketchUp, it covers a complete organizational workflow and set of standards that can be applied to any type of 3D modeling. It also gives you a complete overview of LayOut, and its various tools.
I should note that the book was written in 2015, and is still very much applicable, however is missing some of the new features. Section Cut Fill is a big feature that allows you to skip over many of the work-arounds you had to do in the past. Also, the Table tool in LayOut lets you create schedules more easily. I do have plans on updating the book this year, although no timeline yet.
SketchUp & LayOut for Architecture is more of a complete workflow for an entire architectural project, from site, schematic design, & construction documentation, while SketchUp to LayOut can be applied to any type of 3D modeling.
I’m not aware of any existing threads about my books, but I’d be happy to answer any questions anyone may have if you want to start a new thread.
So far the mdkBIM suite makes no effort to assist with the Layout side of things (ie. Construction Documents, Details, Drawings etc…) The primary concern has been to get a detailed and accurate model. However, at some point if the API allows it would be really nice to automate some of the tedious work associated with putting together construction documents. At this point I’m not really sure what can be done in this regard since I have not spent enough time really digging into it, but I have every intention of doing just that.
There are plugins like Skalp as well as manual workflows for extracting drawings from the 3D model. If this is integrated to the Medek toolset I’d recommend to think through how these tools work together and if some functionality is duplicated among different extensions that at the same time partly overlaps. Partly overlapping tools can increase the complexity and cognitive load quite drastically. It’s nicer to have a knife, a fork and a spoon, than a spork, a spife and a knork.
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 (United States National CAD Standard - V6), 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?)