File size discrepancy
-
@hellnbak said:
It is something to worry about if you are planning to share your model in the warehouse.
If that were not the case I would still be trying to keep my file size to a minimum. It's a factor in computer performance, and, IMHO, it's just a good habit to get into, which is what I'm trying to do. If keeping your file size to a minimum is part of your normal modeling practice, then you don't have to scramble to get it down when it does become a factor for whatever reason.
i dunno, i guess my post could sound like i'm saying "just slap it all together and don't worry about file size" but i'm not saying that at all..
it's just that the whole "work your butt off to keep file size down" sounds counterproductive or misguided.
pretty much, the cleaner your geometry and more efficient you work, the smaller the file size.. strive for that instead and your models will be smaller automatically.
i'm just thinking of the tire .skp file that you posted a while back that was around 40,000 entities and had a whole bunch of unnecessary geometry.. that could be modeled much cleaner and faster with a bonus of 1/2 the file size.. (imho) -
How are you determining the size of the instance once its inserted into the model?
-
@unknownuser said:
pretty much, the cleaner your geometry and more efficient you work, the smaller the file size.. strive for that instead and your models will be smaller automatically.
That's all I'm talking about, I want to get to the point that my geometry is clean and my work is efficient as a matter of routine, without having to work at it. When I mentioned working my butt off to get the file size down on a model, it was because when I created that model I was not working that way. Not even close.
@unknownuser said:
i'm just thinking of the tire .skp file that you posted a while back that was around 40,000 entities and had a whole bunch of unnecessary geometry.. that could be modeled much cleaner and faster with a bonus of 1/2 the file size.. (imho)
Actually that's the model I was referring to
I know it was sloppy work. It was my first tire, and I needed to clean it up and do it right. jAnd most importantly, learn in the process. And hopefully my work in the future will start out right and I won't have to backtrack and clean up my messes.I'm still new to all of this stuff, and I know no matter how hard I try I will still not even approach the quality of some of the stuff I've seen posted on here, not for a long time, if ever. But I'll at least get better at it. My "suck factor" will slowly decrease, given enuf time
And BTW, I really appreciate your honest appraisals of my crap, I mean models, that's what I'm looking for. Be brutal!!
-
To get back to my original question, does anybody know why this is happening?
-
It is a larger gain in file size than I would have expected. There is no way to share the model here so we can look at it?
-
When there is a file with a certain size and you insert it in as a component (say) 4 times, the master file does not only need to contain the geometry inside the component but also needs some bytes to "remember" the size, position, alignment and materials (there could be added materials from outside) of those components. Don't worry about that extra 1Kb.
-
@gaieus said:
When there is a file with a certain size and you insert it in as a component (say) 4 times, the master file does not only need to contain the geometry inside the component but also needs some bytes to "remember" the size, position, alignment and materials (there could be added materials from outside) of those components. .
I'm having trouble buying this as an explanation. The file where I copied the model from (where it was the only thing in the file) also has to remember everything you mentioned. So all this "remembered" information was taken into account with the original file size. And at this point there was only 1 instance of the added component.
And as far as "Don't worry about that extra 1Kb", it's not 1kb, it's 99kb, and that's a fair chunk of change for a model that has to be limited in size for the warehouse. I don't know, maybe you guys are used to routinely dealing in very large models, and file sizes, and so can't appreciate my concern when trying to limit the file size of such a relatively "tiny" model.
And just so you know, purging is not a factor in this. I do purge, religiously. If I consider the possibility of someday thinking about maybe doing something to a model, I purge. If I look at a model crossways, I purge. And I purge using the plugin, not just the one built into SU. Again, just so you know.
-
When you have a compact SKP at ~600kb and you then insert it into another SKP you should expect this other SKP's size to increase by ~600kb to account for the additional data needed to describe this newly created component and its various 'values' BUT if you have also placed an instance of it in this other SKP there needs to be extra information in the SKP to cover the instance's unique 'values' - like its id, its transformation, its layer, its name, its material and so on... This is where the 'extra' ~99kb comes from. Every time you add an instance the SKP's size must increase - you are adding data to it - although it won't increase by the size of the original SKP but rather by the size of the additional code needed to hold each instance's unique 'values'.
-
Not sure I understand this. Actually I'm sure I don't understand this - doesn't the original file of the component contain all the required information about it, including all the extra stuff that needs to be remembered about it, and thus wouldn't all that be included in the file size of the original model? Why would more information beyond this be required in the model where I paste the component? And I did not make extra instances of it, just inserted the original component into the model. Sorry if I'm being obtuse about this, but I really would like to understand what's going on.
-
If you insert a SKP into another SKP as a 'component' you have added the original SKP's data ~600kb AND also an instance of the new component - at ~99kb extra for the data that each instance needs to describe itself...
IF you copy/paste the 'raw' geometry from one SKP file to another than the recipient SKP should only increase in size by the equivalent of that added geometry, which should approximate to the original SKP's file size [actually it'd be slightly less since the original SKP contains data like 'name' that isn't transfered].
You have to get your head around the fact that a 'component' isn't just the instance that's placed in the model, it's that instance you can see AND the component-definition that is 'hidden' in the SKP's database. The component-definition holds all of that component's data - its geometry etc - and so that is approximately same size a an external SKP file [in fact you can think of component-definitions as small models within the main model's SKP - that's why there are separate 'entity' collections for each]. Each instance of a component-definition needs extra data in the SKP to describe where it is, what layer it's on and so on - therefore each instance of a component adds a tiny bit to the file size, because of that necessary data - however because an instance is a 'marker' it's much more 'economical' than having the 'raw' geometry inserted directly into the model several times... Therefore using component-instances for repeated objects is a good way of keeping your file size optimized... BUT if an object only occurs once then using its 'raw' geometry placed directly into the model will keep the file minimized.
Incidentally 'groups' and 'images' are only 'instances' of specialized kinds of 'component-definitions', so like 'normal' components using 'instances' of groups/images in place of 'raw' geometry will inevitably push up the SKP's size by a little - but the advantages for manipulation and separation of geometry during modeling usually outweigh the small file size penalty..... -
Model A contains geometry and values at 1mb.
Model B contains geometry and values at 1mb.
A + B = 2.1mb.
Because A previously contained it's own values minus B when B is inserted these values are amended to A creating extra values. Thus size increase.
So A's values + B's values creates AB values. These new values have the slight increase that both combined bring to your model.
My advice is to continue on your modelling odyssey and when this is finished and you're over the 10mb limit. Just revisit certain components to see how to reduce segment or face count.
-
I think you're right to be skeptical. Without knowing SketchUp internals, or the .skp file format then it's all speculation.
Wouldn't the amount of "extra" data be the same for a simple cube, as for the complex tire?
-
Normally it should be. Yet we are always on theoretical stages with hellnbak so never know what he actually have in that file.
-
@gaieus said:
Yet we are always on theoretical stages with hellnbak so never know what he actually have in that file.
That certainly isn't making it easy to help; so I will add:
Without having access to the model, it's all speculation.
-
Sorry, bit of a snowstorm here, wasn't ready for it.
Here's the file. I didn't include the file I pasted it to because it is too large. But it seems to do the same no matter what file I add it to. Thanks
-
Your original SKP is full of groups and multiple nested component instances ~657kb...
If you insert it into another SKP as something slightly bigger that the original because the multiple definitions and instances each need some tag 'tags'... ~668k.
IF you explode the original back to raw geometry when you insert it into another SKP it's 35700kb !!!
Because you now have 27,681 separate entities per tyre !!!!So your tyres are terribly 'over detailed' and although 'componentizing' the repeated elements like 'treads' and 'spokes' does keep the total size down you will inevitably get a slight up-sizing on its insertion, as every sub-component AND the instance of the whole thing itself need some data the describe them... The few kb that you get with this is really 'nothing' - 'raw geometry' makes for a much bigger file size...............
-
@tig said:
Your original SKP is full of groups and multiple nested component instances ~657kb...
Yes, is this not an accepted method of keeping the file size down?
@tig said:
IF you explode the original back to raw geometry when you insert it into another SKP it's 35700kb !!!
Because you now have 27,681 separate entities per tyre !!!!The whole point of using this method is to be able to have 35700kb of detail and have it only take up 675kb. Right?
@tig said:
So your tyres are terribly 'over detailed'
Really not sure what you mean by this. It's as detailed as I wanted it to be. I made it the way I did so that I could include that detail. Given how very important tires and wheels are to the overall appearance of a car model, I decided to make them a bit nicer than maybe some others might have. If I managed to include the detail I wanted to include, and still keep the file size down, how does that make it "terribly over detailed"?
@tig said:
The few kb that you get with this is really 'nothing'
While I don't agree that a nearly 8 percent increase in the file size is "nothing", if it's the price I must pay to get the kind of model I want, so be it. I just wanted to know where those extra 99kb were coming from, and if there was anything I could do to avoid it. Apparently I can't. Such is life
I don't mind criticism of my models, as a noobie I look forward to it. I know that now is the time to find out if I can improve my modeling techniques before any bad practices set in too hard. So I need to ask, are you saying the methods I used to create this model are not those that would be used by a more experienced modeler (assuming that modeler also wanted to include the level of detail that I did)?
Your input is very much appreciated, thanks for taking the time.
-
@hellnbak said:
So I need to ask, are you saying the methods I used to create this model are not those that would be used by a more experienced modeler (assuming that modeler also wanted to include the level of detail that I did)?
I am sure TIG did not mean this is not a proper way of modelling ifyou want to put as much detail in as you are putting andkeep the file size down to the necessary minimum (considering that you are planning to upload it to the Warehouse if I remember correctly and your goal is not to reach the 10Mb limit).
Deeply nested components will often cause some performance issues but you have to make the decision whether to risk those issues or allow your file size grow.
But back to theory; when you insert a component into a model, always expect the file size grow a bit more than what the file size of that component is as a model itself. Also, the file size will slightly grow with each inserted instance and eventually you will need 4 of these wheels.
When modelling the car itself, also consider to model only a half, turn it into a component and mirror it. You will gain some file size reduction this way as well (of course, do not include the steering wheel, the pedals etc. into the component for instance).
-
The way you model it is quite correct - using components for repeated geometry/objects, and the small overhead of importing it into another model is inevitable because of the additional data needed to describe it within its new home - for example a component imported has a 'path' saved with it showing where it came from so you can 'reload' it later if the external SKP changes - if the component is made 'in situ' then that value is '', so the imported definition's size must go up. The few kb extra you get is as 'nothing' compared to the 3Mb you have saved by making a componentized tyre/wheel in the first place.
When I say your tyre/wheel is 'over detailed', although I accept that you as the modeler can include/exclude as much detail as you wish, you need to remember that the instances and the number of displayed facets and edges etc that you have in your one tyre/wheel is more that a whole complex building might include. This WILL have affects on the performance of SUp panning/zooming, exporting and rendering etc: it's not just 'file size' that's important but the number of displayed polygons too. You can achieve the level of detail in other ways - e.g. apply a 'tread texture' instead of modeling every indentation into its faces in 'reality'.Always remember that you are making a 'model' not a 'real object', so you can include whatever level of detail you like... BUT be aware that detailing every last bit of an object is often unnecessary - especially when you won't ever be seeing it, or might never expect to see it so close up so you'll never notice the simplified form.
As an example - I had a young assistant modeling an 'office layout' for me and she couldn't understand why her simple box of walls floor and ceiling etc, with a few desk and chair components placed into it was so sluggish when she tried to move around it with textures and shadows switched 'on'. When I looked at the model she had literally millions of polygons that SUp was struggling to calculate for and 'render'. The imported furniture component definitions had sub-components for ALL of their parts - there were even screws in the underside of the chair that would never be seen, which had 'slightly domed cross-heads' AND all of their threads into their holes! She had more 'bits' in just one chair than she had in the whole 'building'. So a little judicious editing of these wayward components reduced the whole model's polygon count dramatically and all was well - the exported images looked not different from those the clunky version as all of the 'baggage' that was removed was 'invisible' anyway...
-
@gaieus said:
Deeply nested components will often cause some performance issues but you have to make the decision whether to risk those issues or allow your file size grow. When you insert a component into a model, always expect the file size grow a bit more than what the file size of that component is as a model itself. Also, the file size will slightly grow with each inserted instance and eventually you will need 4 of these wheels.
Yeah, I realize now that this stuff is going to happen. It's just something I will have to get used to in the wonderful world of SU.
@gaieus said:
When modelling the car itself, also consider to model only a half, turn it into a component and mirror it. You will gain some file size reduction this way as well (of course, do not include the steering wheel, the pedals etc. into the component for instance).
I have been mirroring whenever possible, helps a LOT as far as file size. Just one of the many tricks I'm having to learn.
Can't help dreaming about doing this without any concern for polygon count or file size or computer performance. Wow, would that be great! I could build my own world!
Advertisement