I largely agree with Justin’s point, but I wish we had more quantitative data to back up the anecdotal evidence we frequently hear. Our conversations with Architects and Designers often confirm their use of tools like Rhino Grasshopper and D5.
This brings up a comparison to my engineering school experience in the early 2000s, where Solidworks and AutoCAD made fillets and chamfers — which are critical for stress reduction (i.e., eliminating sharp points) — a fundamental requirement, even offering tools for variable radii.
I wonder if SketchUp’s nature as a surface modeler restricts the focus on such functions. Features similar to SolidTools and Boolean operations are standard in most other CAD design software.
Finally, a note on our offerings: beyond K-12, we already provide the more functional SketchUp Studio version to universities (Higher Education)
I’m not sure what problem that particular tool is meant to solve. I did get some comments that people were excited to use it, so there’s a niche that’s using it.
Unfortunately this is really hard to get, and would require internal data both from SketchUp and from McNeel. That said, the fact that that video did over 100k views and over 1700 comments in a week does indicate it struck a nerve for a significant number of people (in my opinion)
I largely agree that one of the problems is the underinvestment in developing improvements to the creation and modification features.
You mentioned fillets and chamfers; we could also talk about stretching multiple components.
To stretch several components simultaneously in SketchUp, you need to use plugins like the one Justin showed in this video. In my opinion, this kind of basic operation shouldn’t require a plugin, especially since the one shown in this video is paid and, according to its description, compatibility only goes up to version 2024.
That’s also the risk with plugins: that one day development will stop, and then it can drastically change how users work.
This is what I’m afraid of. I was thinking about this yesterday - if the soap skin and bubble tool stops working, it will significantly affect landscape/earthwork workflows in SketchUp…massively!
And that’s just one tool - there are multiple older tools that are used daily by a large number of SketchUp users that could just…stop working next time a new release rolls out. I’m less worried about the paid extensions, as those developers are incentivized to keep updating, but there’s a large part of the SketchUp userbase that relies on plugin developers updating their tools “if they feel like it,” which is not a great feeling.
For your first comment, it would be really nice to have some kind of vertex editing toolset built in. There are situations where I need to pick up the ends of lines and extend them without having a face, and currently that really isn’t an option (I mean you can use the scale tool, but that only works in certain situations).
I like how Blender gives you the option to toggle between vertex, edge, and face modeling - it’s nice to be able to toggle between those modes if needed
3dm file format . Yes well looking at product modelling and 3d printing in a sketchupish interface but with Nurbs instead, just like Rhino is Moi3D for accurate modeling for designers and artists. The developer of Moi3D has a relationship with 3dm and i like the modelling engine myself. Obviously Rhino is much more powerful and GrassH and Rhino shares the same file format as Moi3D! That tells you something. Are you aware of it?
I have read the first half of this thread and watched Justin’s excellent video.
In terms of the “pipeline” Justin refers to, what Trimble decides to do commercially seems to me to be of small moment, unless you feel a need to be a proponent of a particular piece of software. I guess it does affect the rest of us tangentially inasmuch as SU’s commercial success must feed into the funds available to keep improving it.
As far as features are concerned, a large part of the problem is the wide variety of different user types that exist. We all have our own pet bugbears, things that we wish SU did or did better. But my list would likely be very different from anyone else’s.
From my POV, what I have seen over the past 25 years or so has been some rocket fuelled improvements in the early years but a rather scattergun approach to development in more recent times. We get Stop Press developments like Dynamic Components, and more latterly Live Components, that that keep the word of promise to our ear and break it to our hope.
I agree with Justin that some basic improvements to functionality (he refers ro chamfering etc) could be built in. I would have thought that SU developers would be looking at the best extension writers out there, selecting what they deem to be their most widely useful ones, and then paying the developer to build their algorithms into SU. I accept that it is a difficult balancing act to keep the base software clean and tidy and not become weighed down with all sorts of features only few would use. But you could argue that some of that has already happened, perhaps.
