Depending on the machine, I've got up to 5 gigs. Most machines are 2, but I have 2-5 gig machines.
I use RAM renders religiously, because unlike pre-renders, RAM renders hold on to everything except for the changed areas. So, if you have 200 keyframes and adjust #'s 49-70, Vegas will remember everything before and after 48 and 71. Very useful for me.
Of course, if you are doing a lot with Boris or Satish's tools, you have to turn RAM use to 0. But I use Boris more standalone than as plugged, and haven't been working with Satish's tools as much (yet) since beta testing 5. I'm excited to see the next WAX.

I also love the Ram preview. To Wax and the need to zero the Ram buffer - maybe this is worth to make a script with an individual adjustment. So it would us take only a keystroke to set Ram buffer to zero and another one to have it back to a preset value!?

Marco

I love the RAM preview too. :) Honestly, if you oculd still make RAM drives on your computer, i'd macx out my RAM & put a 1gb RAM drive to use for temp files while editing. :)

Anyway, I used the Boris demo. Afer using it for a couple days I switch to the standalone version: your render times decreas quite a bit when it's not loaded into Vegas (even when Vegas is open, same with WAX i've noticed to).

:)

(yes, I'd like better prerender management too, but I'd fill my system up and waste a lot of time without RAM renders)

Yes, that'd be the drawback of more agressive prerendering. You may as well devote a disk to it if Vegas were to start background prerendering sections of the timeline, individual clips, individual events, nested veg files, and nested acid files.

Curently Vegas can only prerender sections of the timeline. Saves space but of course if you change the timeline the prerender is gone in that region.

I don't think any amount of prerendering can take the place of ram previews-except for a total render, of course.

Rob Mack

I agree with the fact that the prerender management needs to be (dramatically) improved but… Do you guys know that one second of RAM render (at full resolution) eats up around 40 MB of RAM and a HD pre-render uses less than 4 MB of HD space at the same resolution? Come on... HD space is dirty cheap when compared to RAM. RAM preview has its space but what most of us really need is background rendering. Think of it… while you continue to click away (etc.) your project is automatically being rendered without disturbing your work (and without the need of “Shift+M” or “Shift+B” key strokes). Before anyone jumps in telling me to open a 2nd instance of Vegas and render by sections… I just want you to know that although I consider it very useful, on this matter; it is simply a workaround and believe me when I say that I am fed up with workarounds! If you are afraid to fill up your HD with those automatic prerenders just switch the background rendering off (under “Options/Preferences”, I hope), buy bigger HD’s or put a shortcut (to the prerender folder) on your desktop to delete the files when they become an issue.

I agree and disagree. RAM renders are faster, and I prefer them. I don't like the small files cluttering, and I don't like dealing with them in comps. That's what RAM render is for. Background rendering would be great too. But I can't see the point in mixing the two together. Perhaps if background rendering had intelligence so that it deleted files when the same section was rendered again...but that's my opinion only. I'd have literally a thousand or more prerender files after an hour's session.
When you're comping 40 tracks-deep sections, rendering to disk makes zero sense to me, because I'm only rendering to see it at full frame rate, usually only a few seconds worth of vid to see dozens of keyframe changes that will only playback at framerates of 3-5 fps on a very fast and tweaked system.
Since RAM rendering is very fast, I prefer it for this work. Background rendering on long, deep projects would be great too. But they're separate issues/features in my mind.

Spot, before answering you let me correct my previous statement so when I wrote: "...what most of us really need is...¨ I meant to say "...what most of us also need is...¨
Although I did not intended to imply that one would replace the other; I think of it this way (short version):
Humans reactions are slow when compared to computers following well written instructions/code so, in optimum conditions (...), by the time you're ready to hit "shift+B" the application already thought of it for you and is happily rendering or, depending of the task complexity, has already finished the rendering and is ready for full resolution playback (...).
As for background rendering intelligence: I agree with you but only to a certain level, because those little files can be extremely useful. If background rendering is coupled with a good prerender management routine and if later on we realize that we made a mistake and want to undo something... a full resolution file is already there waiting for us.

