Wishlist for SketchUp 2018
-
@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.
-
No answer to my question and an essay about building software instead that i will never read? ...should i give it a thumbs down now?
No, i don't think so... Ok, I'm out.(just one last thing... RailClone and ForestPack are working great with their multi threading... but maybe Itoo is just dumb and the development was completely unneccessary... LOL these idiots!)
-
@baz said:
...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.If you're going there...why use a mouse instead of eye tracking..? And maybe have SketchUp talk back to us... Some inspiration from my favorite sf series when I was young.. (start at 48:00 for the talking computer part) https://www.youtube.com/watch?v=7rt06UPT5-s
-
One thing I would definitely like to see is the ability to control the width of the fill in 'filled' dimension text in Layout, or to at least make the fill boundary closer to the length of the occupied text...perhaps extending beyond the ends of the dimension text by the same amount that the fill adds above and below the text, or slightly less even. Currently the fill boundary is superfluously extended beyond the ends of the dimension text, creating unnecessary blocking/overlapping of items in close proximity.
-
Simple workspace toolbar migrate.
-
@baz said:
How about voice commands? It's the way of the future IMHO.
can you imagine how annoying an office full of people voicing sketchup commands would be?
I think I will stick with just voicing the occasional expletive and keeping the other commands silent.
-
@pmolson said:
@baz said:
How about voice commands? It's the way of the future IMHO.
can you imagine how annoying an office full of people voicing sketchup commands would be?
I think I will stick with just voicing the occasional expletive and keeping the other commands silent.
Well, there is that, but I work alone and I talk to myself anyway
-
If you want voice then I would look at a 3rd party voice add on. Therefore I wouldn't want or expect sketchup to do it. With a 3rd part solution then you can use it for many applications - not just one.
Advertisement