Can Sketchup keep up?

Everyone has their own work flow. In my case I have my building plans, mechanicals, materials, furniture, etc. all in the same plan. I have scenes set up for my basic views (plan view, elevations, basement, 1st floor, 2nd floor, mechanicals, etc.), but then use tags to control visibility of various components within each of those scenes such as different circuits, HVAC zoning, furnishings, etc. Sure, you can use scenes, you can use grouping…whatever. I find scenes and groups a little more cumbersome than tags. For me, I prefer using scenes for the macro views, but like the simple menu structure of tags (despite it’s limitations) as a quick way to toggle the visibility of various details.

The ability to save a bunch of different tag views seems more intuitive to me when you have a lot of views compared to doing it all with scenes or groups. Perhaps it’s because it’s more analogous to the way I work in audio mixing where we have scenes as well as solo and mute groups. There’s overlap in that functionality, but it’s very flexible. Since I’ve been engineering film audio much longer than than I’ve been using SU, I guess my brain gravitates towards organizational structures that are similar. To extend the audio analogy further, there are discussions like this in audio engineering forums and the better audio programs offer multiple ways to accomplish the same thing in order to accomodate a broader number of applications and working preferences. So just because their’s already a way to do something doesn’t mean the developer should stop there. That said, this is not the particular hill I wish to die on today!

Scenes, tags, groups, components all work together. Having a tag heirarchy would absolutely help you with what you are trying to achieve.

Scenes are established mainly for LO, but you could set up working scenes that have tagging preset so your not redoing that task every time you start a new project.

This is actually the focus of what I am presenting at Basecamp so one can streamline that process and spend more time designing.

2 Likes

Hei Odd Haakon! Lenge siden sist!! :wave:

Do you mean the materials list when you refer to “colors”?

I’m happy that you find my extensions useful. And I agree that some extension functionality makes sense to have built into SketchUp when it lends it self to a generic workflow, like with Weld. Selection Toys, at least parts of it would also make sense to me.

But for things like SUbD, I’m not convinced this is generic enough. I certainly don’t share the notion that these are “All easy functions to integrate”. That’s making a lot of assumptions on the complexity of the code.

With things like Weld, and some basic selection filtering then porting them to native tools is rather straight forward. And features that are likely to remain as-is once released. But SUbD for instance is much more complex, and something likely to evolve. To take any extension and build into SketchUp means it’ll take up development time in creation and maintenance. It’ll also lock it to the SketchUp release schedule.

Beyond integrating basic generic functions that into native functions, what I would find interesting is hearing what people expect in terms in value gain from having any given extension made into a native feature. (I’ve seen some reasons expressed here, but I’d love to hear more.)

2 Likes

I agree with you that many “easy” extensions are not “easy” at all - not easy to program and not easy to use - it’s just that we power users know them by watching YouTube videos etc. :slight_smile:

I do a lot of training of “newbies” in our company - people that have never used Sketchup and I need to get them up to speed quickly so that they can collaborate with my power users. I always notice that there are certain things that are REALLY hard to explain on how to do with just the native tools. Or - let me phrase it differently. If you are used to Fredos “Stretch to Target” (as just one example) - and then you sit in front of an install without it, and a newbie asks you how to make this cabinet longer - and you start to explain: “Well you open this group and then you use push pull and then you close the group and than you open the next group and you use push pull and then you close the group and than - well - you repeat that 20 times…” it feels - off… It feels like there is a “more powerful native way” missing.

So for me extending “native Sketchup” boils down to:

  1. Preinstalled functions workflows that would be very repetitive but still are still in itself basic tasks
  2. “Fix ■■■■” type functions that everybody that uses Sketchup for a while ends up finding anyway (like Cleanup3, MakeFaces, etc.)
  3. Equal workflows across all App-Types (Pro, Web, iPad) for type 1) & 2) tasks

Other than that - I LOVE extensions and yes - it’s nice to make Sketchup the tool YOU need. :slight_smile:

Hey bifterx,
I’m intrigued by your statement … can you say more, or forward a link or reference? I’d like to understand more about this!
Thanks!

That’s a critical issue now. Back when SketchUp only ran on two OS’s of full computers, and all versions supported extensions, you could afford to be conservative about letting all kinds of things be extensions, but first with the web based versions that don’t support extensions, and now the iPad version which can’t support extensions, you have to be more aggressive about what’s included in the base app that’s there across all versions and platforms.

I would put Solar North as #1. I’ve been dumbfounded for years why that was ever an extension to begin with. Selection Toys would be #2. In another thread, we just tossed around some ways with native tools on iPad to select only edges or select only faces, but they are certainly workarounds.

I think I’ve relied on Takata’s Stretch by Area to achieve the same thing, but I consider such a tool to be #3. This is the equivalent to the Move Points tool in Wild Tools for PowerCADD, which is one of the top 6 or so tools I use from there. That was a plugin that proved so valuable that the developers eventually created their own native equivalent tool. (hint, hint) I suspect this isn’t on SU Team’s radar as mission critical, basic functionality, but I want to ad my voice to wanting it included in some form.

Yes AK-SAM,
To really achieve “a professional AEC program with … robust and efficient workflows”, Trimble simply has to take your item #2 more seriously!

Hey napperkt,
I like you bullet list, but would shorten it as follows:

1 Like

It’s great to hear you say this Nick! Given your excellent demonstrations of how much Layout CAN do, maybe Trimble will listen to YOU!

2 Likes

I have this as my base template setup… works really well, except when it doesn’t, or I throw a curve ball at it.