I'd go along with that. :-) Each of us has our own workflow, and that's the true attraction of Vegas...so many ways to accomplish the same goal.

Background rendering would complement RAM previews transparently. Essentially, if it plays back fine then you aren't going to do a RAM preview.

As to what gets rendered, you might want yet another control panel. It would offer yes/no checkboxes to background render:

Media FX
Event level FX
Nested Veg files
Nested Acid programs
Nested tracks
Audio FX at media and event levels

You'd also have to specify where to put all this stuff. Users may just want a separate partition or disk for it all. Maybe users also need a setting for the amount of space these files can be allowed to take up-ala system restore or IE cached pages.

And you'd have to choose the render formats. Uncompressed is good but maybe some near-lossless compressed format would be better for video. Photo JPEG comes to mind. Audio needs to be lossless.

Media in the pool and events on the timeline would get the same prerender marker bar as the timeline gets-but shown in the thumbnail (could get messy-probably should be in the same space as the active take name gets shown)

Finally, Media clips in the pool and events in the timeline should have a prerender command in their context menus. This would override any project settings.

It seems to me that background prerendering is no small task to program. Also seems like it demands more hardware from users-more disk space and a dual processor setup. Perhaps Intel's next line of CPUs (supposed to have dual physical processors on the same chip-probably next year) would make this work on laptops as well.

Rob Mack

Rob I agree that having a few selection boxes may eventually be needed/welcome because as Spot said "Each of us has our own workflow...” Regarding dual processors, they should not be a requirement because, when programmed right, it is simply a matter of task priority. I do it all the time with, for example, the windows XP task manager. :-)

Ram previews are fine and dandy but the lack of intelligent prerendered media management is the single issue for me that ruins vegas in my eyes. Vegas has a lot of things going for it but without intelligent prerendered media management, an editor most rerender too often, usually rerendering the same file more than once because triming the file or moving the clip ruins the prerendered connection, and defaults it back to unrendered state. This creates far too much "double" work.

Premiere Pro and Avid Express PRO are so good at this, and Vegas really lacks in this reguard. But we all know this. Luckily... Vegas has a lot of nice features that put it above the competition in other areas.... BUT the lack of prerender mangement is a workflow breaking point in vegas.

Frankly as a 3d artist.... I find the new 3d tools difficult to work with, and i would have rather seen better prerendered management in vegas first.

Some advice for the 3d tools in vegas... X Y Z axis should be represented in the standard R G B colors. Right now its a head ache to read that silly transformm manipulator.

Also am i missing something... Because nested FX tracks do not move together in a parent/child manner. If i move a clip on the parent track... the clip on the child track doesnt move with it (unless i group it of course.)

>>> X Y Z axis should be represented in the standard R G B colors. <<<
Agreed, absolutely. Reading the axis indicators against the white is hard enough, not having the grey or black background, RGB would be much easier to see, with or without the grey or dark background I loved so much before.

"Don'tcha just love....how Vegas renders to RAM on the fly?"

THIS is the function I use the most. Why?
This is the most usefull function. Why?
This function is soooo usefull...

... etcetera... repeat as desired...

No, DP shouldn't be required. But it should make background rendering totally transparent. The goal would have to be to make sure that background rendering never impacts the editor's workflow. Yeah, you can start with controlling the process priority (programatically-not manually) and making sure it's only done in idle moments. But what I'm sugesting could create a lot more render load than anyone is seeing now. I can easily imagine that my scheme here would create 10x as many prerenders as we currently create. Not only is it 10x the disk space, it's 10x the CPU cycles.

10x is a wild guess. If you had all my little checkboxes ticked maybe you'd end up with 100x the normal prerenders, I don't know. It's just easy to imagine background renders becoming pointless if the system can't transparently keep up with the editor. Then it becomes a buglike feature.

Rob Mack

Yes, indeed! Sometimes I set things to loop while I think about them. It's kind of meditative to watch the playback improve. Or maybe I'll say to someone nearby, "come take a look". By the time they get there it's playing well enough for them to be impressed or bored or to pat me on the head and say "that's nice, Rob".

Rob Mack