Thanks, Chienworks. I understand that you have had a similar experience before.

To me it is *not* a complicated project, bearing in mind that I am not stretching the capabilities of VV3. After all, it is publicized as handling an "infinite" (?) number of tracks. And I am not using that many load of FX.

*And* I am careful enough not to have more that 3 or 4 images at the same time. They spread out through the 12 layers, but no more that 3 or 4 in one given moment.
If I have many tracks but I am not using all of them at once, it does *not* require CPU time, right ?

I am wondering if the reason for long rendering time might be having that Track Motion "thing" that forces the renderer to re-evaluate each frame of the track based on the motion keyframing. Or even the resample/de-flicker setting ...

Now, just imagine that I have this "scene" as part of a much bigger movie, where nothing fancy happens. I mean, I have 12 tracks but 95% of the time they are empty.
Will I have long rendering for the *entire* project ?
You will tell me to do this in a separate project, but it may be spreaded out and be almost impossible to isolate ...

Thanks for your thoughts ...

(p.s.: hey, I'm not of English culture. "culprit" is not a right word ???)

Culprit - Noun - One accused of or charged with a crime.

It seems it is complex with regards to the limited system you have. Today a 800 Mhz system simply don't cut it (speed wise) when you expect it do to heavy duty work like you are expecting. So, the problem is mostly you hardware, not the Vegas software.

So called "reasonable" time is relative to what your asking Vegas to do and what kind of computer you have to do it with. Twelve video tracks, filled with 24-bit images of good size, with lots of switches turned on IS asking a lot. Not that Vegas can't do it, it can, but it will take time as you've discovered for it to render.

One thing you might one to try is as a first step reduce the color depth of your images. Sounds like overkill for making a MPEG.

Both track motion and the HSL filter are major render hogs. If you play your project and mute tracks or filters, the FPS display in the preview window will show you what's causing the biggest hit. I think there is some room for major improvements in track motion.
If you can use one track and pan/crop for your project, you should see a hugh difference.

Craig H.

Hmmm, all of the above may be true, however I have had a similar problem. (PAL)
I had a project and for some reason it took forever to render, like about 30~60 seconds per frame, nothing super special in regards to FX etc, relative to other projects I have done it was incredibly slow.
I spend ages testing my PC and trying to find the slow down problem, thinking it was my PC.
I eventually decided the Veg file must be corrupt in some way or something I had done was the killer, so I dumped the lot and started from a new project again, rebuilding and testing bit by bit. I eventually got back to the finished project and it rendered at about normal speed. I put it sown to a screwed Veg file. Have never seen it again, just the once!

DrWho, the beginning of your story is like my story, but not the end.
I am used to corrupted VEGs, so I usually do different saves at project intervals (5min) but this is a 1min project ...

So, yesterday I decided to give it a new try with the same pics but a new veg project.

My first assessments (some of them pretty obvious):
- changing the format is bad: my source is 16:9 and I want my output to be 4:3 letterboxed.
- resample is bad.
- track motion is quite ok. Pan/Crop is quite ok.
- HSL is so-so.
- color depth of stills is important (16-bit must be faster than 24-bit, but I am working with high-detail PNG, not MPG).
- number of superimposed tracks (filled with something) is important. After the 5th superimposed event it lags ...
- Render quality is *very* important: Best is 5 times longer than Good.

So, the laydown so far (and the culprit): change render quality from Best to Good, pre-render those images that are going to have a different proportion in the output, resample only if necessary.

I am not very unhappy with my machine (considering that my first PC was a 4MHz, and my next one is going to be a 3.2 GHz... when prices go down) and as I said I have had "decent" rendering times on other situations.
OK, it takes 8 hours to render something instead of 5 hours. So, I'll go to sleep 8 hours straight instead of 5 :-). Like Chienworks wrote, we don't speed up things by looking at them.

I read somewhere in this Forum a discussion between Good and Best Rendering option, but I can't find it anymore. I am working with high-detail pictures so I naturally went to Best Rendering (the manual says: go to Best when only the best will do). To be fair, I do not see a significant improvement between Good and Best, and the payback is 5 times more rendering time.

Which makes me wonder ? Anybody uses Best ?

I don't really have a helpful reply :) but for comparison I've been working on a project that's currently about 45 minutes, maybe 20 of which is entirely high resolution (some 2000x3000 with zoom, panning, rotation) 24-bit PNGs typically displayed for 5 to 10 seconds. The remaining time is DV with some occasional color correction or FX. I only have three video tracks and about six audio tracks.

I've set re-sample and de-interlace on all the stills and it takes about 12 hours to render at the best setting on a P4 1.8 with 1.5 GB RAM. I start it pre-rendering before going to bed and pick up where I left off when I get home from work.

- Jason

Jason, in 12 hours I would do 3 minutes of my movie (!!!) You do 45.
God Job on the 1.5 GiG RAM, even though someone wrote here in the past that RAM is not the name of the game with Vegas. CPU juice is.
The most important difference (besides having a CPU more than twice as strong as mine) is having only 3 video tracks (4 times less than me)
Because these things are not proportional it might explain the difference (45 minutes vs 3 minutes, in 12-hour work).
DrWho made the right remark: waiting 30-60 sec for *each* frame is more that I can bear ...

If you haven't already seen, over on the COW (http://www.creativecow.net/index.php?forumid=24) DSE has posted a small test .veg file to compare render speeds. Several people have rendered the file and posted their time and machine specs.

- Jason