FORUMS: list search recent posts

Amazed at render mgmt - and a downside

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Bret Williams
Amazed at render mgmt - and a downside
on Mar 13, 2014 at 2:06:36 pm

This app never ceases to amaze me. I already knew that X was pretty amazing at render management. For example, if you render a section, then make a bunch of changes, but then decide to change even just a portion of something back to a previously rendered state, then X will simply return it to rendered. This was absolutely not possible in legacy, nor any other NLE I've seen. The only way to return something to a previously rendered state was to hit undo. If for example your rendered a stack of layers, then deleted a layer in the middle, then replaced it with an identical copy from the bin, any other app would require you rerender. But X simply says, "oh, we have a render in the cache that meets that criteria, lets use that."

So I already knew X could do that. Nice. But recently I had a long version and a short version of essentially the same sequence. Everything had been locked in and approved in the longer version before we began to cut it down to make the short version. But of course a lower 3rd needed to be changed. Instead of changing one and copying and pasting to the other sequence, it was just easier to retype them both. I retyped the first one and rendered. Then I retyped the second one, in a whole separate sequence, and the instant I was done typing, it was rendered! Just because it happened to have media exactly matching that render in the cache already. But not just a match of TC and file names, a match of the actual typed text too. Nice.

And another example. I duplicated an unrendered sequence today to create a new version. I finished the new version and rendered. The first version instantly recognized all the parts that were the same and it was now rendered too in those areas. That's efficiency. And pretty damn cool.

I think this new behavior (the 2nd two examples) is the result of an efficiency of having projects grouped into libraries. and Render media is associated with the library, not the project as in the past, so render media is shared. Previously if you duplicated a sequence, all the render media had to be duplicated or you could choose not to duplicate the render media. The two versions of projects never shared one single frame of rendered media. They were kept separate just as libraries don't share render media now.

A downside to this I've also discovered, is that X isn't smart enough when you delete render files. If you say to delete the render files for a sequence, it deletes all the render files for that sequence no questions asked. If those render files are shared by another sequence, then tough shmit. They're gone too. And duplicating a sequence doesn't duplicate the render files. In legacy, I do believe that it was smart enough not to delete the render files in a sequence that were also being used by another. But I could be mistaken.

Anyway, another huge benefit of Libraries.


Return to posts index

Herb Sevush
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 2:21:35 pm

[Bret Williams] "For example, if you render a section, then make a bunch of changes, but then decide to change even just a portion of something back to a previously rendered state, then X will simply return it to rendered. This was absolutely not possible in legacy, nor any other NLE I've seen."

Because you never used *edit.

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Bret Williams
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 2:27:02 pm

I have heard that about edit now that you mention it. I've used a lot of other NLEs over the past 20 years, but not edit*.

So is there a footnote or something? I was always looking at the bottom of the page to see what the catch was.


Return to posts index


Herb Sevush
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 2:52:30 pm

[Bret Williams] "So is there a footnote or something? "

No footnote, it's just that edit* was way ahead of anything like legacy when it came to rendering. Unlike legacy it intelligently rendered only what had to be rendered to effect actual visual changes to the timeline. And the new renders had their own "track" on top of the timeline.

Mow it's been 10 years since it was EOL'd but I believe the renders came in layers, and could be deleted to re-reveal old renders underneath. It wasn't automatic, but if you wanted to restore something in the middle of a long and complex render it only took a moment to accomplish. At least this is the way I remember it. Hopefully another old edit*or can come on and confirm or deny.

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Bret Williams
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:07:19 pm

Ah, one of those. I'm sure it was great, but I was never a fan of that. I used two other systems that did that. The video sphere, which was essentially a multilayered version of the immix video cube. It had all this layering and RT capability, but to render, you had to tell it to compound a section into a clip and then you placed that clip back into the timeline. Usually at the very top of the stack. But it was a manual process. And that render file had no management. It knew not where it came from or how to recreate it or redigitize it, etc. Ridiculous design.

And I used editDV at home when I was a freelance Avid editor because FCP wasn't out yet, and I could bring home DV copies of my work and make demo reels. I did a few little projects on it, but then FCP 1 came out and I made the switch. But editDV had a render track up at the top. And it was kinda up to the user to mentally keep up with what needed to be rerendered or not. The track, while better that the sphere solution, still knew not where it came from or if changes had been made beneath it. Not a fan of that one either, but it was useable. Hopefully edit* was a bit more advanced.


Return to posts index

Herb Sevush
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:27:40 pm

[Bret Williams] "Hopefully edit* was a bit more advanced."

edit* started out as D/Vision, which, along with EMC, was the best PC NLE editor in the 90's. It was re-written for windows and then bought up by Discreet Logic, who wanted it to compete with Avid as an off-line editor to feed into the whole Smoke, Fire on-line system. This was viewed as a great move by D/Vision-for-windows users but was a nightmare, starting with the ill conceived name change to "edit*". the problem from Discreet's point of view was that it was too good - it was not only feeding into Smoke, it was, when combined with Combustion, beating the pants off it for a fifth of the price. It was easily the finest NLE I have ever worked with, although primitive by today's standards, and superior to Avid in almost every way at the time, but not nearly as well known. When Autodesk bought up discreet, edit* became the victim of corporate infanticide, and I eventually moved on to FCP, a move that to this day I think of as a lateral, as opposed to upward, progression.

