Comparing render times between systems is futile unless the exact same veg file is used as a reference. Guarantee blk diesel's render times would jump dramitically if he used a median filter at the track level for example...etc....

Slow render times is a fact of life with Vegas...something you live with....
The paradox is---as you get better at using Vegas and use more and more plugins at your disposal, your render times will get longer.... :-)

There is a render test file available at the Sundance site, you can search this forum for "rendertest times."

Using it, Vegas 5 was 7 seconds faster for me. I'm on a 2.66 P4 with hyperthreading enabled.

You can get the file here:

Render test

and see other people's results here:

Test results

Also, this was discussed a few days ago here:

Render Times in V5

I don't think the new version is much faster, unless you use the network render feature.

A tip for faster renders is to always render to a different physical disk from where your media assets are stored.

This has been discussed on this forum more times than I care to remember. One would think that everyone is aware, by now, that render times are based upon a nearly countless number of variables, especially that which is in the timeline!

Why this tired, old issue brought up time and time again is beyond me.

J--

I record our church services each week and produce tapes and DVDs for our members. Therefore the video is approximately an hour long each week and it normally takes about an hour on my PC to render. I've got a P4 3Mhz, 1G RAM PC. The PC I had before my current one was a P4 1.8Mhz, 512 RAM and the same 1 hour video only took a little over 2 hours to render.

As mentioned earlier, I think it all has to do with what's on the timeline. The church video I produce is not complicated in that it contains only 2 video timelines and 1 audio.

Also, when I start the render process, I don't do anything else on the PC. I also make sure that no other applications are running. I just start the render process and leave it alone. Sometimes I reboot the PC before I render. I'm not saying this is the correct way to do things because you should be able to multitask. This is just the way I choose to do it.

Why this tired, old issue brought up time and time again is beyond me.

It keeps coming up because it is a major workflow issue. How much would you pay to get your rendering time reduced by 1/2? Also, people who are relatively new to editing just don't understand that some effects take a much longer time to create than others, and therefore are surprised when something takes ten times longer to render than did a previous project of similar length.

The new Vegas 5 network render feature is HUGE, and is the answer that should be given to most people asking this question: Use Network Render.

Hopefully a future release will permit network rendering to also be used for pre-renders.

I'm all up in the fact that the more plugins and transitions you use is a major factor.

i do think that when you have a file that has tons of stuff, a dual xeon on a 800meg bus would help in reduce rendering files.

and it really doesnt make any difference which codec[s] you use... all seem to take just as long to render..

John, at this time, I don't see how anyone could reduce my render by 50%. Time is money. At this point in my life, I have more time than I do money!

Having said that, I would be curious to know what the cost of network rendering would run (and I may not understand it correctly!).

J--

Ron, my understanding has been that the faster the CPUs get, the more things developers add to programs to use that processing power. So, in the end, it becomes moot.

As I said to John, my understanding could be flawed!

J--

"The paradox is---as you get better at using Vegas and use more and more plugins at your disposal, your render times will get longer.... :-) "

And thats the good news?

Always something to look forward to. It must be Monday! ;-)
Stardust

I know of a huge way to reduce my render times.

Okay, I'm cheating a bit, but I do a project in sections, and render finished sections on a background instance of Vegas. At least in my case, I'm always amazed just how much time I consume doing other things. Those otherwise idle CPU cycles are put to good use.

Fastere CPUs reduce rendering time. Double the speed, and you cut rendering time in half.

Yes, you may decide to add more effects, etc. as they become more available, but it least in my line of work, I have found that the simple stuff (cuts, dissolves) works best for most projects.

The key feature in Vegas 5 for reducing rendering time is the network render feature. I was going to try using it tonight, but I'm not going to get to it until tomorrow. This feature lets you use other computers on your network to render parts of a project, and then let your main computer stich the pieces together. If you have a DV AVI project with lots of effects, this feature can make a huge difference. If you have three computers on the network not doing anything, then you can potentially render your project is 25-30% of the time it would take on your one computer alone.

"Fastere CPUs reduce rendering time. Double the speed, and you cut rendering time in half."

John, I'm only repeating something I read in a computer magazine a few years ago. I may be remembering it incorrectly, too, but the thought is still the same... unless I misread it!

Anyway, as I recall it said, for example, if you have a 500mhz processor and then upgrade to a 1ghz processor, that doesn't mean that you'll see a 50% reduction in the processing time. It turned out to be a fraction's increase, considerably less than one would think.

"If you have three computers on the network not doing anything, then you can potentially render your project is 25-30% of the time it would take on your one computer alone."

Certainly! But how much would three computers cost!? Like I said, time is money, but right now most of us have a whole lot more time than money! Yes, network rendering is certainly viable, for many of us it simply isn't feasible.

