Hi Hugh, Did you saw this http://www.tweaksoftware.com/static/documentation/rv/current/html/rvnuke_help.html and I am pretty sure this current rvnuke package canbe easily convert to the way you need. I made this before.
Regards Kurian On Mon, Dec 12, 2011 at 5:28 PM, Hugh Macdonald <[email protected]>wrote: > ** > I'm not quite sure how RV deals with it, but I know it's possible. I don't > think it's necessarily direct streaming of image data (although this may > well be possible) - it's more calling a trigger to get it to insert an > image that's on disk. > > > Hugh > > > On 12/12/11 11:40, Thorsten Kaufmann wrote: > > I was wondering already if it maybe was an option to have a way of > "reload triggering" in case direct piping is not possible**** > > in certain applications. I take it RV supports direct streaming of image > data via pipes? Or was i over-interpreting there?**** > > ** ** > ------------------------------ > > Thorsten Kaufmann**** > > Head of Production**** > > ** ** > > MACKEVISION**** > > Medien Design GmbH, Stuttgart**** > > Forststrasse 7**** > > 70174 Stuttgart**** > > Tel: +49 (0) 711-933048-0**** > > Fax: +49 (0) 711-933048-90**** > > ** ** > > [email protected]**** > > www.mackevision.de**** > > ** ** > > Geschäftsführer: Armin Pohl, Joachim Lincke**** > > HRB 243735 Amtsgericht Stuttgart**** > > ** ** > > *Von:* [email protected] [ > mailto:[email protected]<[email protected]>] > *Im Auftrag von *Hugh Macdonald > *Gesendet:* Montag, 12. Dezember 2011 12:21 > *An:* [email protected] > *Betreff:* Re: [Nuke-python] Flipbooking**** > > ** ** > > It would certainly be a plugin-based system, similar to the current one, > so it would be straight-forward enough to write new plugins for different > playback applications, and any of this would be do-able, provided the > application supports piping images once it's already open. > > > Hugh > > On 12/12/11 11:15, Thorsten Kaufmann wrote: **** > > Hey Hugh,**** > > **** > > without going too much into detail (lack the time right now, will try > later today) I love the idea. Even tho we are not on RV i would still love > **** > > to see something like that! **** > > **** > > Regards,**** > > Thorsten**** > > **** > > **** > ------------------------------ > > Thorsten Kaufmann**** > > Head of Production**** > > **** > > MACKEVISION**** > > Medien Design GmbH, Stuttgart**** > > Forststrasse 7**** > > 70174 Stuttgart**** > > Tel: +49 (0) 711-933048-0**** > > Fax: +49 (0) 711-933048-90**** > > **** > > [email protected]**** > > www.mackevision.de**** > > **** > > Geschäftsführer: Armin Pohl, Joachim Lincke**** > > HRB 243735 Amtsgericht Stuttgart**** > > **** > > *Von:* [email protected] [ > mailto:[email protected]<[email protected]>] > *Im Auftrag von *Hugh Macdonald > *Gesendet:* Montag, 12. Dezember 2011 11:55 > *An:* PYTHON (nuke) discussion > *Betreff:* [Nuke-python] Flipbooking**** > > **** > > Hi all, > > I was looking, over the weekend, at using RV as a flipbooker. There are a > few things that I'd like to be able to do with it that don't seem to be > supported by the current flipbooking implementation. > > As such, I'm looking to write a new subclass of FlipbookDialog that > supports a different FlipbookApplication API, giving more options to the > Application class. > > > There are two features that I'd like to support: > > * Supporting standard render callbacks in the FlipbookApplication class. > beforeRender, beforeFrameRender, afterFrameRender and afterRender. > * Supporting reordering on the frames to be rendered. So frames 1-100 > could be rendered in the order: 1,100,50,25,75,etc, or reversed, etc > > > With this, what I'd like to do with RV is write a new FlipbookApplication > class that starts up RV at the start of a flipbook render, and passes in > each frame as it renders. This would enable Shake-style flipbooking where > you can view the rendered sequence as you go, and it keeps adding new > frames to the end. With the frame reordering, it would allow flipbooks to > start RV and then fill in the frames, meaning that, after half the range is > done, it'll already have every other frame. This will allow artists to spot > issues with their comps far earlier - if there is an issue at the end of a > render, it'll show up in the first few frames, rather than the artist > having to wait until the whole render is done. > > > What do people think of this? It's something that I'd like to do, and > would plan on releasing it to the wider world. It's something, though, that > I'm sure a lot of people would have opinions on, and would love to hear > what people think before I start on it. > > > Cheers > > Hugh Macdonald > *n**vizible** – **VISUAL EFFECTS* > > [email protected] > +44(0) 20 3167 3860 > > www.nvizible.com **** > > ** ** > > ** ** > > _______________________________________________**** > > Nuke-python mailing list**** > > [email protected], http://forums.thefoundry.co.uk/**** > > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python**** > > ** ** > > > _______________________________________________ > Nuke-python mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > -- --:: Kurian ::--
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
