File size versus Component Instances balancing act?
-
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