i think eric's apprehension is because point locators can sometimes disappear (ice wants to optimize them if they aren't being used)
another issue i have seen with point locators being frozen... in the cage deformer case if you duplicated your entire rig, i have seen the point locators not resolve to the correct duplicate object. instead they point back to the first one. On Wed, Jan 15, 2014 at 12:04 AM, Simon Reeves <[email protected]>wrote: > I guess if you know what the frozen tree contained (or it was a compound) you > can always just recreate it anytime if you need it so in that way there's > no risk? > > > On Tuesday, 14 January 2014, Alan Fregtman wrote: > >> Can't say there weren't random hiccups along the way but it's been >> working 99.9% on several dozen different vehicles. >> >> >> >> On Tue, Jan 14, 2014 at 4:59 PM, Eric Thivierge >> <[email protected]>wrote: >> >> You're a brave soul Alan. I don't trust frozen locations on meshes >> further than I can throw them... and I can't throw them at all... >> >> Not something I would recommend myself. >> >> - Eric T. >> >> >> On Tuesday, January 14, 2014 4:53:50 PM, Alan Fregtman wrote: >> >> By the way, as long as your locations are in-use (or you got Display >> Values on for it) you can freeze the tree responsible for doing the >> location lookup and storing it to a custom attribute. >> >> It will "freeze" the locations and it will be way faster when reading >> them. The second you change topology though, you'll need to compute >> the locations again. Same goes if you want to recreate the locations >> or overwrite what's frozen. >> >> I am currently employing this technique in production in a film with >> an epic car chase. The cars that crash are being (ICE) cage-deformed >> by an outer shell "blob" mesh (through shapekeys to warp them) and >> it's effectively using frozen locations to transfer the deformation to >> the entire set of meshes in the car relative to the cage mesh. >> >> >> >> >> On Tue, Jan 14, 2014 at 1:48 PM, Simon Reeves <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks Dan, >> >> Glad I'm not going crazy... It's one of those things I thought >> that I have done before and worked.. >> >> >> >> Simon Reeves >> London, UK >> /[email protected] <mailto:[email protected]>/ >> /www.simonreeves.com <http://www.simonreeves.com>/ >> /www.analogstudio.co.uk <http://www.analogstudio.co.uk>// >> >> / >> >> >> On 14 January 2014 17:46, Dan Yargici <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Simon. >> >> The sample set will constantly change with deformations. You >> have to emit from a static version and stick to a >> re-interpreted location on the deforming version. >> >> It's a little irritating, yeah. >> >> DAN >> >> >> On Tue, Jan 14, 2014 at 5:40 PM, Simon Reeves >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hello list, happy new year! >> >> I'm slightly puzzled here with locations. I thought that >> just having this simple set up would do the job, but alas >> it does not (see attached image) >> >> This tree is in a cloud in a non simulated stack, without >> time variation and without the seed changing. >> >> I thought that the points should stick to the same >> location on the geometry while the geometry deforms?... >> The do stick when the object's SRT moves, but not any >> deformation.. >> >> Now I can get this to work by adding a sim ice tree and >> just using*'Stick to Location'* >> >> **But it'd be great if it wasn't a simulated tree, and >> >> more to the point I'm just surprised that the locations >> change in the first place....(especially when i can stick >> to them afterwards), what is changing every frame >> initially? Is location based on the bounding box of the >> geometry or something?... >> >> >> >> > > -- > > > Simon Reeves > London, UK > *[email protected] <[email protected]>* > *www.simonreeves.com <http://www.simonreeves.com>* > *www.analogstudio.co.uk <http://www.analogstudio.co.uk>* > >
