Wishlist for SketchUp 2018
-
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.
-
@numerobis said:
@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.
Some of the things you list can and probably are passed to separate threads, whether explicitly by SketchUp or by the operating system. For example, file writes are usually buffered by the system and actually occur after the application's request returns control. So long as the model is frozen, multiple threads could be used for rendering. But some things have to wait. For example you can't save a model while it is in the midst of being updated! And, in SketchUp's case, nobody has figured out a way to use multiple threads to capture model geometry in a database simultaneously while presenting it to the user for editing.
@unknownuser said:
@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.
This is a misunderstanding (see also my other post). Only SketchUp extensions/plugins are written in Ruby. The core of the program is in C and/or C++. At this point in time, rounding edges and processing SubD models are not built into the core of SketchUp, they are extensions. The philosophy of SketchUp has always been to keep the core relatively simple so that the program doesn't become a bloated behemoth, and to allow specialized features to be added via extensions so that users can pick and choose which ones they really need. A friend of mine used to use the quip "I wanted a banana and they made me take a gorilla, a cage, and a zoo with it".
@unknownuser said:
(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)
To repeat, the SketchUp team does not develop or implement Ruby, they just embed the interpreter into SketchUp. Historically, Ruby has simulated threads rather than truly supporting them. The current versions use true operating-system threads to implement it, but layer their own scheduler atop it because too much of the standard Ruby library is itself not thread-safe. The result is that Ruby blocks the main SketchUp thread, even if the Ruby program itself is written to run in multiple threads. But even if the extension could truly run multiple threads, it would be restricted in what it could do because the core of SketchUp itself is not multi-thread for all the reasons above.
-
Thanks for these clarifications slbaumgartner. I think most people here are architects and designers, so we don't really have a full understanding of things that can or can not be improved in our favorite program. It would be nice if SketchUp could get better integration with other software that's more capable of doing stuff this program can't do. For example, animation, subdivision modeling, texturing, high poly assets, those are the things that SketchUp can't and probably will never do as good as some other software. But we, as architects and designers, get a lot of requests to do walkthroughs, animations, to model some chair for the interior and that sort of stuff. There are ways to import/export these models into and out of SketchUp, but that's so hard in most cases. So, it would be great if you could simplify and speed up connections with other software. And maybe you can also consider making a 3rd, 4th, 5th app, next to SU and LayOut which would maybe specialize in those areas. Same as you did with LayOut integration. Something that would just read skp file and work it's own thing in a completely different window. Or something where SketchUp itself could use other files as references without actually bringing them into the model. And then sell those separately if you want. I don't care if I have to pay extra, but we need some more tools to do all the stuff that clients ask us to do. We just need a familiar interface and a logical way to organize and connect it all.
-
Yeah, one more thing I always forget to ask about. Could you guys filter the content of 3dwarehouse? I respect everyone's effort, but to be honest, some people just suck at modeling and post things that choke the warehouse. There are quality filters on websites that sell stock photos, stock 3D, graphics, games etc. So, I think we really need one or two guys out there just filtering all the stuff that's uploaded. And a better search and rating for 3dwarehouse. And perhaps a PREMIUM section, where stuff wouldn't be free. There are sites that sell, like this one, but I still think 3dwarehouse would be the best place to sell our stuff. Hope you'll consider this.
-
@slbaumgartner said:
This is a misunderstanding (see also my other post). Only SketchUp extensions/plugins are written in Ruby. The core of the program is in C and/or C++. At this point in time, rounding edges and processing SubD models are not built into the core of SketchUp, they are extensions. The philosophy of SketchUp has always been to keep the core relatively simple so that the program doesn't become a bloated behemoth, and to allow specialized features to be added via extensions so that users can pick and choose which ones they really need.
@unknownuser said:
To repeat, the SketchUp team does not develop or implement Ruby, they just embed the interpreter into SketchUp.
@slbaumgartner said:
Some of the things you list can and probably are passed to separate threads, whether explicitly by SketchUp or by the operating system. For example, file writes are usually buffered by the system and actually occur after the application's request returns control. So long as the model is frozen, multiple threads could be used for rendering. But some things have to wait. For example you can't save a model while it is in the midst of being updated! And, in SketchUp's case, nobody has figured out a way to use multiple threads to capture model geometry in a database simultaneously while presenting it to the user for editing.
Are you kidding me?
-
Better Scenes organization. I'd like to be able to create and save sets of scenes, which would be great for creating presentations. Maybe there's a way to do this now that I'm unaware of.
-
@unknownuser said:
LOL!!! Really? Who ever is downvoting this post... i would like to hear your explanation.
(maybe you have to re-read the posts above?!?)
-
I agree with slbaumgartner. He provide some reasonably good examples.
I cannot agree with someone who just says "Are you kidding me" without even a single substantive statement to corroborate their statement.
Perhaps it is you who should explain !!
-
Physics? I have not had any luck with the 2 plug-ins currently available.
-
How about voice commands? It's the way of the future IMHO.
-
@baz said:
How about voice commands? It's the way of the future IMHO.
have you any experience with this? I wonder how effective it is compared to key commands.
-
@pbacot said:
@baz said:
How about voice commands? It's the way of the future IMHO.
have you any experience with this? I wonder how effective it is compared to key commands.
Not directly, only thru sf movies
.
But imagine not having to remove your attention from the model as you "Pushpull, 200mm, go"
Or, "linetool, red axis, 600, go." Or even, "Rectangle, 30 metres, green axis, 10 metres, push pull, 6 metres, blue axis, make component, copy by 5 , red axis, 20 metres, go." "Undo last."
The mouse would still be selecting the area of focus. Gotta be quicker and less stressfull.
Possibly you could then use a 'SpaceNavigator' more effectively, tho no experience there. -
@garry k said:
Perhaps it is you who should explain !!
ok...
@unknownuser said:
@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.
@numerobis said:
%(#0080BF)[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:
...
If there are better ways to improve the performance single threaded - no problem.]@slbaumgartner said:
Some of the things you list can and probably are passed to separate threads, whether explicitly by SketchUp or by the operating system. For example, file writes are usually buffered by the system and actually occur after the application's request returns control. So long as the model is frozen, multiple threads could be used for rendering. But some things have to wait. For example you can't save a model while it is in the midst of being updated! And, in SketchUp's case, nobody has figured out a way to use multiple threads to capture model geometry in a database simultaneously while presenting it to the user for editing.
@unknownuser said:
@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.
@numerobis said:
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.
@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.
@numerobis said:
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.
@slbaumgartner said:
This is a misunderstanding (see also my other post). Only SketchUp extensions/plugins are written in Ruby. The core of the program is in C and/or C++. At this point in time, rounding edges and processing SubD models are not built into the core of SketchUp, they are extensions. The philosophy of SketchUp has always been to keep the core relatively simple...
So do you think it would have been better to tell him once more that i already know the difference between Ruby code and compiled code (e.g. C++)? And that i think that if it is not possible to speed up things in Ruby, they should find other ways, which of course would mean something other than Ruby, and most likely compiled code (what else?)?
And then i could have said once again, that i know it's not possible to use multi threading on every task, but that there are many examples of other programs where it has already been implemented successfully and more is planned so it seems to be possible for many tasks (...regardless of the "fundamental computer science reasons" that make it "essentially impossible").
And maybe i could have told him that i'm aware of the old story of the "philosophy" of SU to keep the core simple because i'm following the develeopent for more than 15 years now, and then say once again, that i think that such fundamental functions should be implemented into the code if there is no other way to make them run (MUCH) faster and then maybe that i don't think that some more functions will make it "bloated", especially such basic things like quads, subd or rounding edges.
And maybe then he could have answered that the SU team can't do anything to speed up the Ruby code and that SU is programmed in C++ and that it is not possible to use multi threading... Is that how you think the "conversation" should have been continued? But how many times?Btw. i thought this was meant as a wishlist and not a thread for endless "discussions".
-
Building software that exploits multiple cores can be extremely complicated and often does not increase performance significantly. Multiple cores, threads and processes are some of the most misunderstood computer concepts. Someone thinking that doubling the number of cores should double performance is in most cases completely inaccurate.
I've written software for the transportation industry and have effectively designed applications using a single process and several dozen threads. Threads were chosen in this case so as not to lose any real time data. For example, 1 thread read and processed GPS data while 1 thread read and processed ECM data and another thread handle m2m cellular communication and another satellite communication. There was some parallel processing that could have benefited by multiple cores - but not much.
Please note that cores have to share memory, share disk access etc. So even the effort of backing up the skp to disk would require most if not all of the cores to synchronizing prior to writing the file so that the application could be completely sure that it was in a known state at the time it flushed to disk. Seems like a lot of extra work for very little gain.
If you can completely isolate a number of tasks as completely independent then those tasks can be processed in parallel and run on separate cores.
An example would be an application that visually compares different sorting algorithms. A copy of the same list of data could be sorted using sorts such as, 1)bubble sort, 2) insertion sort, 3) merge sort, 4) bucket sort, 5) heap sort, 6) quick sort
You could perform the sorts sequentially but the effect wouldn't be all that interesting. So run them in their own threads and start them up. What you would see is the fastest 6) quick sort would finish first and the rest would follow. Now the effect is visual.
Some of the rendering programs that use ray tracing can very effectively divide tasks across multiple cores.
Advertisement