"there's room for improvement on the comp side regarding the available tools"
I think you summ'd it up right there Holger... there is room for improvement on the comp side because as it stands, working with any large volumetric scene (over 10 kilometers) in deep is cripplingly slow. Patrick, I agree point-clouds are great for reference, not so much for rendering... Thanks for your input guys! On Mon, Feb 25, 2013 at 8:51 AM, Holger Hummel|Celluloid VFX < [email protected]> wrote: > > hi Nitant, > > i'm afraid, you don't to tell the honest truth. > that's what deep compositing is actually good for - when set up correctly > and offering the right tools you need for stuff like that. > the way it is right now, there's room for improvement on the comp side > regarding the available tools, to say it in a diplomatic way... > apart from that, there's no such thing as a cloud mesh. a point cloud > would be the equivalent. and yes, those files tend to be > fairly big. and Nuke doesn't deal with them in a satisfactory way yet, if > i'm not mistaken. that's why basically deep comping > is your way to go - minus the afore-mentioned sub-optimal situation... > > cheers, > Holger > > > > Nitant Karnik wrote: > >> Holger, >> >> Thanks for the 'in depth' explanation! >> I get what your saying that FBX, Alembic and OBJs are the way to go for >> static hard surfaces but how would you handle extracting mattes from >> clouds, since exporting geo for a cloud mesh would be either too dense (if >> accurate) or too inaccurate (if it's not dense)? >> >> Cheers, >> Nitant >> >> >> >> >> On Sun, Feb 24, 2013 at 9:45 AM, Holger Hummel|Celluloid VFX < >> [email protected] >> <mailto:holger@celluloid-vfx.**com<[email protected]>>> >> wrote: >> >> hey Nitant, >> >> afaik, this is not possible. >> >> to be very honest, right now i cannot even think of any advantages >> in your suggestion/idea. >> >> if i understant you correctly, you're suggesting something >> comparable to FBX or Alembic files >> for deep pixel data. i don't think that you'd end up with a >> substantially smaller file compared >> to a frame sequence. in your example of a static object and a >> moving camera, FBX and the likes >> save a lot of space because e.g. an object is saved in it once >> plus the camera animation. the >> object is not saved per frame. now with deep pixel data, i highly >> doubt that there's a lot of this >> kind of space saving possible. so the only way to reduce size is >> compression. to achieve a good >> amount of compression it should be done across multiple (or even >> all) frames. which means >> every frame needs to be rendered first. so this would be a >> post-conversion. >> even if this were a useful approach, post-processing a lot of >> rendered frames into one >> big file is probably not very reasonable. >> next, re-rendering erroneous frames would be basically impossible >> or result in the need to >> re-build the all-frames-in-one-file from scratch. >> >> what you're imagining is roughly comparable to a multilayer-exr or >> stereo-exr. there is no >> speed-up in using those compared to single layer/view images. for >> example, to read layer 3, >> the file reader needs to go through the file across layers 1 and 2 >> until it can read the requested >> layer 3 data. i admit, i don't know 100% how this works but >> apparently there is a certain amount >> of time wasted this way. that's why i'm a fan of using exr files >> per pass instead of multilayer-exrs. >> now imagine this issue being spread across a ton of frames instead >> of a few layers and there's >> probably a lot more file reading/seeking time wasted. >> >> i'm not a programmer, so what i wrote might not be 100% correct. >> but my 'binary sense' somehow >> tells me that i got the basics right ;) >> >> so for what you'd like to achieve, i suggest going the FBX, OBJ >> sequence or Alembic way if you need >> to extract masks or similar tasks - in case you don't have those >> in the rendered frames already anyway. >> >> cheers, >> Holger >> >> >> Am 24.02.2013 10 <tel:24.02.2013%2010>:22, schrieb Nitant Karnik: >> >>> Hey! >>> >>> I was wondering if there was a way to write out one deep image >>> file per object for the entire length of a shot rather than a >>> deep image sequence... almost like a kind of DeepGeo? >>> Let's say the element you were rendering deep data for was a >>> static object like a building, light post, or a static cloud, >>> couldn't you pre-calculate all angles along the path of the >>> camera for the duration of the shot in one file? I would imagine >>> it would almost be like in comp terms, 'max merging' every deep >>> frame together and rendering that out? >>> >>> I think ultimately having 1 file of deep data would be smaller >>> and less of a network hit then having 200 files of deep data with >>> almost 50% (or more) of it being redundant information. >>> >>> I'm sure someone's thought of this already... any luck >>> implementing it? >>> >>> Nitant >>> >>> >>> >>> ______________________________**_________________ >>> Nuke-users mailing list >>> >>> [email protected].**co.uk<[email protected]><mailto: >>> Nuke-users@support.**thefoundry.co.uk<[email protected]>>, >>> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >>> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/** >>> nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >>> >> >> >> ______________________________**_________________ >> Nuke-users mailing list >> >> [email protected].**co.uk<[email protected]> >> >> <mailto:Nuke-users@support.**thefoundry.co.uk<[email protected]> >> >, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/** >> nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> >> >> ------------------------------**------------------------------** >> ------------ >> >> >> ______________________________**_________________ >> Nuke-users mailing list >> [email protected].**co.uk<[email protected]>, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-users<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users> >> > > -- > Holger Hummel - [email protected] > > Celluloid Visual Effects GmbH & Co. KG > Paul-Lincke-Ufer 39/40, 10999 Berlin > phone +49 (0)30 / 54 735 220 - [email protected] > > > ______________________________**_________________ > Nuke-users mailing list > [email protected].**co.uk<[email protected]>, > http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> > http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-users<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
