@Musicvid - Enlightening Numbers! Thanks for doing the testing and your conclusions, made me think of the following.
O....K..... Wild idea here. Instead of going to using a standard or recipe Template for PreRendering, how about using Frameserver to produce a PreRender? Yes I realise there’s the minor issue of FS being ephemeral or whatever, could FS be enlisted to be part of this PreRender/Previewing?
Guess I'm a bit confused by "PreRender". Do you mean a draft, perhaps low resolution render that can be done very quickly? If so, staying within Vegas is probably your best bet. Using the XDCAM format suggested by MusicVid is probably as fast as you can achieve.
This is a bit simplistic, but I think of rendering as a two-stage pipeline process. During the first stage, Vegas takes a frame from your source, applies whatever compositing and FX you might have and outputs a modified frame. The modified frame is then handed off to the Rendering stage using whatever format you choose to produce a final frame that can be viewed.
Of the two stages, the first is usually the most demanding for complex projects such as yours and take the most time and resources. As such, choosing a low resolution fast rendering GPU-supported codec is unlikely to save a great deal of time since most resources are being used during the first stage. In other words, the bottleneck is really in the processing that takes place during the first stage.
Nested projects do not shorten render time, at least for now. The purpose is to better structure and parallelize complex projects. If a fast render time is needed, they are not a good choice. That could change if pre-rendered subprojects are managed. Video proxies for the preview would make working much easier.
Especially for compositions with stills and generated media, rendering time noticeable increases. Then GPU and CPU are not effectively used. Unfortunately, a better hardware does not help here.
In a current FHD 50p project, I can see the drop in rendering speed from 55 (Video AVC) to 6-8 fps (simply stills) in those regions. If I render the subproject directly, then the rendering speed in these regions only drops to 30 fps. That is 4 times the speed.
@wwaag & @matthias-krutz - You both give me the Science behind this Nesting business. And I've inadvertedly "proved" this on my new MONSTA! Hmmm... but sadly understood. So, would it be fair of me to say that although Nested Projects are an excellent advantage to the ASSEMBLING of complex Sources from other Veggies, the PREVIEWING is always always going to be Hobbled by the processing streams created by the NESTING. Nesting will have its limitations, it woud appear I've unearthed this for myself sooner rather than later.
O...K... If the bottle neck is the serving of frames from the Child to Parent then that is the point that MAGIX should focus their attention. I've alreaady found and posted them a Nesting Bug, which they've recognised (where IS Nick?) maybe they could also deconstruct their QA to accomodate for better Previewing for the Parent? @VEGAS_EricD & @VEGASDerek!! 😉
I think Render Events might be a useful tool to explore.
You wrote: "the PREVIEWING is always always going to be Hobbled by the processing streams created by the NESTING".
It's more than that--it's previewing in general. Here's an example (perhaps extreme). This is the 4 sec intro that I use for some of my video projects.
The project consists of a still with a couple of glint Fx and a HitFilm Light Flare Fx. With my i8750 and Nvidia 1050ti card, I get the following render performance.
For CPU only during rendering: 2.38 fps.
For Nvenc rendering: 2.34 fps
In other words, there really isn't any appreciable difference since the Fx processing is so demanding. With Fx bypassed, the renders are 80 fps.
I learned something very interesting regarding preview performance. Here's a short clip of that project being previewed in V15. You'll note that when Best:Full is selected, the preview fps remains pretty constant at 2.5 fps. However, when Preview Auto is selected it begins at roughly 25 fps and gradually improves after a few iterations until it remains constant at full 59 fps. It's as if it somehow "learns". I have no idea what this means other than it's interesting and offers another vehicle for speculation.
"It's as if it somehow "learns"."
This might be because of a RAM buffering when frames are repeatedly displayed and this is one reason why I use high RAM preview settings most of the time (even if I don't use the RAM preview which is a different thing of course).
If your RAM preview value was not set to 0 (zero), do this and try if the playback still improves with each playback cicle.
I think with RAM set to higher values the length which could be buffered will encrease.
For this "learning" a sufficiently large RAM is needed. You can test it with Shift-B. I use this function for the preview at the cursor position, which can be called up with the Num 0 key. After a few passes the automatically selected area is appearing fluid. The time I set with Cursor preview duration on 2 or max. 4 seconds.
This function seems to be hardly used. The comma problem when entering the value, would have bothered many. It must be 2,000, not 2.000 as suggested.
Do any of you notice stutters or delays when playing back SHFT-B ram previews of transitions, text composites, etc?
My experiences with the Shift-B RAM preview are positive. It shows the right thing at the right time.
If there are still problems, such as on my laptop with Win 7, I have seen the cause in too little of free RAM. Prerequisite is sufficient free RAM, so Windows does not have to swap.
More critical is that sometimes wrong frames from the RAM preview (GPU??) are displayed, probably from previously "learned". These disappear only by deleting the preview with RAM 0.