> *Von:* nuke-users-boun...@support.thefoundry.co.uk <
> nuke-users-boun...@support.thefoundry.co.uk> im Auftrag von Nathan Rusch <
> nathan_ru...@hotmail.com>
> *Gesendet:* Montag, 14. September 2015 19:26
> *An:* Johannes Hezer; Nuke user disc
net/mackevision>.
Von: nuke-users-boun...@support.thefoundry.co.uk
<nuke-users-boun...@support.thefoundry.co.uk> im Auftrag von Nathan Rusch
<nathan_ru...@hotmail.com>
Gesendet: Montag, 14. September 2015 19:26
An: Johannes Hezer; Nuke user discussion
Betreff: Re: [Nuke-users]
How many files are too many? Just curious
Den 14 sep 2015 08:30 skrev "Daniel Hartlehnert" :
>
> Am 13.09.2015 um 11:04 schrieb Johannes Hezer:
>
>
> As we are under Windows I never want to run into the "too many open files"
> error again.
>
>
> Just a side note: i experienced the
Am 13.09.2015 um 11:04 schrieb Johannes Hezer:
>
> As we are under Windows I never want to run into the "too many open files"
> error again.
Just a side note: i experienced the "too many open files" error on linux as
well.___
Nuke-users mailing list
I am not sure, i think its depending on the filesystem anyway, and not on the
OS. Keep in mind, that for every time operation (time offset, retime, oflow
etc.) every read node upstream is counted twice ( as in two open files instead
of one).
Am 14.09.2015 um 09:39 schrieb Elias Ericsson
On windows I ran into this with 200-300 read nodes (too many layers and a lot of aovs)As mentioned retimes etc increase the file handles too.I think the per app file handle limit on windows was around 512 ?!On Linux you can change that and set it to 8192 and never have that problem
I think the number was, on win, 1024 data accesses.
Am 14.09.2015 um 10:24 schrieb Daniel Hartlehnert:
I am not sure, i think its depending on the filesystem anyway, and not
on the OS. Keep in mind, that for every time operation (time offset,
retime, oflow etc.) every read node upstream is
uftrag
von Howard Jones <mrhowardjo...@yahoo.com
<mailto:mrhowardjo...@yahoo.com>>
*Gesendet:* Samstag, 12. September 2015 11:07
*An:* Nuke user discussion
*Betreff:* Re: [Nuke-users] Multipart multichannel exrs vs.
separate exrs
That is a good point about whi
s://www.behance.net/mackevision>.
> --
> *Von:* nuke-users-boun...@support.thefoundry.co.uk <
> nuke-users-boun...@support.thefoundry.co.uk> im Auftrag von Howard Jones <
> mrhowardjo...@yahoo.com>
> *Gesendet:* Samstag, 12. September 2015 11:0
s* introduce its own form of overhead, but it's still almost
always the better option.
From: Randy Little<mailto:randyslit...@gmail.com>
Sent: Friday, September 11, 2015 4:29 PM
To: Nuke user discussion<mailto:nuke-users@support.thefoundry.co.uk>
Subject: Re: [Nuke-users] Multip
gt;> Yup, and that's part of what I said. I just wanted to point out that
>>> multiple file sequences *does* introduce its own form of overhead, but it's
>>> still almost always the better option.
>>>
>>>
>>> From: Randy Little
>>> Se
t's
>> still almost always the better option.
>>
>>
>> *From:* Randy Little <randyslit...@gmail.com>
>> *Sent:* Friday, September 11, 2015 4:29 PM
>> *To:* Nuke user discussion <nuke-users@support.thefoundry.co.uk>
>> *Subject:* Re: [Nuke-users] M
Hey everyone,
A bit of a survey question... Is anyone using multipart exrs ?
We have been using them for 2 projects and we have not done any performance
profiling, but I am not 100% sure if it is a speed bost or not, compared to
multichannel 1.xxx exrs.
I was hoping might come close to
n: nuke-users-boun...@support.thefoundry.co.uk
<nuke-users-boun...@support.thefoundry.co.uk> im Auftrag von Randy Little
<randyslit...@gmail.com>
Gesendet: Freitag, 11. September 2015 22:06
An: Nuke user discussion
Betreff: Re: [Nuke-users] Multipart multichannel exrs vs. separate exrs
big huge all passes i
big huge all passes in a exr is slow. Has to read entire file (75MB+) to
find the channel you want that might be 200KB every single time you want to
deal with that little mask channel. They also seem to take longer to
render out of 3d. We usually break them up by math type and try not to
access to different parts in the same file.
-Nathan
From: Randy Little
Sent: Friday, September 11, 2015 2:57 PM
To: Nuke user discussion
Subject: Re: [Nuke-users] Multipart multichannel exrs vs. separate exrs
Has to load the file to read it always. Can't just load part of a little
endian f
<https://www.behance.net/mackevision>.
> --
> *Von:* nuke-users-boun...@support.thefoundry.co.uk <
> nuke-users-boun...@support.thefoundry.co.uk> im Auftrag von Randy Little <
> randyslit...@gmail.com>
> *Gesendet:* Freitag, 11. September 2015 22:06
&
ferent parts in the same file.
>
> -Nathan
>
>
> *From:* Randy Little <randyslit...@gmail.com>
> *Sent:* Friday, September 11, 2015 2:57 PM
> *To:* Nuke user discussion <nuke-users@support.thefoundry.co.uk>
> *Subject:* Re: [Nuke-users] Multipart multichannel ex
>
> *From:* Randy Little <randyslit...@gmail.com>
> *Sent:* Friday, September 11, 2015 4:29 PM
> *To:* Nuke user discussion <nuke-users@support.thefoundry.co.uk>
> *Subject:* Re: [Nuke-users] Multipart multichannel exrs vs. separate exrs
>
> Can't speak to mu
19 matches
Mail list logo