Wishlist for SketchUp 2018
-
Seeing SU 2017 is out this morning, here are my must haves for the next version:
-
Custom linetypes for SU. Such a huge missing element of graphic communication in this day and age.
-
Advance the Layer Manager for better control. Locking layers as well as manipulating layers to be viewed in one, many or all scenes...
-
-
+1 for advanced layer tools!
-
Dimension styles and functionality to match Layout's dimensions tool so that perspective dimensioning in SU could match LO style in every way, since we can't perspective dimension in LO
+100 for layer palette tools. Also for Scene and Material Palettes
Preference options for turning off/customizing inference engine. Create hierarchal list of inferences so one can customize which is given greater "strength" depending on use (for instance, I would make center of line most important/strong, and I would remove the axis origin entirely)
Preference to turn off the rotate functionality portion of the move tool
Eliminate or customizable clipping distance
Eliminate the crazy zoom when cursor is not hovering over geometry
Eliminate all the dotted lines and multiple vertex inference dots when trying to grab a part of a circle/cylinder. Utterly maddening and confusing when trying to set individual bolts in a large model.
Improve native 3D text to include edibility
Native section tool to provide cut faces like TIG's plugin. Also, allow for stepped section planes instead of just straight lines
Some sort of a click and modifier function that allows me to instantly edit a deeply nested component/group. Endless double clicking to drill down through 8 groups is a huge time waster.
That's just off the top of my head...
-
Yeah man, what's up with these material, scenes and layers palletes? We need those better. And we need everything else otb mentioned.
-
Shader for Mat Caps, AO, Soft Shadows and Reflectivity
Dock extension dialogs to Trays
Quad support
Disable inferencing
-
I forgot disable inferencing entirely; that would be highly helpful!
-
OK for the movement to quads and organic modeling improvements, but for SU to be what it was originally designed: a modeler of boxy buildings, it still needs faster performance on any old model that is over a few MB. This includes the ability to populate the model with furniture and plants for all purposes of design and presentation, without cringing at every addition. I can mostly work with what SU is, if it just doesn't slow up so easily.
-
Ok, once again, almost the same as for 2013, 2014, 2015, 2016 and 2017...
(faster load/save and 64bit has been removed with 2015)- import improvements
- Quads
- sub-D modeling (edit: since we now have SUbD and i don't think that Trimble will provide another version, my wish would be to make it possible to let it run faster (much faster) so that it is usable with bigger models. But maybe this is related to the general SU performance issues...)
- better texturing tools
- multicore support (yes, this is the way processors evolve now - since a few years)
- high poly support
- faster ruby script execution! (it's just a joke, that you have to watch a counter when you round some edges, where other apps can do this instantly...)
- faster explode or copy/paste
- disable/configure snapping
- an advanced camera without these unbelievable stupid huge frustums and guide lines (clipping problem?) or simply a camera with numerical input for the target height (or simply the same value as the eye level if a flexible value is too much
) - a usable, more direct or intuitive version of dynamic components with usable stretch and move options like in dynamic blocks in acad for instance (and including options to avoid texture stretching)
- better proxy display modes for referenced objects of external renderers - not only a box
- a camera that can use/display shift parameters of the camera in render plugins
- a function to replace a photo match image with a new one (photoshopped, colour adjusted, etc.) incl. the projected textures or derived materials. Maybe with the option to select if the projected textures/materials should be changed or not.
- an option to disable the rotate handles of components/groups.
and... since this is a wish list (i really don't think this will ever happen): non destructive and parametrical modeling using a modifier stack or node graphs. Maybe we'll see a ruby... this seems to be the only way this program will evolve in the future (as always).
...and a roadmap would be nice
-
- Dynamic Boolean Tools;
- Rotate, offset and mirror textures in material editor;
- Multiplanar sections and multiple active sections in the same context.
- Linetypes;
Not that urgent but very nice in order to use sketchup in a workflow with other apps: Expand Skp materials so we can have a standard way of storing extra textures inside a single material and we can use normal/bump maps, height maps, emittance, etc, across all different render engines and include them in exports like FBX, DAE, etc...
-
Perhaps Visual booleans to make any form work as sections?
-
@pixero said:
Perhaps Visual booleans to make any form work as sections?
The principle of sections is not geometric but related to the display of the model I think.
Although in the end, the result could be the same... they are independent from the rest of geometry.
But sections also have a button to turn them on and off, another to turn them visible or invisible and generate special section profiles.
Also there are a lot of plugins that act on Sections.
Hopefully Layout+Sketchup could integrate itself better on what regards to sections management and display on 2D output, section naming, section scene management and all sort of technical stuff that relates to sections for architects and other pros.
EDIT: But you're talking of visual booleans? Not Geometric Booleans right? What do you mean by that? The same thing you see on Vray 3?
-
He, I'm not sure what I meant. I just had the idea of having any object/form work as a boolean for the view like section boxes in Revit (or whatever they are called now).
-
I like that idea.
-
I like it too.
-
All are of course free and welcome to propose any features they would like. If you don't ask, you won't get! I just want to observe that some are things that have been extensively discussed before and explained why they are not feasible.
@numerobis said:
- multicore support (yes, this is the way processors evolve now - since a few years)
There have been many posts about this. No 3D geometry model editing program has cracked this nut in at least two decades. There are fundamental computer science reasons why it regarded as essentially impossible. So, don't hold your breath! In some ways this proposal is like the one a few years ago about the need for 64-bit support. They added it, and it turns out the pundits were right: the only real benefit was ability to use more memory for large models. It did not have a noticeable effect on the performance of SU.
@unknownuser said:
- faster ruby script execution! (it's just a joke, that you have to watch a counter when you round some edges, where other apps can do this instantly...)
There is nothing the SU team can do about the basic execution speed of Ruby. They do not develop the Ruby interpreter, they just embed it within SketchUp. Ruby is not designed as or advertised as a high-performance language.
I suppose there could be further optimizations in the SketchUp Ruby API (which is the gateway between Ruby code and underlying compiled SketchUp code). For example, new methods that hand off more bulk operations to the compiled library instead of using Ruby step-by-step logic. Other apps get their speed by having these operations done by compiled code, not by a scripting language such as Ruby.
Sophisticated programmers write the performance-critical parts of their extensions in compiled C/C++ code, which is much faster than Ruby. But they must still route their access to the SU model and library through the Ruby API bridge. They are compiled extensions to Ruby, not really compiled extension to SU itself. It isn't clear how much overhead that adds, but perhaps there could be a C/C++ API to bypass Ruby entirely (note: the existing SDK does not do so, it is for reading and writing SU files independent of the SU process).
-
Slbaumgartner, I maybe have a silly question. Would SketchUp work faster if it was connected or written with some other code, not Ruby? I have no idea what these codes are all about, how they work, what's used to write something, what translates what code... I'm not a programmer, so my understanding of code is very limited. But I do understand that you said some other codes are faster, so would it be possible, or reasonable to rewrite SketchUp using faster code? Maybe I'm just talking jibberish... Anyway, I'm quite happy with SU as it is, computation speed is not the most important thing to me, but faster is always nice. I'm more concerned about some organizational and visual stuff that I think can be improved easily and don't require such fundamental changes of software. And there are a bunch of bugs that really go on everyone's nerves. Those require more immediate attention in my opinion.
-
@slbaumgartner said:
No 3D geometry model editing program has cracked this nut in at least two decades. There are fundamental computer science reasons why it regarded as essentially impossible. So, don't hold your breath!
I'm fully aware that it wouldn't be possible for all operations (at least at the moment) But why not use it for tasks that can be multi-threaded, like background saving or file import/export, rendering, etc.?
Examples:
Revit https://knowledge.autodesk.com/support/revit-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Which-function-in-Revit-will-take-use-of-multiple-processors.html
ArchiCAD http://helpcenter.graphisoft.com/technotes/setup/software-technologies/multiprocessing-and-archicad/#Is_ArchiCAD_multi-threaded
Invertor https://knowledge.autodesk.com/support/inventor-products/troubleshooting/caas/sfdcarticles/sfdcarticles/Support-for-multi-core-processors.html
Some 3DSmax modifiers are already threaded (Bend, Skin, SkinWrap, Shell, PFlow, APEX Clothing, Delta Mush to Skin, etc.)
Not sure about Maya... i know that Maya API supports multi threading
cinema4d https://www.maxon.net/en/news/maxon-news/article/foundations-for-the-future/
Siemens NX (Parasolid) http://cadabout.ru/2016/10/28/a-few-words-about-siemens-nx-perfomance-cpu-graphic-adapter-memory-multi-core/
Grasshopper https://stevebaer.wordpress.com/2013/12/11/ghpython-node-in-code/If there are better ways to improve the performance single threaded - no problem.
@slbaumgartner said:
In some ways this proposal is like the one a few years ago about the need for 64-bit support. They added it, and it turns out the pundits were right: the only real benefit was ability to use more memory for large models. It did not have a noticeable effect on the performance of SU.
I never said that 64bit would improve performance. But i can say that i experienced many crashes hitting the memory limit. Trust me... i know why i voted for 64bit
@slbaumgartner said:
There is nothing the SU team can do about the basic execution speed of Ruby. They do not develop the Ruby interpreter, they just embed it within SketchUp. Ruby is not designed as or advertised as a high-performance language.
If that's really the case and they are already at the limit of what ruby is capable to deliver, then i think they should rethink their "strategy" of relying completely on ruby code for standard operations like rounding edges or processing SUbD models.
(Btw. as far as i know it's also possible to multi-thread Ruby code. I don't know about the SU implementation. https://www.tutorialspoint.com/ruby/ruby_multithreading.htm )@slbaumgartner said:
I suppose there could be further optimizations in the SketchUp Ruby API (which is the gateway between Ruby code and underlying compiled SketchUp code). For example, new methods that hand off more bulk operations to the compiled library instead of using Ruby step-by-step logic. Other apps get their speed by having these operations done by compiled code, not by a scripting language such as Ruby.
Sophisticated programmers write the performance-critical parts of their extensions in compiled C/C++ code, which is much faster than Ruby. But they must still route their access to the SU model and library through the Ruby API bridge. They are compiled extensions to Ruby, not really compiled extension to SU itself. It isn't clear how much overhead that adds, but perhaps there could be a C/C++ API to bypass Ruby entirely (note: the existing SDK does not do so, it is for reading and writing SU files independent of the SU process).
Like i said above, if it's not possible to speed up Ruby scripts, i think Trimble should do anything to either support the developers of these critical functions or implement them directly into the SU code.
-
For RoundCorner and SubD (and other plugins creating heavy geometry), the limitation is not due to Ruby but to the time needed by Sketchup to create the actual geometry in the model. It would be the same if you created it manually at the speed of Ruby.
Personally, this is why I use a Preview mode in some of my plugins (like Curviloft and TopoShaper), because the computation can be fast, and drawing in the viewport is also fast enough, versus creating the actual faces.
Fredo
-
@fredo6 said:
For RoundCorner and SubD (and other plugins creating heavy geometry), the limitation is not due to Ruby but to the time needed by Sketchup to create the actual geometry in the model. It would be the same if you created it manually at the speed of Ruby.
Interesting.
-
@kimi kimi said:
Slbaumgartner, I maybe have a silly question. Would SketchUp work faster if it was connected or written with some other code, not Ruby?.
The short answer is that SketchUp itself is not written in Ruby. It is written in high-performance languages called C and C++. The C or C++ code is processed in advance by a compiler program that outputs commands that directly instruct the computer's CPU. Pre-processing and talking directly to the CPU are what provide the high performance.
But SketchUp also provides an extension/plugin system by which users can add new capabilities atop the core of SketchUp. The extensions are what get written in Ruby. Ruby is a high-level scripting language. "High-level" means it provides programming features that make many complex operations easy to write, hiding all the detailed stuff needed to make them happen. "Scripting" means that the original Ruby code is read from a file and processed each time SketchUp runs; it is not preprocessed. As a result, Ruby code is in general much slower than compiled C or C++.
So, the long answer is that extensions would run faster if they could also be written in C or C++ (and some authors do write parts that way), but it is a much more technical and complicated way to go.
Advertisement