7.1 Performance
-
Please, please, make SU capable of using all my CPU cores!
-
@chrisjk said:
Please, please, make SU capable of using all my CPU cores!
What specific operations do you believe would be best served by adding multi-core utilization? 3D is an inherently GPU-heavy endeavor and most real-time editing, orbiting, etc., can't really be improved with extra CPU cores. There are some areas where multi-core strategies can be applied; I'm just curious what items stand out in your mind.
Andrew
-
Don't have anything to add regarding CPU cores, but it made me remember another issue ruby scripters have been trying to deal with: being able to create new threads. It seems to be impossible within the SU Ruby environment.
Many attempts has been made in order to allow CPU intensive scripts work without locking up the SU UI.Whenever a processing heavy script runs and you switch to another window while it works the SU window will grey out and stop updating, and from testing - that also seem to cause the script to run slower, impacting the total processing time.
-
Thanks everyone for your replies. I'm thrilled the 7.1 performance boost is working out for most of you.
We'll continue to spend a large portion of our time dedicated to performance improvements. We have not hit a ceiling as of yet, and as many of you point out, when you remove one bottleneck, it often unmasks the next bottleneck.
One thing to note, SketchUp has a very unique geometry engine that requires us to merge any new geometry in will all the other geometry in the same component. This is part of what makes the SketchUp magic possible, but it can cause as slow-down when adding any significant amount of new geometry, or even a small amount of new geometry into a component with a lot of existing geometry. Importing, or using a Ruby script that is creating geometry makes this issue really noticeable. We'll continue to look for ways to optimize this area.
Thanks again,
Tyler
Google -
@tyler miller said:
One thing to note, SketchUp has a very unique geometry engine that requires us to merge any new geometry in will all the other geometry in the same component. This is part of what makes the SketchUp magic possible, but it can cause as slow-down when adding any significant amount of new geometry, or even a small amount of new geometry into a component with a lot of existing geometry. Importing, or using a Ruby script that is creating geometry makes this issue really noticeable. We'll continue to look for ways to optimize this area.
Is it not possible to prevent SU from doing all this magic when you want to add a large amount of geometry? Is it something that has to run every time you add something? Would be nice to be able to just dump a pile of geometry into a model, without needing SU to do "magic".
Explode is also a method that really bogs down. On larger models it practically impossible to use as it just grinds SU to an halt. I often don't need SU to merge everything - being able to quickly explode would be a great performance improvement. I expect explode's slowness is related to the slowness of adding geometry in general.
-
Well, I have noticed that when I add another toolbar, and the toolbar scatter all over the screen, replacing the toolbars is a lot easier and more consistent. I don't seem to have to chase a toolbar all over the screen to get it to look in position or have a toolbar that refuses to be located where I want it. To me this is an improvement from the hours of chasing toolbars and accepting a placement I really didn't want.
Ken
-
What I would really like is if there was a way SU could recognise imported groups from other apps that are identical and make them into either identical components or groups with the same attributes that groups and components in SU have, IE edit on and all change and smaller foot print in SU.
I do a lot of work with clients that send me .3ds, .obj, etc models with say 200 columns (identical) and I need to spend hours deleting all but one, making it a component and duplicating and placing one by one.
-
@andrews said:
@chrisjk said:
Please, please, make SU capable of using all my CPU cores!
What specific operations do you believe would be best served by adding multi-core utilization? 3D is an inherently GPU-heavy endeavor and most real-time editing, orbiting, etc., can't really be improved with extra CPU cores. There are some areas where multi-core strategies can be applied; I'm just curious what items stand out in your mind.
Andrew
Andrew,
I notice it in the Rubies thing discussed above but not being a Ruby developer, I confess I do not know if it’s a CPU or a GPU bottleneck.
-
I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it. I don't always remember to do this at the time of creating the geometry and it's irritating to have to go back and fix something where a face hasn't been created etc.
I apologise if this isn't considered a performance issue.
-
@solo said:
What I would really like is if there was a way SU could recognise imported groups from other apps that are identical and make them into either identical components or groups with the same attributes that groups and components in SU have, IE edit on and all change and smaller foot print in SU...
Can't you do this with imported stuff?
(And sorry for the OT post - we can chop these parts off) -
Sure one can do that, but they are just grouped or made into a component, I need to make them so that if I alter or texture one, it will edit all the others accordingly.
This is a performance issue as if indeed they all act like one component duplicated 200 times instead of 200 separate objects, SU either crawls or flies.
-
Well, in my above example, I made the three groups instances of the same component - certainly however SU keeps track of "instances" of the same group, too.
-
@chrisjk said:
I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....
I apologise if this isn't considered a performance issue.
I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.
Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorb -
@mitcorb said:
@chrisjk said:
I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....
I apologise if this isn't considered a performance issue.
I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.
Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorb+1
-
++
-
+++
-
I hope my previous quote and comment weren't perceived as being harsh or disrespectful, because I certainly did not intend that.
I just wish to gain better understanding of the program. And I believe open discourse is elemental to understanding. -
++++
...and another thing, im noticing slow downs in transforming lots of geometry and grouping lots of geometry (when i say lots im talking about ~50,000 faces.) Like you say, its only now SU can navigate such models with ease that i've really noticed it
-
@mitcorb said:
@chrisjk said:
I should like SU to handle geometry in small dimensions accurately, without needing the work-around of scaling up/down to fix it....
I apologise if this isn't considered a performance issue.
I agree here. And if it is not a performance issue, perhaps one of the SU team can comment as eloquently as you have on previous posts, so that us laymen can understand, and put this and the tiny triangles matter to bed.
Whatever the answer, I believe folks will appreciate it.
Best Regards,
mitcorbThe small dimension issue is not a performance issue, but I feel your pain. Under the covers, SketchUp represents all geometry in inches with 64-bit floating point precision. When dealing with floating point numbers in applications like SketchUp, you have to establish a tolerances for things like length, angles and planarity. In SketchUp's case, that tolerance factor for length is 0.001 of an inch. Below that threshold, two lengths are considered equal. In practical terms, that means that SketchUp does not support edges that are less than 0.001 in length. SketchUp was originally designed for architecture and it was not conceived that users would want tolerances lower than 0.001 of an inch. Changing it now, while theoretically possible, could have disastrous effects for existing SketchUp models.
That said, the issue is on our radar and does get discussed around here a fair amount. If we can see our way to a solution that works for new and old models, then we'll try to fix it.
Hope that helps,
Tyler -
Tyler: that bit of info is greatly welcome! It allows us scripts to more reliably match and control the tolerance that Su works with.
I don't suppose you got some info in regards to what is considered co-planar? If you make a script that iterates a model's edges, and check if it's adjacent faces are co-planar using
face1.normal.same_direction?(face2.normal), and remove the edges then that method returns true, then in some cases the faces are lost as SU doesn't really consider them co-planar. It also goes the other way, it sometimes says they are not co-planar, while you can remove the edge and the two faces merge. It's a very tricky issue (all though not a performance issue). The SU API methods that compares vectors doesn't seem to match 100% with how SU really works.
Advertisement