So yes, I think it was a bit more advanced than editDV.

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index


Bret Williams
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:41:45 pm

I just meant the render management. Not the whole app! EditDV, was just a cute little NLE that mimicked Avid's layout, but none of the functionality like FCP legacy did. I'd hope that edit was light years ahead!

EditDV did have only a couple things I missed when I got FCP. You could digitize in time lapse off of tape. You could tell it to capture every Nth frame. Capture every 3rd frame, or every 100th frame, etc. So great when drive space was a premium and someone shot for an hour and you wanted it to take 30 seconds.

It also output to the client monitor frame by frame as it rendered. So the instant there was a screwup in your composite, you'd see it. After effects can do this and I thought Avid could too. Very useful.


Return to posts index

Michael Hancock
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 2:36:33 pm

Avid does it too under most circumstances. If you render a sequence, move stuff around, then move media back to where it was when you rendered the render relinks. FCPX seems to do it under more circumstances, though (removing a lower third and cutting it back in from the original i your bin doesn't relink to the render file in Avid, and rendering one sequence doesn't result in a secondary sequence being rendered).

----------------
Michael Hancock
Editor


Return to posts index

Walter Soyka
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 2:47:01 pm

[Michael Hancock] "Avid does it too under most circumstances."

As did Avid DS.

It's not an NLE, but the render cache in Ae CS6 and up caches footage and rendered effects on a per-layer basis, and matches them back according to source, properties, and effects. If you use the same effects on the same footage in two separate projects, it need only be rendered once.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index


Daniel Frome
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:03:52 pm

Avid can do this too... only in the far opposite direction: it doesn`t, ever, want to delete those render files. If you `clear renders`they are kept on disk... just not available anymore. If you actually want to delete them you need to use the media tool. End of rant.


Return to posts index

Bret Williams
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:00:01 pm

What I loved about Avid (and it's been a good 10 years) was DESTRUCTIVE compositing. Destructive compositing is a wonderful thing. FCP always made it out that they had "non-destructive" compositing. Which just meant, it's gonna take one helluva long time to rerender that, just because you added a bug to the top layer.

In Avid I could render a stack of stuff, and then add a new layer on top, and it used the render file as a single source. You wouldn't even need to render they new addition because it could certainly play in rt with the lower stack.

Yes, you could continue on in this method rendering each layer as you go and the image got softer and softer. But it's better than working in some low res mode. And when you're done, you deleted the render files and rendered it all ONCE as non-destructive.

Destructive compositing would be a welcome addition to FCP X for me.


Return to posts index

Santiago Martí
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:23:28 pm

[Herb Sevush] "[Bret Williams] "For example, if you render a section, then make a bunch of changes, but then decide to change even just a portion of something back to a previously rendered state, then X will simply return it to rendered. This was absolutely not possible in legacy, nor any other NLE I've seen.""

If I understand well what you are saying, PPro CC works in the same way.

Santiago Martí
http://www.robotrojo.com.ar
Red One M-X, Red Epic X waiting for Dragon update, Red Pro Primes, Adobe CC, Assimilate Scratch


Return to posts index


Bret Williams
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:35:24 pm

That's great if it does. I used PremiereCC on a render heavy thing this fall and didn't notice this behavior, but kudos if it does. It should.

So maybe the only app that still stinks in this regard is FCP legacy. As well it should. It's a 5 year old app. As I've said before, one may not like FCP X, but if you're still using FCP legacy, geez it's time to move on to something else. Pick one. Of course this is a broad based generalization and I'm sure there are perfectly good reasons to still use FCP 7. But not 6. Can we all agree that FCP 6 is done? :)


Return to posts index

Bret Williams
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 3:30:41 pm

In looking deeper into the library bundle, I think the render files are actually attributed to events, not the Library. Within the library is a folder for each event, and within that a folder for each project, as well as a separate folder for render files. So the render files reside outside of the project, but within the event. My guess is that if you put your duplicate sequence into a different event within the same library, this new render file efficiency would be lost and each would have it's own render cache within that event. But I haven't tested it nor plan to. I don't know why anyone would have separate versions of a project in separate events anyway, but some seem to use events more as organizational bins than others. I tend to have an event for sequences, and an event for media. But even that could be accomplished with folders and keywords.


Return to posts index

Brian Mulligan
Re: Amazed at render mgmt - and a downside
on Mar 13, 2014 at 7:51:50 pm

Autodesk Smoke also has great render management. Frame based rendering, change, undo back to rendered.

Brian Mulligan
Senior Editor - Autodesk Smoke
WTHR-TV Indianapolis,IN, USA
Twitter: @bkmeditor


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]