One last thing... I was watching the "Bonus" feature on a DVD not too long ago for some cgi movie, and it showed a hugh room filled with 100s of Macs, shelf after shelf, row after row, all connected rendering this movie, whatever it was. Now for me, that was a sight to behold!

They went on to say that it was taking months for them to render certain scenes. So I can't get too worked up when someone complains about a few hours of rendering on their 60 minute video. ;o)

J--

I have three computers within a metre of each other, but I just haven't had the time to learn Network rendering, because rendering is not an issue for me - I have several projects going at once and I never wait for renders.

But, one day it might be, so I'd love to hear from SOMEONE who has conducted some Render farm tests with 2/3 computers, single or dual CPUs etc.

Another handy feature to have is the RenderQueue.js script.

Check the script forum for the download site.

You modify the script to tell it what folder to render to and what template to use, then you can render mulitple vegs in a row.

I set up 5 vegs to render overnight yesterday

Though I've been lurking here for a while, I'm using Vegas 4 for the first time. Since rendering is so slow, and when I have clients in the room, I'll probably have to use something else for editing.
Since I'm new to Vegas, I'm sure I'm missing something in the workflow, but simple dissolves (crossfades) and PIP's shouldn't take that long to render.

John

Yeah, i'd like to see some real benchmarks on this issue.

FYI, final cut isnt much faster on a large file, even with dual chipsets...

But, one day it might be, so I'd love to hear from SOMEONE who has conducted some Render farm tests with 2/3 computers, single or dual CPUs etc. PeterWright

and

Yeah, i'd like to see some real benchmarks on this issue. aress

Well, here are the results of one such benchmark test:

I took exactly two minutes of DV AVI footage, put it on the timeline, and used Pan/Crop and one keyframe to rotate the clip exactly 360 degrees during its two minute duration. This is a test anyone can duplicate, because it doesn't matter what the footage looks like.

I then rendered in Vegas 4.0d, then repeated the test in Vegas 5.0a (standalone), in Vegas 5.0a (undistributed network), and finally Vegas 5.0a (distributed network). If you aren't yet familiar with the network render terms, undistributed means that only one remote computer does the rendering, whereas distributed enlists the aid of every computer on the network that has a Vegas rendering client installed.

My local computer is a 2.8 GHz P4. The one remote computer that I used as a network renderer is a 1.5 GHz P4.

Here are the results:

Vegas 4.0d		 9:50

Vegas 5.0a local		 9:17

Vegas 5.0a undistributed	16:59

Vegas 5.0a distributed	 7:53

In this test, there was at least a minute additional time spent stitching the results back together. The 7:53 distributed result actually finished rendering after only 6:40. Sony could significantly improve these times if it let the stitching take place from one physical drive to another instead of all on the same physical drive. Things really slow down any time you have to both read and write intensively on the same drive. The ideal workflow would be:

1. Media files: Drive D:
2. Render segment files: Drive E
3. Target for stitched files: Drive D

This would ensure that all major file movements are from one physical drive to another, thus avoiding the slow down from reading and writing simultaneously on the same drive.

So, using one other computer that's about half as fast as your main computer results in 18% percent increase. John, can you try another test, where you add a segment of just straight DV and then another complex event?

Network rendering is intended to recognize which PC is the workhorse. My hypothesis is that the complex tasks would be done by the 2.8 Ghz and the 1.5 would handle the straigh DV.


Thanks, for the test.

feel free to check my math.

Good point about allowing segments to reside on a different physical
drive than the output.

Another approach might be to dedicate one process to stitching and
allow it to stitch "on-the-fly" as the others are rendering... as each
segment becomes available the stitcher would pick it up and append it
to the output file. This approach would especially be useful for MPEG
and WMV renders where encoding needs to occur during the stitching
process.

The workhorse would handle more of the complex tasks only in the sense
that it will complete segments faster than the slower machine(s) and, in
the end, it will handle more segments.

However, for example, say a 60 second project has 57 seconds of easy
work and a 3 second stretch of extremely complex work. It may just
turn out that the slow machine gets the complex segment and the fast
machine gets all or most of the easy segments.

Also, keep in mind that if, for example, you have a project with a lot
of unaltered DV footage and mainly cuts and/or simple fades between
clips, you're better off not using network rendering.

So, using one other computer that's about half as fast as your main computer results in 18% percent increase.

I did some computations, and the times pretty much make sense. The killer is the stitching overhead, and the slight lag (which I didn't mention) before the remote renderer is ready to go. If you convert time to rate ( 1 / time = rate ), you can add the rates of the slow render machine and the fast render machine. If you add these two rates, and then take the recipricol, you get the predicted time, with no overhead, of the two computers rendering simultaneously. However, there is close to a two minute overhead, mostly due to stitching, that reduces the effectiveness.. With more renderers, and with smarter stitching, this time could be reduced.