Why is 1.0074 so much slower?

[teya]

Re: Why is 1.0074 so much slower?

Hy!
I've been having some troubles too with the rendering times.
Just to give you all the data about my problems:
- i use v-ray settings allready made, since i am no genius, and i don't really understand how all those settings work. I only change the focal lenght, to get a wider view of the rooms i'm creating
- i apply materials to the geometry, but i also have components inside components. can this cause the major delaying time?
- i choose to use components instead of groups because there have been cases before when groups disapeared from the scene
- i've tried all the settings i could find for interior scenes, and the problem seams to be the long "building light cache" time (very very very long time)
- i've been using the new rectangular lights (with the "watts" options), hoping to get closer to the real life parameters. What do you recomend?
- another strange thing....in scense with few materials (like a bathroom - 4-6 materials) things are fine, but in scene a little more complex (like a small livingroom 10-15 material)things just slow down so much that i had to use some settings that were dedicated for the exterios scenes (i think)just to get some renderings in time.
- i do small pictures, like 800X600
- i don't have great expectations from my scenes, i just want it to work like it did before. the rest is up to me.

PS. I've been reading posts on this forum, but i don't seem to find the answers i need. I hope to get some good, short advices.

[thomthom]

Re: Why is 1.0074 so much slower?

There could be any number of things to why things takes time. I think your best bet would be to make a post with specific questions to your specific models. With screenshots and info on your settings.

Also, the latest version is now 1.05.30. Is that the one you use, or do you use 1.00.74 which this thread refers to?

In regards to Watts: 60W V-Ray light doesn't equal to a lightbulb or lamp of 60W. Instead it's actual Watts emitted, which is much lower. When I tried to approximate existing lights I had more luck getting the lumens info and matching that unit in V-Ray.

[Jackson_cg]

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.

http://asgvis.com/index.php?option=c...29118#msg29118

I really should nag someone about making that topic sticky as it's a must-have for VfSU users IMO.

Hope this helps,
Jackson

[teya]

Re: Why is 1.0074 so much slower?

First of all, Thank you so much for your answers!
I will try to follow your advices and make things work properly.
As you can probably tell, english is not my native language, so it's hard for me sometimes to follow all the post on the forum to find the solutions for my problems, but i do my best!
Thanks again!

[thomthom]

Re: Why is 1.0074 so much slower?

- 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.

Do yiou actually notice a speed difference between using groups vs components?
I would find this very odd as internally, groups are defines exactly like components. The only difference is a flag that tells they are groups so whenever you edit a group copy it's made unique. In ruby they are accessed from the same collection of 'definitions' as components. And when you copy a group around without editing it you see it has instances just like components.

[Jackson_cg]

Re: Why is 1.0074 so much slower?

Thom,

I've run tests with 2 skp files, one with 1000 components and another with 1000 identical groups and they both parsed in 12 seconds, but my advice was based Damien's advice that the way SU handles components and components within components causes problems with VfSU.

And when you copy a group around without editing it you see it has instances just like components.

That's interesting... so it would seem SU components (as opposed to groups) aren't as problematic as I thought.

[thomthom]

Re: Why is 1.0074 so much slower?

From what I understood, and looking at the SU API, I think it's not specifically "components nested in components", but "components/groups nested in components/groups". Seeing how they are pretty much the same. But it's odd that only groups disappear. Maybe it has to do with it's unique property.

As for group copies, I have made a plugin which can convert groups with identical copies into components. For them times you end up with a file where someone has used groups instead of components for repeating elements.