Multiprocessing for 3D applications has somehow been “round the corner” for about as long as the first dual-Pentium workstations were released (it must be 20 years ago already). I recently talked with a workstation hardware vendor and he almost went ROFL when he found out that I haven’t given up hope yet.
One more thought on this topic. Why doesn’t Trimble post a list of the things they are at least considering and let users vote on / prioritize. The list would not have to include enhancements that they are already resolved to do. Just get some user feedback on their priorities with the understanding that there are no commitments. Just let them know/see that you are listening.
When I vote +1 or -1, it is NOT whether TO or NOT TO implement a feature. I am simply placing MY chip on one side of the priority balance,… either incrementing or decrementing the priority tally, for a feature on the “to-do-or-not-to-do” list.
When Google owned SketchUp, they had a webportal for doing this kind of thing, that was basically meaningless.
It allowed users to post Feature Requests, and others to then “Like” or “Dislike” them. A logged in user could see those they had “liked” and “disliked”, etc.That was about it.
The result was totally emotional and subjective. It told the development team / management nothing helpful about what the NEED nor USAGE of the proposed features actually was. Just whether it was loved or hated.
How could anyone possibly make any informed decision from such “nebulous” results.
And once again, it looks like this kind of thing is being proposed.
I once wasted a bunch of my time explaining (several pages) how the system could be made objective and proper questions asked to the userbase to collect real useful data about proposed features, (such as how often the user would use a proposed feature.) “Wasted” because the entire report was erased along with the whole forum. (Unless someone manually cut & copied it from the website.)
But I’ve always “liked” the idea of a public FeaturZilla system where the FRs were logged, discussed, closed when implemented, voted on, etc. (Yeah, pun intended.)
Dan, I can appreciate what you are saying. Before I retired, I was a Business Analyst/Product Manager at a software company. One of my responsibilities was to work with customers and find out what kind of features they wanted/needed and then put together a product plan. At times, it surely is a thankful task and no matter what decisions you make there will always be people/users/customers who disagree with you (no matter what system you use). Since our software was limited to a given industry, it was a little easier to get/handle the requests.
I have been using SketchUp for a little over 2 years now. Long enough to go through 2 update cycles. I honestly have to say that I was little disappointed both times. I did not see that much of an update to justify the cost of upgrading but we did it anyway.
BTW: On this forum site, I still have not seen how to quote others. In particular to cut out just the part that I want to reply to instead of the entire quote. What am I missing?
My real reaction though is that I am pleased that this thread was initiated by someone at Trimble and there seems to be an honest request for feedback and some way to help them sort through and prioritize customer feedback and requests. IMHO, this is really a good thing. While I consider myself a newbie and novice, I would like to help/contribute in moving forward.
This past (2016) cycle was a very “special” cycle:
The major visible change (feature) was the introductory implementation of the Microsoft tray system for inspector dialogs. (LayOut was introduced with it. But it has been a long time in coming for SketchUp, where the floating “snappy” toolwindows never worked at 100%. They’d eventually lose track of their stack origin, and get shuffled in their stacking order, despite repeated attempts in each cycle to fix the bug.) But the a lot of the work was “under the hood” and “behind the scenes”.
A major overhaul of the API observer sub-system for stability.
Major implementations and additons within the ongoing C API project.
The initial release of the LayOut C API.
Introduction of Ruby extension encryption v2.
Part 1 of High DPI display support, ie, toolbar icons and cursors. (Coming in Part 2 should be drawing area support for tool drawing, inference dots and and tooltips.)
Major overhaul of the inferencing engine and how the native toolset works with it.
Likewise, the previous (2015) cycle also had a lot of “engine” work done:
The introductory release of 64-bit editions for MS Windows platforms.
This is the most important (and profound) thing that has been said here on the forums, regarding SketchUp development and maintenance, in a long time.
It is definately very informative to the public, in understanding the Trimble in-house development philosophy for maintaining SketchUp.
(IMO, it should be quoted or pasted into this forum’s header “intro” post.)
It again reminds me of a “promise” made by Tyler Miller, Engineering Director at SketchUp, (some years and cycles ago,) that they would try their best in Boulder to avoid the traps of “feature creep” with the SketchUp application.
Everyone (who posts a feature request) should first be made to read the following wikipedia article:
Yes, Dan you are correct. Sometimes we do not really get to see/appreciate all that goes on behind the scenes. My real preference would be for them to continue working on the engine to improve performance. There are tons of external tools to do most everything.
It might be that English is not my native language, but the the post that Tommy opens this thread with reads to me as a warning that we cannot expect the coming releases of SketchUp to bring about any essentially new features but only minor bug fixes. Has SketchUp passed the apex of its development path? Is it on the decline?
But the goal of the simple basic core pre-dated the Pro editions. I think it is more a warning to the host of requests to add non-core features to the Make editions.
Look through this forum and you’ll see requests by Free/Make users to add Pro features into Make (like SolidTools.). When prompted they admit that no, they do not want to pay for them.
So a main point in Tommy’s OP is that many requests must be implemented as extensions, rather than core features. What ratio? The wiki on feature creep mentions a “80/20 rule” (core/extension.) But I think we’ve reached the point that those numbers are reversed. Ie, 80% of SketchUp feature requests should be satisfied by extensions (or external utilities.) Perhaps only 20% can be seriously considered for core feature implementation.
to me the strength of a spreadsheet program is the ability to customise it to ones specific needs. So the VBA ide in excel with the use of user forms provides a safe and fairly easy way of creating solutions. As such within a period of five years I was able to compile a AutoCad / Excel solution to do layouts and takeoffs which enabled be to do accurate projects in a shorter time. (that was 10 years ago, and I am using the same with little change, howbeit 2D)
This feature is what ruby is for Sketchup? but where are the inbuilt forms, programing interface? it seems the same as its always been, a ruby console and a very limited userform. Then we are directed towards java script…
I believe if there is need to offset the “features” to extensions then make that environment as easy to use as sketchup itself with some Macro features, userforms…coding ide.
I would like to do my work in 3D using Sketchup and Layout
I also vote for a native section tool extended to solid-group.
As to keep it simple, it should render solid-sections only on solid-groups.
No need to implement additionnal contextual window for the optional material render style of the solid group, just use the same paramaters as cut-edge color, in style option. The advanced options to choose special material on sections are naturally an extension…
One other request : it could be really cool to enable easy partial section (only one side of a symetry axis for example), broken section (X parallels planes), and pie section by :
Right click on a section plane, to acces to context menu option “divide section plane”
Select, then move one side to make a broken section
2b) Select, then rotate one side to make a pie section
2c) Select, then delete one side to make a partial section…
In fact I am often making big buildings model, with lot of groups.
It appears that making a pie section within a big construction tree is really awfull.
If I want a clean and flexible result, I do multiple copy of the groups and various section cuts within… And if I want it quick, I use Zorro, erase, and then cleanup, but it’s still dirty work and destructive modeling…