From: "J Bills" Received: from [40.92.3.49] (HELO NAM02-BL2-obe.outbound.protection.outlook.com) by media-motion.tv (CommuniGate Pro SMTP 6.1.0) with ESMTPS id 7193597 for AE-List@media-motion.tv; Tue, 20 Nov 2018 06:10:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IcL3XK/mT8iOkChm1uo2LNO9Yg1ADw5oIHPiYZzoRs4=; b=hUVYWlMDlzFRwGQ67lGJtFh6JX5KZAkkzFordFzsh6fHbWtwZzw2T7mk3Bo3c+YlmOcG1tPJSE7WVy/1PTsDzlzVqCyZh331Forh2ggVwJCMs3fmxkrHCq7FDjSpl4rb9FGPY18vZe+EFTORGl1gqKspUwC3VwK54fBEn8PaQ+riGg7cbffb+8oAilpwX1oYVLDrLkxDckk2F83jzvWpWhMFnAdUqiXTVrswCM9599Wrzjj2vh3lG0RkQBkxJ4xI7A/8yD0oKmks5liphzgZxG/xzmOH08I3ehy0ahYI1Q1AXSJsWY8u1E91N3wMV9X/zX4jdP2AHuKFi5v7z3g2cg== Received: from SN1NAM02FT055.eop-nam02.prod.protection.outlook.com (10.152.72.52) by SN1NAM02HT204.eop-nam02.prod.protection.outlook.com (10.152.72.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.15; Tue, 20 Nov 2018 05:23:39 +0000 Received: from BYAPR11MB3112.namprd11.prod.outlook.com (10.152.72.57) by SN1NAM02FT055.mail.protection.outlook.com (10.152.72.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.15 via Frontend Transport; Tue, 20 Nov 2018 05:23:39 +0000 Received: from BYAPR11MB3112.namprd11.prod.outlook.com ([fe80::7ca2:c36e:a91e:d92c]) by BYAPR11MB3112.namprd11.prod.outlook.com ([fe80::7ca2:c36e:a91e:d92c%3]) with mapi id 15.20.1294.048; Tue, 20 Nov 2018 05:23:38 +0000 To: Stephen van Vuuren Subject: Re: [AE] Constant hangs when switching between apps Thread-Topic: [AE] Constant hangs when switching between apps Thread-Index: AQHUfe2qG8vtNSnmjEuC+r/kNbKtfKVYIo9q Date: Tue, 20 Nov 2018 05:23:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A2641B03F980AB857D8BC03910ED7663B2C8C296C71D8990189876B21FE61A9E;UpperCasedChecksum:FDDF9D340E57A0071AD02B3E078B68764674A17420AABA90AB6595B125D5DB7B;SizeAsReceived:6964;Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [oP5tB5BLbFKgIB2kegJn0essSjh8zRc2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;SN1NAM02HT204;6:IH/y5RjcqTrSju8JGHGErPNY+twpoDUMwU4LvNwRifdYkXbDTHTDedY84qPyV96Cknc7ayzQ7iQw81IpLGs9UdyfeE6vzHDw9USNHz6NAX7vzfd1YoQbU+UW3FOI3YlVwp4QOpFeKZM0dqKsCHt2+cyJZOUPPHl6w/tbD/VEWamBs3OkYiZZBnmcrMw9Hr7djpm18/2cul7crAAxlnfOLq5F80i7C2zpr/kN9oKPFKKCBE5UN66JNeC4ZkQN1kfAdj8HtQTutPKhJeI4vt45JQAOI9PvfJ3171V3l+CHa5s7hl1QvrZsqv2O4K/sCrKp3a6WJhZSjIS/pNOfyXQkDvEMjBaseCs3OyawTJKUDtBSOcCqK4tw7D/bXcknkRHQfwMcRCEK3dyAvjfgB6rP2pRaqpLhxQ/JMAv9QO5m3NDxCOCt3rOVSQr6Eb3UUlC1bA8Idj7QW2Yv4jqnWFrgVQ==;5:wwoHwG3YCbWreD7qlNYKiSzQVEsYkwy8YgD6w+WyA0CGmZV58btYmML2HOWjWUvr3TSYQIij3BkQxmXRtAIwoqAtSu7BAKNhjGlzuyO9qqNrzuFQEIySli/XRFceZMHkKacyqhmrlruEcGyU1n65lNvKjNJpE8w29B8mzmlytP8=;7:8OVgoJ6O236Iugf+vakUw0fsMzSX2jK6lgv6cqw5y8XN+iXGzPtw7NMiu7VybaG69VrlVQCLuiIOnuAtpPAcUcTpST9b2cai9pSFQ03OGtZ7LuFGpZ5XdetxbW/8niOJ69Nce0m1o3OAI6CAHOS6Yg== x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390098)(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045);SRVR:SN1NAM02HT204; x-ms-traffictypediagnostic: SN1NAM02HT204: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(4566010)(82015058);SRVR:SN1NAM02HT204;BCL:0;PCL:0;RULEID:;SRVR:SN1NAM02HT204; x-microsoft-antispam-message-info: dEoakEy9GqaWzhbRhEzyOAXXRwkxOc1Cq8ByQftUhD6Wi5DNaxnyevBkvwBRmxtf Content-Type: multipart/alternative; boundary="_000_BYAPR11MB311208BF7AC2885F41E380A5B9D90BYAPR11MB3112namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 24fd1209-d934-423e-a578-ee886993c07f X-MS-Exchange-CrossTenant-Network-Message-Id: 63f497ab-f090-4324-757b-08d64ea853f6 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 24fd1209-d934-423e-a578-ee886993c07f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2018 05:23:38.9324 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT204 --_000_BYAPR11MB311208BF7AC2885F41E380A5B9D90BYAPR11MB3112namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Nuke has a really elegant way of handling this. You can localize any or al= l network footage in a project file to a predefined cache location. Typica= lly this is on the local ssd/nvme. Nuke organizes it and it's easy to see = what all is in this folder when tidying up. It takes a certain amount of time to cache the files down from a server - u= sually within the reach of a coffee for a typical shot - and from there you= work essentially network free for the duration. Project files are saved t= o the network, where they are presumably backed up a dozen different ways a= nd/or snapshot regularly. Renders go to the server. If you render out a p= ortion of your script as a precomp, you'll need to cache that or any other = new renders when bringing it back into your comp. Nuke retains the link to the network footage, so that if it reaches locally= and doesn't find it, it reverts back to the network path. This is handy f= or renderfarm nodes and the like, which often don't have the footage cached= locally. I've done this (albeit totally manually and not near as elegantly) in AE us= ing the proxy functionality, where it puts a little dot next to the footage= /element in the project bin and allows you to switch between 2 locations of= the footage. Which was originally meant to be for working with large forma= ts at lower rez, but I believe I was able to use the same size footage in 2= different locations. Don't quote me, it's been a while... Does make me wonder out loud if someone has hot rodded this workflow and au= tomated things better on aescripts or rendergarden or something. Most of t= he larger studios I've worked at have tweaked this in Nuke to be constantly= doing it in the background without the user even thinking about it. ________________________________ From: After Effects Mail List on behalf of Stephe= n van Vuuren Sent: Friday, November 16, 2018 11:47 AM To: After Effects Mail List Subject: Re: [AE] Constant hangs when switching between apps > I thought we were supposed to be editing 8K off the cloud by now. Yeah, the death of the desktop has been forecast about as often as the end = of the world and it just doesn=92t happen. Again, it=92s just physics and e= conomics. Whatever makes the cloud faster and cheaper makes local computing= =93more faster=94 and =93more cheaper=94 and will continue unless some rev= olutionary breakthrough in time, matter and space changes all that. If you google =93death of the desktop=94 you will get forecasts going back = into the 80=92s - then the dumb terminal was going to take over until mobil= e tech arrived. Now we just have pocket desktops instead of pocket dumb terminals. In fact,= I think foldout phones will kill off the tablet. Possibly the laptop in a = much longer timeframe but iOS and Android will need to have much better cur= sor, mouse and keyboard features to make that happen. But computing needs in the foreseeable future will always demand beefier s= tuff for power users and at least in us old guys lifetimes, no evidence poi= nts to that changing. Best, stephen van vuuren 336.202.4777 http://www.insaturnsrings.com/ http://www.sv2studios.com/ http://www.sv2dcp.com/ A film is =96 or should be =96 more like music than like fiction. It should= be a progression of moods and feelings. The theme, what=92s behind the emo= tion, the meaning, all that comes later. =96Stanley Kubrick From: After Effects Mail List Sent: Friday, November 16, 2018 1:13 PM To: After Effects Mail List Subject: Re: [AE] Constant hangs when switching between apps I thought we were supposed to be editing 8K off the cloud by now. On Nov 16, 2018, at 11:34 AM, Stephen van Vuuren > wrote: > A properly configured SAN works pretty darn well across multiple workstat= ions, but can still bog down during peak use. Which is a failure of engineering 101 =96 you design infrastructure to hand= le Max Q i.e. beyond peak use, not for normal traffic. Sure, this basic pri= nciple is violated all the time in the world and creates a lot of problems = (DC Beltway), but in the case of storage, there is no reason other than it= =92s expedient. It=92s certainly not cheaper or fasters. Best, stephen van vuuren 336.202.4777 http://www.insaturnsrings.com/ http://www.sv2studios.com/ http://www.sv2dcp.com/ A film is =96 or should be =96 more like music than like fiction. It should= be a progression of moods and feelings. The theme, what=92s behind the emo= tion, the meaning, all that comes later. =96Stanley Kubrick From: After Effects Mail List > Sent: Friday, November 16, 2018 11:33 AM To: After Effects Mail List > Subject: Re: [AE] Constant hangs when switching between apps A properly configured SAN works pretty darn well across multiple workstatio= ns, but can still bog down during peak use. It=92s when a NAS or SMB/AFP filesharing is used as if it=92s a SAN that th= ings tend to go sideways. -Warren Sent from my iPhone On Nov 15, 2018, at 11:05 AM, Dennis Wilkins > wrote: Working on one film with very unique specs for several years is very differ= ent than 90-95% of production studios and agencies who may be turning over = 1-15 jobs per week and has multiple artists working on several projects sim= ultaneously (and possibly even hopping from machine to machine). Don=92t ev= en start trying to figure out how to go about archiving these jobs if the w= ork files are all over the place - especially when using freelancers who ha= ve different organization and work habits and may leave before the project = is even completed. Try integrating a render farm with multiple artists using the setup you=92r= e recommending... Once you add in live action plates, editorial, mgfx, and vfx tasks and even= if you could possibly manage all of this you would cause nearly the same a= mount of network thrashing just trying to get artists the right source file= s, not to mention always having to wait for the files to be synced to the r= ight places. The network would come to a standstill every time you started a new project= while trying to sync everything to the right destinations. A better option in AE=92s case is to have a large SSD for your Disk Cache; = you should then effectively be reducing network traffic but more intelligen= tly and without the IT overhead. Dennis Wilkins On Nov 15, 2018, at 10:24 AM, Stephen van Vuuren > wrote: > Yeah, I'm not sure how we'd effectively have a team of artists working on= a bunch of different shots simultaneously on the same project if the files= had to be synced locally before they could use them. I did this many thousand of times on my IMAX film. It=92s just getting the = workflow right and because you=92re only copying a file once or twice acros= s a LAN, instead of hundreds or thousands of times, the speed improvement a= nd cost reduction is very large. >>using Render Garden to distribute a render that's going right to an edito= r, etc. and all of that needs to happen immediately -- it doesn't work for = something to sync overnight. It=92s just a question of what gets distributed where and when =96 and duri= ng my heavy years on the film, I had hundreds of syncs and mirrors happenin= g a week =96 dozens on busy days. >> We sometimes even sync entire projects from our network drive to Dropbox= so remote freelancers can work on them as well. You just argued for working local solution. A remote freelancer is function= ally identical to a network workstation which is remote from central server= . Just much greater latency and poorer bandwidth, so the issue is painfully= easy to see. But that does mean this issue vanishes when someone is inside= the building. The identical structural issues are all there, just short en= ough duration that we put up with it. But just because something only takes seconds or minutes longer working net= work workstation then working locally in the most conservative examples, th= at means over time, months, years, we are talking about massive effects on = cost and performance as well increased risks of problems. >> I'm all for things going faster, but that seems impossible without worki= ng off of central storage on a network. I'd be curious what kind of infras= tructure and workflow design could get around this. Again, I=92m in the final stages of my IMAX film. We had 100+ volunteers bu= t the bulk of the work was done here, primarily by me but due to the slowne= ss of working with the files, I normally had three workstations plus a lapt= op running around me (while one machine was previewing frames, move to the = other) so that=92s 4 workstations plus 15 render boxes all rendering projec= ts from the three workstation, 2 nearline servers and two archival servers = and 2 cloud backup services. We have three main teams of volunteers all working remotely and using both = Dropbox and Gdrive to sync projects and assets but for some on slow connect= ions, FedEx and hard drive was the way to go. Never was a file worked over the network. 33 Million files at peak, 700 TB = at peak. The scope of how is both beyond email discussion and would vary widely base= d on the biz. From: After Effects Mail List > Sent: Thursday, November 15, 2018 11:30 AM To: After Effects Mail List > Subject: Re: [AE] Constant hangs when switching between apps > Then every VFX studio I've worked at, between 4 and 400 employees, is doi= ng it wrong apparently. Yeah, I'm not sure how we'd effectively have a team of artists working on a= bunch of different shots simultaneously on the same project if the files h= ad to be synced locally before they could use them. We're constantly updat= ing an asset, bringing in a new version of the 3D render to comp while it's= still rendering, using Render Garden to distribute a render that's going r= ight to an editor, etc. and all of that needs to happen immediately -- it d= oesn't work for something to sync overnight. We sometimes even sync entire= projects from our network drive to Dropbox so remote freelancers can work = on them as well. I'm all for things going faster, but that seems impossible without working = off of central storage on a network. I'd be curious what kind of infrastru= cture and workflow design could get around this. On Wed, Nov 14, 2018 at 11:27 PM Brendan Bolles > wrote: On Nov 14, 2018, at 12:01 PM, Stephen van Vuuren > wrote: Workstations working directly off network storage is slower, more expensive= , more prone to failure and a huge waste of time and money. Then every VFX studio I've worked at, between 4 and 400 employees, is doing= it wrong apparently. --_000_BYAPR11MB311208BF7AC2885F41E380A5B9D90BYAPR11MB3112namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Nuke has a really elegant way of handling this.  You can localize any = or all network footage in a project file to a predefined cache location.&nb= sp; Typically this is on the local ssd/nvme.  Nuke organizes it and it= 's easy to see what all is in this folder when tidying up.

It takes a certain amount of time to cache the files down from a server - u= sually within the reach of a coffee for a typical shot - and from there you= work essentially network free for the duration.  Project files are sa= ved to the network, where they are presumably backed up a dozen different ways and/or snapshot regularly.  Renders = go to the server.  If you render out a portion of your script as a pre= comp, you'll need to cache that or any other new renders when bringing it b= ack into your comp.

Nuke retains the link to the network footage, so that if it reaches locally= and doesn't find it, it reverts back to the network path.  This is ha= ndy for renderfarm nodes and the like, which often don't have the footage c= ached locally.

I've done this (albeit totally manually and not near as elegantly) in AE us= ing the proxy functionality, where it puts a little dot next to the footage= /element in the project bin and allows you to switch between 2 locations of= the footage. Which was originally meant to be for working with large formats at lower rez, but I believe I w= as able to use the same size footage in 2 different locations.  Don't = quote me, it's been a while...

Does make me wonder out loud if someone has hot rodded this workflow and au= tomated things better on aescripts or rendergarden or something.  Most= of the larger studios I've worked at have tweaked this in Nuke to be const= antly doing it in the background without the user even thinking about it.


From: After Effects Mail Li= st <AE-List@media-motion.tv> on behalf of Stephen van Vuuren <AE-L= ist@media-motion.tv>
Sent: Friday, November 16, 2018 11:47 AM
To: After Effects Mail List
Subject: Re: [AE] Constant hangs when switching between apps
 

> I thought we were supposed to be editing 8K o= ff the cloud by now.

 

Yeah, the death of the desktop has been forecast a= bout as often as the end of the world and it just doesn=92t happen. Again, = it=92s just physics and economics. Whatever makes the cloud faster and chea= per makes local computing =93more faster=94 and =93more cheaper=94 and will continue unless some revolutionary breakth= rough in time, matter and space changes all that.

 

If you google =93death of the desktop=94 you will = get forecasts going back into the 80=92s - then the dumb terminal was going= to take over until mobile tech arrived.

 

Now we just have pocket desktops instead of pocket= dumb terminals. In fact, I think foldout phones will kill off the tablet. = Possibly the laptop in a much longer timeframe but iOS and Android will nee= d to have much better cursor, mouse and keyboard features to make that happen.

 

But computing needs in the foreseeable future will= always demand  beefier stuff for power users and at least in us old g= uys lifetimes, no evidence points to that changing.

 

Best,

 

stephen van vuuren

336.202.4777

 

http://www.insaturnsrings.com/

http://www.= sv2studios.com/

http://www.sv2d= cp.com/

 

A film is =96 or shoul= d be =96 more like music than like fiction. It should be a progression of m= oods and feelings. The theme, what=92s behind the emotion, the meaning, all= that comes later.

=96Stanley Kubrick

 

From: After Effects Mail List <AE-List@m= edia-motion.tv>
Sent: Friday, November 16, 2018 1:13 PM
To: After Effects Mail List <AE-List@media-motion.tv>
Subject: Re: [AE] Constant hangs when switching between apps

 

I thought we were supposed to be editing 8K off th= e cloud by now.

 

 



On Nov 16, 2018, at 11:34 AM, Stephen van Vuuren &= lt;AE-List@media-motion.tv&g= t; wrote:

 

> A properly configured SAN works pretty darn w= ell across multiple workstations, but can still bog down during peak use.

 

Which is a failure of engineering 101 =96 you desi= gn infrastructure to handle Max Q i.e. beyond peak use, not for normal traf= fic. Sure, this basic principle is violated all the time in the world and c= reates a lot of problems (DC Beltway), but in the case of storage, there is no reason other than it=92s expedient= . It=92s certainly not cheaper or fasters.

 

Best,

 

stephen van vuuren

336.202.4777

 

 

A film is =96 or should be =96 more like music tha= n like fiction. It should be a progression of moods and feelings. The theme= , what=92s behind the emotion, the meaning, all that comes later.

=96Stanley Kubrick

 

From: After Effects Mail List <AE-List@media-motion.tv&= gt; 
Sent: Friday, No= vember 16, 2018 11:33 AM
To: After Effect= s Mail List <AE-List@media-motion.tv>
Subject: Re: [AE= ] Constant hangs when switching between apps

 

A properly configured SAN works pretty darn well a= cross multiple workstations, but can still bog down during peak use.

 

It=92s when a NAS or SMB/AFP filesharing is used a= s if it=92s a SAN that things tend to go sideways.

 

 

 

 

-Warren

 

 

 

 

  

Sent from my iPhone


On Nov 15, 2018, at 11:05 AM, Dennis Wilkins <AE-List@media-motion.tv> wrote:

Working on one film with very unique specs for sev= eral years is very different than 90-95% of production studios and agencies= who may be turning over 1-15 jobs per week and has multiple artists workin= g on several projects simultaneously (and possibly even hopping from machine to machine). Don=92t even start tr= ying to figure out how to go about archiving these jobs if the work files a= re all over the place - especially when using freelancers who have differen= t organization and work habits and may leave before the project is even completed.

 

Try integrating a render farm with multiple artist= s using the setup you=92re recommending...

 

Once you add in live action plates, editorial, mgf= x, and vfx tasks and even if you could possibly manage all of this you woul= d cause nearly the same amount of network thrashing just trying to get arti= sts the right source files, not to mention always having to wait for the files to be synced to the right plac= es.

 

The network would come to a standstill every time = you started a new project while trying to sync everything to the right dest= inations.

 

A better option in AE=92s case is to have a large = SSD for your Disk Cache; you should then effectively be reducing network tr= affic but more intelligently and without the IT overhead.

 

Dennis Wilkins

 

 

 

 

On Nov 15, 2018, at 10:24 AM, Stephen van Vuuren &= lt;= AE-List@media-motion.tv> wrote:

 

> Yeah, I'm not sure how we'd effectively have = a team of artists working on a bunch of different shots simultaneously on t= he same project if the files had to be synced locally before they could use= them. 

 

I did this many thousand of times on my IMAX film.= It=92s just getting the workflow right and because you=92re only copying a= file once or twice across a LAN, instead of hundreds or thousands of times= , the speed improvement and cost reduction is very large.

 

>>using Render Garden to distribute a render= that's going right to an editor, etc. and all of that needs to happen imme= diately -- it doesn't work for something to sync overnight. 

 

It=92s just a question of what gets distributed wh= ere and when =96 and during my heavy years on the film, I had hundreds of s= yncs and mirrors happening a week =96 dozens on busy days.

 

>> We sometimes even sync entire projects fr= om our network drive to Dropbox so remote freelancers can work on them as w= ell.

 

You just argued for working local solution. A remo= te freelancer is functionally identical to a network workstation which is r= emote from central server. Just much greater latency and poorer bandwidth, = so the issue is painfully easy to see. But that does mean this issue vanishes when someone is inside the bui= lding. The identical structural issues are all there, just short enough dur= ation that we put up with it.

 

But just because something only takes seconds or m= inutes longer working network workstation then working locally in the most = conservative examples, that means over time, months, years, we are talking = about massive effects on cost and performance as well increased risks of problems.

 

>> I'm all for things going faster, but that= seems impossible without working off of central storage on a network. = ; I'd be curious what kind of infrastructure and workflow design could get = around this.

 

Again, I=92m in the final stages of my IMAX film. = We had 100+ volunteers but the bulk of the work was done here, primaril= y by me but due to the slowness of working with the files, I normally had t= hree workstations plus a laptop running around me (while one machine was previewing frames, move to the other) so = that=92s 4 workstations plus 15 render boxes all rendering projects from th= e three workstation, 2 nearline servers and two archival servers and 2 clou= d backup services.

 

We have three main teams of volunteers all working= remotely and using both Dropbox and Gdrive to sync projects and assets but= for some on slow connections, FedEx and hard drive was the way to go.


Never was a file worked over the network. 33 Million files at peak, 700 TB = at peak.


The scope of how is both beyond email discussion and would vary widely base= d on the biz.

 

 

From: After Effects Mail List <AE-List@media-motion.tv&= gt; 
Sent: Thursday, = November 15, 2018 11:30 AM
To: After Effect= s Mail List <AE-List@media-motion.tv>
Subject: Re: [AE= ] Constant hangs when switching between apps

 

> Then every VFX studio I've worked at, between= 4 and 400 employees, is doing it wrong apparently.

 

Yeah, I'm not sure how we'd effectively have a tea= m of artists working on a bunch of different shots simultaneously on the sa= me project if the files had to be synced locally before they could use them= .  We're constantly updating an asset, bringing in a new version of the 3D render to comp while it's still render= ing, using Render Garden to distribute a render that's going right to an ed= itor, etc. and all of that needs to happen immediately -- it doesn't work f= or something to sync overnight.  We sometimes even sync entire projects from our network drive to Dropbox s= o remote freelancers can work on them as well.

 

I'm all for things going faster, but that seems im= possible without working off of central storage on a network.  I'd be = curious what kind of infrastructure and workflow design could get around th= is.

 

On Wed, Nov 14, 2018 at 11:27 PM Brendan Bolles &l= t;A= E-List@media-motion.tv> wrote:

 

On Nov 14, 2018, at 12:01 PM, Stephen van Vuuren &= lt;AE-List@media-motion.tv> wrote:

 

Workstations working directly off network storage = is slower, more expensive, more prone to failure and a huge waste of time a= nd money.

 

 

Then every VFX studio I've worked at, between 4 an= d 400 employees, is doing it wrong apparently.

 

--_000_BYAPR11MB311208BF7AC2885F41E380A5B9D90BYAPR11MB3112namp_--