Component processor usage...

tomsdesk · 12 Sept 2008, 14:54

...stretched copy of a component vs. unique component copy with stuff inside stretched?

I'm doing a small terrain model (rather large for me) and have inserted 3 face-me trees. I copied them several times and stretched the copies to form about 10 trees of different sizes. I'm wondering if anyone knows for sure if this method creates more or less load on the processor than making 10 unique components...?

remus · 12 Sept 2008, 15:01

I dont think its going to make much difference on processor usage. SU has still got to display them (and do all the other stuff associated with having geometry.) It might have a difference on file sizes though.

My guess is that lots of scaled components will be smaller than lots of individual components, but if youve only got 10 of them in your scene i dont think it will make much difference.

Alan Fraser · 12 Sept 2008, 16:31

Processor usage tends to be all about edge and face counts, Tom. How the stuff is organised...or even if it's just raw geometry...is largely irrelevant.

AdamB · 12 Sept 2008, 18:14

Not strictly the case... but I know what you're saying..

Broadly there are 3 things that take time in graphics:

Containers the geometry is inside
The geometry itself
The pixels that need to be drawn

Working backward up the list:

If you're model refreshes faster if you make the window smaller, the limiting factor for your computer is drawing pixels. You are what is known as "Fill-bound".
If you find that as you subdivide a surface more and more but keep the window the same size, the refresh gets slower, the limiting factor is geometry. You are what is known as "Geometry-bound"

Finally, there is a "fixed-cost" with opening each container of geometry (be it a group or component instance) in order to draw what is inside. Having 1 container with 100 polygons inside is much faster to draw than having 100 containers each with 1 polygon inside. There is a sweet spot for how finegrain you should create containers aka components/groups. Unfortunately it relates to how fast your graphics card is...but as a rough rule of thumb, a container of less than 20 odd faces is going to hurt your performance if you have lots of containers.

The pathologically bad example of this is the standard SU beech tree which has a container for each leaf. This is a really bad idea and the modeller responsible will be taken out and shot when I'm ruler of the universe..but I digress. Much better to have a container/component with 40-50 leaves inside and still get the advantage of compactness with the advantage of keeping your graphics card busy.

Adam

tomsdesk · 12 Sept 2008, 18:24

Thanks guys (edit: Remus, Alan)...what I assumed as well (but didn't want to fall into the ass-u-me trap :`) Gonna have a hundred+ trees on my current project, so every little bit helps.

Also, the first method (the one I'm using since my old operating system doesn't always access the "stored for later use" sub-directories until I'm in sleep-mode backing the day's work :`) won't work with the new component spray ruby I was waiting for an opportunity to use...thank god drop.rb wasn't a wet-dream.

Edit: Adam...if I understand you correctly: in my case both methods I have the same number of containers, with the same amount of geometry in each, so should be no difference?

Chris Fullmer · 12 Sept 2008, 22:35

@adamb said:

The pathologically bad example of this is the standard SU beech tree which has a container for each leaf. This is a really bad idea and the modeller responsible will be taken out and shot when I'm ruler of the universe..but I digress. Much better to have a container/component with 40-50 leaves inside and still get the advantage of compactness with the advantage of keeping your graphics card busy.

Ahh, so good to hear a formal explanation about that tree. It has always been the slowest component and I refuse to use it. Now I know a little bit more about the problem. Thanks Adam,

Chris

plot-paris · 16 Sept 2008, 12:57

that was a very good explanation indeed. thank you very much, Adam.

and while we are at it: what is the easiest method of showing the framerate of SketchUp? is the time.test-thing command the best way or is there something like a small digit in the top right corner that shows the current framerate?

Anssi · 16 Sept 2008, 17:12

Thanks very much Adam

This is something that I have to start keeping an eye on. The sluggishness of some of my quite small models could be caused by this "over-organizing".

Anssi

Chris Fullmer · 16 Sept 2008, 18:59

I didn't get around to playing with this a few weeks ago when this thread first came up, but now I did. So I made 3 models to check this out to see how noticeable it is.

There are 3 models. Each model is made up of 12,100 separate faces. Each face is a simple triangle.

In the first model, each face is a separate component. So that is 12,100 instances of a single component.

The second model has 10 instances of a component with 1,210 faces in it. The faces in this component are not component instance, just faces. This model has a total of 10 instances of one component.

The third model has 100 instances of a component that has 121 faces in it.

So model 1 is the extreme amount of components with minimal information inside of each. model 2 is few components, but large amounts of information in each. model 3 is a balance of amount of components and amount of information inside the component.

Its interesting how the file sizes are so extremely different too. I was careful to purge everything, etc, so the files should all contain only the minimal amount of info.

So if you want to the most dramatic effect, open the largest file, model 1 first. On my computer is horribly sluggish. Then close it and open model 3. On my computer, that one navigates with no problems.

Hope anyone finds this interesting.

Chris

PS and thanks Adam, again, for explaining this. Made for a fun experiment. I always assumed there would be some sort of correlation between amounts of components and the amount of info in each, but I never dreamed it would be so dramatic.

model 1

model 2

model 3

plot-paris · 17 Sept 2008, 07:55

great test, Chris!
it demonstrates nicely what Adam explained.
interestingly the file with only 10 components worked fluently on my laptop (Core2Duo 2,4Ghz; 4Gb Ram; GeForce 9650M GS), whereas the one with 100 components was rather choppy. the one with all faces being a seperate component took between 20 and 30 seconds to update the view...

AdamB · 17 Sept 2008, 11:02

@plot-paris said:

and while we are at it: what is the easiest method of showing the framerate of SketchUp? is the time.test-thing command the best way or is there something like a small digit in the top right corner that shows the current framerate?

At the Ruby Console, you can type this mouthful:

1.0 / Sketchup.active_model.active_view.average_refresh_time

to get frames per second