Hello,
Does anyone know how to setup Nuke to detect my custom renderman shaders saved
in:
$HOME/nuke/shaders
Tried adding it to my nuke.pluginPath() without success.
Thanks in advance.
T
Frank Rueter|OHUfx <[email protected]> wrote:
>Too much room for error when reading R3d in directly, not to mention the
>speed hit due to de-bayering and full resolution as mentioned before.
>I totally agree that transcoding everything to dpx files is the way to
>go. This will give you:
>
> 1. full control over how the transcode happens across the show (gamma
> space, priamries etc)
> 2. much superior speed in Nuke due to having uncompressed rgb channels
> to load and only having to deal with the resolution that is actually
> required (especially if you shot on 8k and only need to deliver
> regular DCP or hd resolutions)
>
>
>
>
>On 19/09/14 11:17 am, John Coldrick wrote:
>> Cool, thanks for the feedback guys. The speed hit seems like a no-fly...
>>
>> Cheers,
>>
>> J.C.
>>
>> On Thu, Sep 18, 2014 at 6:41 PM, Nathan Rusch
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> R3D's are going to be slow because they need to be debayered.
>> You're also looking at more room for error by exposing all of the
>> debayer settings to the artist, and more room for instability by
>> getting third-party libraries involved.
>> I would stick with DPXs.
>> -Nathan
>>
>> *From:* John Coldrick <mailto:[email protected]>
>> *Sent:* Thursday, September 18, 2014 3:01 PM
>> *To:* Nuke user discussion
>> <mailto:[email protected]>
>> *Subject:* [Nuke-users] R3D "Live" source plates in Nuke
>> In the past we had experimented using quicktime files directly in
>> Nuke as source plates and it was pretty much a disaster,
>> unstable, inexplicitly slow at times, and checking around that was
>> a concession from a number of shops. Fine in theory, seemed OK,
>> but inevitably when you got to a real shot, trouble.
>> I'm just curious if anyone has had any experience with using R3D
>> files like this. We'd be working at 4K from a Red Dragon, I'm
>> thinking on the plus side the compression would make for faster
>> interaction, but potentially on the negative side some of the
>> snappy scanline efficiencies might be lost, and of course,
>> stability is key. I've also noticed that the firmware in the
>> camera can be a real issue in getting successful reads in Nuke, so
>> there's a thing...
>> We're going to do some testing, but just curious if anyone had any
>> war stories.
>> Thanks in advance!
>> J.C.
>>
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Nuke-users mailing list
>> [email protected]
>> <mailto:[email protected]>,
>> http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>> _______________________________________________
>> Nuke-users mailing list
>> [email protected]
>> <mailto:[email protected]>,
>> http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>>
>>
>>
>> _______________________________________________
>> Nuke-users mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
>--
>ohufxLogo 50x50 <http://www.ohufx.com> *vfx compositing
><http://ohufx.com/index.php/vfx-compositing> | *workflow customisation
>and consulting <http://ohufx.com/index.php/vfx-customising>* *
>
>
>_______________________________________________
>Nuke-users mailing list
>[email protected], http://forums.thefoundry.co.uk/
>http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
