Re: Why is 1.0074 so much slower?
Teya,
I’ll try to answer your questions/bullet points in order:
- Did you know you can change the focal length in SU itself without having to adjust it in VfSU’s camera options? Just select SU’s zoom tool and type in the new focal length (suffix it with “mm” to enter standard camera focal length figures or “deg” to enter Field of View figures). That way you’ll get much closer to WYSIWYG output between SU and VfSU.
- Components inside components do cause parsing slowdown (parsing= the process of VfSU “reading” the skp file), but don’t let that stop you using them. Components are so fundamental to good SU modelling that they are too valuable to give up on and there are ways around the slowdown! (see my final bullet point)
- As a rule, never use components instead of groups, the more components you have in an SU model the slower VfSU’s parsing will be. Just use components and groups as you normally would in SU: groups for geometrical objects which are only used once and components for geometrical objects which will be repeated thoughout the model and which may need to be edited simultaneously later. The “disappearing group bug” in VfSU can be fixed quite easily by following the advice in my final bullet point and sometimes by simply saving, closing and reopening the SU file.
- There’s a rather complex method of calculating the optimum Light Cache subdivision parameters as they relate to the size of your actual render, but as a very rough rule of thumb I use 500 for most screen size (1400x800) renders and up to 1000 for higher quality or larger images. Anything over 1000 will start causing very slow LC build. That’s really a dummies’ guide to LC, search the forums for Dalomars detailed explanation of how LC is calculated. More importantly untick “Batch Render” under the “Global Switch” menu- it causes a very long delay in the LC build.
- No problem with using rect light and watts (though in the long term it might help to become more accustomed to using lumens as they’re the industry standard and are based on how the human eye actually perceives light rather than the rather abstract one joule per second Watt unit, which doesn’t actually describe light, but power. As a rule of thumb, a 100W bulb gives out approx 1200 Lumens.
http://en.wikipedia.org/wiki/Lumen\_(unit)
- This is the most important one! Matthieu Noblet created a free SU ruby script called “Remove C-G” which will take any material applied to the outside of groups and components and apply it directly to the geometry/faces. If you’re wondering what the hell I’m talking about think of car components which have materials applied to tyres, headlamps, bumper, etc, but which have SU’s default material applied to the bodywork so you can apply a material to the component and all the bodywork will be painted he new colour. The trouble with this SU method of working (although useful in SU) is that it makes it extremely difficult (read: slow) for VfSU to read the skp file. This is where Matthieu’s ruby script comes to the rescue. After running it you usually won’t actually see any difference to your skp file, but there will no longer be any default materials within your groups and components as all materials will be applied directly to geometry. Before running it some of my models had parse times of 20+ minutes, now all but the largest model will parse in less than 30 seconds. Be warned that the first time you run it in very large SU files it can take a long time to work and SU will hang while it does, but don’t worry, when it’s finished SU will spring back to life again. I use it many times a day on all my VfSU and can honestly say it’s the one most important thing you can do to dramatically speed up VfSU total render times.
Matthieu’s “Remove C-G” script can be found below.
I really should nag someone about making that topic sticky as it’s a must-have for VfSU users IMO.
Hope this helps,
Jackson