File size discrepancy
-
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!
-
I actually know what boat you are in. I also tend to model every small detail when possible and sometimes "overcomponentiate" my models. I have a model with about 1.3 million edges and over 300,000 faces but the size is less than 7 Mb (true that there are only "light" SU materials as "place holders" in it as it was later re-textured in Max for rendering).
-
@tig said:
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
Yeah, as I just told Gaieus, I've accepted that this is going to happen. I don't like it, but I accept it.
@tig said:
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'.
Actually the treads are a texture (until I can get around to putting in the real things
)@tig said:
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
Actually it has not affected panning, orbiting, zooming, anything (so far). And I am coming close to reaching the dreaded 10mb limit. Occasionally my textures will start to blank out when doing something, but all I need to do is purge (even if there's nothing to purge) and things are back to normal. Any idea why this is?
Probably won't have the nerve to upload the dang thing when I do finish it. But this has been my learning model, so it was worth it.
@tig said:
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.
I have kept this is mind, and I don't include detail that likely won't be noticed or benefit the model. As I mentioned before, tires and wheels are very important to the appearance of a car, so I did splurge on them. Overall I think the benefits of this have justified the extra edge count.
Wow! Screws under the chairs, with full threads! Can I have her phone number?
Advertisement