7.1 Performance

tfdesign

@tfdesign said:

(One thing I love about OSX is the way you can sequentially toggle through all open windows of the current application by pressing the command key and the ` key together. I wish I knew how to achieve this in XP.

If it's an MDI application, like Photoshop, then use Ctrl+Tab and Ctrl+Shift+Tab to toggle backwards and forwards between the windows.

Thanks Thom. It worked!

Interesting though (and again sorry for the OT), this is not the standard Mac way of doing this, and Adobe really should stick to standards! It's nice to know that the SketchUp developers have done the right thing, and you can toggle windows how it should be done (for Mac that is, not PC)

Anyway, that's besides the point, if the Mac SU version is wireframing, and the PC version isn't, then could this be looked into? But I'm sure that this is not a graphic card issue, because I got the same problem with my HP workstation P4 running XP SP3. I swapped out the NVidia card for a more powerful one, but there was no difference. The Duo Core II in my Macbook Pro worked a lot better, as long as there wern't multiple windows open. And I should mention again, that i was dealing with models/files that were 14+ mb's in size. Smaller files didn't exhibit the same behaviour.

Aerilius

I also want to thank you for the performance increase (especially when orbiting) - the maintenance release made it also work on the OS of my choice ( )

I only see three little issues where there's room for improvement:

When editing the a texture on a face (to move the pins), the area around the face shows the rest of the model with an overlay of the texture. This slowed Sketchup down until SU7.1 It still can be improved especially when you need to zoom very very much (for searching the pins of GE terrain )

Sometimes the display in photomatch is a bit lame due to a high density of those dotted grid lines:

If you intensely use components and layers, you sometimes see "ghost components" and "ghost groups" that show only up while orbiting. These components/groups are on another layer which was turned off. For example I had some hundred high-poly columns (well-considered on an invisible layer) that decreased performance a bit.

brodie

working well: the performance boost has been noticeable and much appreciated.

room for improvement:

Exporting 3d models to another format seems to take longer in SU than in other programs
Long save times - SU files can get fairly large and I've had autosaves taking 1min+ each pop for large architectural models. Again, I'm comparing this to other programs such as 3ds Max and AutoCad.
Better integration with rendering apps - Based on how this forum has changed over the past couple years a LOT more people seem to be using SU to transfer to a rendering app. It'd be nice if SU started some back and forth to help smooth the transition. For example, I use Maxwell Render. In 3ds Max you can export the model into Maxwell's format (which may take a minute) or hit render and it will automatically render the scene. With SU I have to export the scene everytime which can take 5min+. Perhaps SU could work with various render apps to improve some of these issues.
UV mapping is a huge bottleneck for me and for many others. It requires going to another program to do any UV mapping other than planer or box (unwrap, cylindrical, sphere, etc.).

-Brodie

thomthom

@unknownuser said:

Long save times - SU files can get fairly large and I've had autosaves taking 1min+ each pop for large architectural models. Again, I'm comparing this to other programs such as 3ds Max and AutoCad.

100+!!!

@unknownuser said:

UV mapping is a huge bottleneck for me and for many others. It requires going to another program to do any UV mapping other than planer or box (unwrap, cylindrical, sphere, etc.).

+++

Whaat

Great job on 7.1!

In terms of increasing performance further, these are my wishes:

Improve the speed of saving and loading large SKP files. Try opening a SKP that was exported from Microstation. From my experience, a 40MB file can take more than 3 minutes to open and save. It might have something to do with how Microstation creates deeply nested groups when it exports a SKP file.
Improve the speed of geometry creation. This is a huge bottleneck for Ruby scripts. Why does it take so long in SketchUp compared to other apps? It also takes a very long time to import high-poly 3DS meshes due to this same problem.

thomthom

@whaat said:

Improve the speed of geometry creation. This is a huge bottleneck for Ruby scripts. Why does it take so long in SketchUp compared to other apps? It also takes a very long time to import high-poly 3DS meshes due to this same problem.

Yes! Good point! Ruby geometry creation is a big bottleneck. I was doing some testing and found that most of the time in my scripts is spent on the methods that create geometry. All other calculations become insignificant. I found that entities.fill_from_mesh is the fastest way to add geometry, but that isn't always an option to use. And another observation is that the more entities is already in the entities collection, the longer the methods to create geoemtry take. Doesn't even take that much geoemtry before it starts to bog down.

brodie

I have to agree with Whaat regarding the rubies. Rubies, in general, are problematic. With no integrated progress bar, screens going blank, and some rubies taking 5min-5hours to do there thing it feels extremely clunky and has caused me to do a lot of things the hard way just to avoid problems.

-Brodie

thomthom

In regard to Ruby and adding geometry: Check out this thread for comparisons of various methods to add geoemtry - and the general frustration of the topic: http://forums.sketchucation.com/viewtopic.php?f=180&t=23994

chrisjk

Please, please, make SU capable of using all my CPU cores!

AndrewS

@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

thomthom

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.

Tyler Miller

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

thomthom

@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.

ken

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

solo

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.

chrisjk

@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.

chrisjk

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.

Gaieus

@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)

solo

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.

Gaieus

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.