Cheers Mark, >>
> My current problem will be the Two Gig file limit of the XP..... > ..... RS is meant to run on heavy workstations with huge render farms, but it's rarely used this way in practice :( ......... a positive side on this: we poor 32bit-bums know very well how to work efficiently and we know our workarounds ;) Too true!! For me, so far, I have kept "takes" well under the limit and it's just trying to stitch the episodes together that is the problem. An "episode is between 7 and 15 "takes". So the file size limit is not on the RS side of things .... so far!! But "takes" get ever more complex of course. This is a natural law of artists and "tweaking" I think. In addition I am rendering with compression and at less than the HDV optimum file size. So putting together the real thing will need to be off-site for me. Someone will need to buy into it at that point of course. Fun. Thanks again, Neil. On Thu, Jun 13, 2013 at 7:35 AM, Mark Heuymans <[email protected]> wrote: > On 11-6-2013 22:52, Neil Cooke wrote: > >> Hi again List, Mark ... >> >> >Animating a material, you could affect a whole bunch of objects at once >> >> Yes, this was the objective for flashing lights. >> >> For example - I have twelve separately animated objects but they each >> have a flashing light on their heads. If I have to change the timing of the >> whole action, but leave the timing of the flashes as they were, I need to >> reach into each object and tweak the flash chor timeline back to what it >> was after changing the overall timing of the twelve objects. >> >> I thought a material should be easy to create in VSL. >> >> I cant use a fade based material or a clip based material, which are very >> easy to programme on/off as booleans in the chor window, because these do >> not affect the flashing light source. Objects appear and disappear but the >> light from any light source object does not. >> >> It is seldom a problem for me for many reasons. One being that a shifted >> frequency of flashing lights is not usually much and is not going to be >> noticed between "takes". Also I seldom have several, separately animated >> sources that require synchronising. >> > > > > Hi Neil, > > This is a complicated problem that pops up because of a combination of > factors, aaargh! > If only Fade would also fade light intensity it would be simple... (except > that partly Faded objects can be very slow to render if they are > self-shadowing) > > I had a crazy idea... make a tiny sphere around the lightsource, make it > camera-invisible, give it a material with a Surface Filtering shader. > See attachment, V6.1 project with only objects, materials and animation. > > The Surface Filtering shader affects shadow casting properties. If you > animate Filter:Transparency, it seems as if the lightsource is changing its > intensity. > BUT: this only works if the light source casts shadows, and the light > source must fit inside the sphere, in practice they have to be point > sources. The dummy spheres must be tiny because although they are > camera-invisible, they still cast shadows from other lights. And (the list > goes on) post processing effects like lens flares probably no longer > work... haven't checked this. > > > > > I just thought it might be easy and I'm really just being lazy since it's >> easy enough to create one choreography sequence and assign it to each >> object's lights then go into the chor window, find each object, find that >> flasher timeline and tweak them all at once. >> >> It is not stopping me in the big project. I think I'm almost finished the >> first sketch for the whole story. Probably an hour screentime. My current >> problem will be the Two Gig file limit of the XP I'm using but I can load >> Win7 and beat that I think. Anyway, sketch almost done and a ton of work to >> follow. Fun!! >> >> > > Same stupid 32-bit situation here :( > I had the opportunity to work a few times with RS on a 64-bit workstation > with 12 GB of RAM and it's a totally different story, especially with > scenes that contain many trees. RS is meant to run on heavy workstations > with huge render farms, but it's rarely used this way in practice :( > > Yet, there is a positive side on this: we poor 32bit-bums know very well > how to work efficiently and we know our workarounds ;) > > > > > The bonus is that I am getting so slick at some of my work procedures. >> >> Thanks for looking at it! >> >> Neil. >> >> > > Good to hear! > And good luck with this massive project, > > -Mark H > > _______________________________________________ > User-list mailing list > [email protected] > http://realsoft.com/mailman/listinfo/user-list_realsoft.com > >
_______________________________________________ User-list mailing list [email protected] http://realsoft.com/mailman/listinfo/user-list_realsoft.com