For me, in LO being able to manage the ‘viewport’ similar to how we manage scenes from the Scenes pallet in SKP would be great - right now if I am developing a page, and I make some individual settings to Tags (lines, dashes, etc.) and want to transfer these to another page - I usually create a mess… and need to just go back and manually update the dashes / etc.

Being able to control viewport properties like how I can quickly blast through scenes and uncheck / re-check camera, tags, hidden objects, style, etc. - but for line weights, dashes, scale, etc… that would be great.

2 Likes

Good comment, and it looks as if a rather terse reply may have deterred you from expanding on what you were trying to say… I for one would be interested to hear more on what you mean about SU as a BIM platform or tool :slight_smile:

Great video, and a lively debate. No one who’s read any of my comments over the past few years will be surprised when I come back to just two main areas where there is not only room for improvement, but those improvements will become deal breakers for many of us who use SU for architecture…
1 - Layout - really gals & guys, this is SOOO cumbersome that it makes us want to cry some days, and after reading this thread we are many who feel this way.
2 - BIM - when oh when are Trimble going to make it possible to add more detail to classifying objects and have that information export with the .ifc files that one can only currently export convincingly via a 3rd part plugin (IfcManager) (even this great extension has bugs, as I discovered recently, if you have anything classed as ifcRoof or ifcCovering the export fails)…
Moving forward, it will become essential to be able to have enriched data on objects that remains readable when an ifc file is exported. Oh, & has anyone written an extension to easily generate ifcSpace objects ?
Anyway, I hope these are on the To Do list at Trimble, but we will never know until/unless they “appear” in a future iteration of the product, as the corporate secrecy is so extreme that we humble users are kept totally in the dark and guessing…
Hého, meantime we soldier on with what we’ve got, doing all kinds of work arounds in order to keep up with the changing demands of our industry whilst avoiding Revit or whatever, but for how long will that be a viable option ?
All the best to all…

1 Like

Yes. imprecise language… :slight_smile:

Nice to see a big discussion on this. Great thread!

2 Likes

A very interesting debate and a lots of opinions and differences of opinions on the direction SketchUp should take. It will be interesting to see what SketchUp and Trimble do in the next five years and for me a bit nerve wracking.

Couldn’t agree more.

1 Like

Some of us need proper dwg export desperately.
However:

THERE IS ONE WAY to make a quite proper dwg from a sketchup model. It does not involve Layout, as that will not produce precise geometry. The engineers report that the distance between your reference lines are 5999,999 meters instead of the 6 exact meters when exporting from Layout. Engineers hate that, so dont use Layout for CAD export. You will also hate to get geometry back from engineers with those errors embedded.

The method is like this:

1.In sketchup you set up a scene for each tag or group of tags you want to make a dwg layer from. Each scene needs to share a common reference point ( some geometry that defines the insertion point) . Each scene needs to be zoomed to the exact same location of the model, so best keep some reference geometry around the whole model so that zoom extent will bring the same scope to each scene. The export will otherwise whimsically change position according to the panning/zooming state of your scene, like it does in your Layout viewports for no reason.

  1. Geometry needs to have line colour like the colour you want it to use in the dwg, so use colour by tag, and set the tag colour to your desired dwg layer colour. A “hidden line” Style will then give scenes with coloured linework and nothing else in the scene. That makes it easy to see the resulting linework before export.

  2. You then export each scene individually.

  3. You insert x-refs of each exported dwg into your “master dwg”, and place them on top of each other with the help of their reference point. The imports will not have the dreaded broken lines from every other crossing geometry on other layers.

  4. Before sending away your dwg, use "save as, in your “dwg app”, like autocad, and “Bind” your x-refs in the file you send out, so they are embedded in the export file.

THAT WAY your “master dwg file” can be updated with new exports from your sketchup scenes, while the other file, the copy you send away has the x-refs embedded.

You have now made a manual/ semi-half-automatic dwg machine , and if you standarize your tag naming and have a sketchup template with readymade scenes for those exports, you will not use most of your awake time trying to export things out of sketchup anymore.

Your life might have some small meaning afterall .

Of course, a PRO modeling platform should not engage in whimsical standoffs with 3D amateur potato design freeware like Blender, but rather make efficient tools for its paying customers, so they dont use half the time on things that should be automatic.

Sketchup is our chosen design platform from our love of it, and we will just have to live with the fact that an algorithm that could process exports automatically is no priority , although proper dwg export should from its programmatical nature be really easy to do.

How to do it : The export Flattens each group/component individually and place the result in a dwg block on a layer according to the tag it came from. Name the group like the sketchup group/component. Make a polyline from the connected section cut edges. Keep that origin. Make index colors from similar colors). Sounds like no rocket science .

But its not gonna happen, and we know that those who dont need this is very vocal on insisting that nobody else needs CAD exchange features. So thats my little rant…

6 Likes

You are so right about this aspect of the SU/LO package… there should be a way of doing what you describe without all the palava !
But since it’s not the case, we have resigned ourselves to exporting the SU version of dwg and a little script in Bricscad changes the colors for the two layers that SU deigns to export, so basically you get cut, or viewed geometry and basta… Tant-pis, we give those files to the folks that need them, and they have to like it or lump it ! My angle is now to teach the engineers & contractors around us to be able to open up our ifc files in eveBIM viewer and “read” the information that they’re looking for there.
As for all the contractual 2d stuff, (planning permission for exemple) we painfully creak and try not to go back to smoking, using LO. Our “swaring jar” gets fuller by the day !