File size versus Component Instances balancing act?
-
I've notice quite a few discussions about file size recently and became curious about a few things.
Obviously using components reduces the size of the file, but it seems that there are limits to the benefits, or at very least, it seems to be a balancing act and I'm certain varies greatly depending on the type and size of model.I was curious because I often use a PC with a slow processor and not the greatest Graphics card, so even small models can have a significant effect on performance.
I've found that you can create quite a detailed piece, that may be 4 of 5meg, using just raw geometry and it will behave quite well even with shadows turned on.
However, if I recreate the model using multiple components, I can reduce the file size down to a couple of hundred K. While this is useful in so many ways, I find that when you start using multiple instances of components the performance can drop quite quickly, especially when using shadows.I'm certainly not complaining about it, I'm just looking to understand if there is a logical balance and how others deal with getting the best performance on a limited system.
I modelled this wheel as a test case for myself as it was a structure that had been mentioned a few times (personally I have little interest in modelling cars). It's purely out of my head with no reference material, so no need to tell me it's not a proper wheels and tyre.
The original, made with just groups, was around 4meg,I used 100sided circles to get a smoother finish and to push the limit, I then split it down to all possible components which brought the file down to 290kb.
So I guess my questions from all this drivel are,
Am I right in thinking you need to look for a balance?
Does multiple nesting of components cause issues?
and Do components that are broken up into multiple nested components Render properly?If you've managed to read this far, I thank you.
-
Box, That's a very interesting observation I wasn't aware of. But it's not just file size that's affected, but modeling access. If you have 20 instances, and need to change a single entity, it can be done in one step, but if you have raw geometry for the 20 items, that will be more difficult. Suggesting that an optimum size is also subject to the models use.
-
Hi, Box:
This is stuff I also have wondered about.
Here are your questions restated:
"Am I right in thinking you need to look for a balance?"
I vote yes. Obviously, as part of file management, you also need to search for and delete internal, or duplicate faces and edges. Use xray view to spot them, select and delete."Does multiple nesting of components cause issues?"
I vote yes, but only because the few times I have multi nested stuff I found I couldn't really keep track of where I was. Outliner is supposed to help keep track of components and groups, but you gotta switch it on and off for some cases or it will cause a Bugsplat."and Do components that are broken up into multiple nested components Render properly?"
I do not have an answer for this. Probably is an issue.Someone else want to step in?
-
@box said:
Am I right in thinking you need to look for a balance?
Yes, definitely. Using components is advantageous in many respects but overdoing something is never a good thing (also see below).
@box said:
Does multiple nesting of components cause issues?
By experience of many users, deeply nesting things (several levels I mean) seems to slow down performance. In any case, while using components has many benefits (bringing down file size, ability to edit multiple instances by editing one...), it will never help with performance as the computer will still need to display them.
@box said:
Do components that are broken up into multiple nested components Render properly?
Rendering multi-level, nested components should not be an issue however.
-
Thanks for that guys, clarified a few things for me.
I'll look into unnesting some of the components and see how that works out.Thanks again.
-
great subject : have you seen this related one ? : http://forums.sketchucation.com/viewtopic.php?f=15&t=38060
-
It's definitely a balance. The file size is only loosely related to the navigability of the model. Obviously components have a great advantage in terms of making global changes to a model, as you only need to edit a single instance. However the side effect of multiple instances leading to a reduction in file size (over raw geometry or identical groups) is really only relevant if you need to send the file to someone else, post it here, or have limited space on your hard drive.
What does bear a direct relationship to navigability is the number of faces and edges in the model. It doesn't matter whether they are in groups, components or just raw. In all probability, many nested levels will almost certainly register a hit in performance over simpler geometry...but may be organizationally far more useful. Therein lies the balance.
However complex your model...whether you're using many component instances or none at all, there are certain basic procedures you need to follow if your model starts getting uncooperative.
- Turn shadows off.
- Only show hidden geometry when you have to.
- Organise the model onto different layers, then turn off all layers except the one you're working on...with the obvious exceptions of getting an overview or rendering.
The attached file will give most people severe problems...even though it's only 260KB
-
this is very interesting model !
what makes SU so slow with it ?
-
As I said, the file size is not always related to the navigability of the model. What is important are the number of faces and edges...and in the columns model there are almost 2 million edges and nearly 750,000 faces.
The fact that it is only 269 KB is completely irrelevant. In fact, if you deleted half of the columns and resaved the file (in V3, like the original) the size would only decrease by about 10 KB. I doubled the number of columns in the original file from 100 to 200 and the size only increased by that amount, thus demonstrating how misleading the heavy use of repeated components can be.The wheel and tyre are the same...small file size but over 1 million edges and 87,000 faces. I did the same thing to that file. I duplicated the wheel and saved it as a V7 (like the original) There was no appreciable change in file size at all...in fact it appeared to be smaller than the published size, but that might be down to how the bytes are calculated.
-
what is then the best option : drawing in low poly or using a lot of *.png & alpha channel images?
-
Either will do. It depends on how you are going to use the model. Obviously pngs look more realistic for far fewer faces than even low poly geometry. But if you are going to use them as non Face Me elements, like railings or balustrades, then they have to be in a position where they will not be seen edge-on, or so close you can see the pixels.
Generally, low poly is the best route. A single one of those corinthian columns is about as high-poly as it's sensible to go if you intend to use an array of them, together with all the other architecture and entourage in a visual.
You could always replace one of them with a higher poly version if you were making a render from a position close to its capital.Images are handled by the graphics card, which on a modern system is usually well-suited to the task; so they are not going to tax the cpu any further.
This attached model is much larger than the other two but far easier to navigate....as it has less than 200 faces.
Advertisement