Yes both of those reasons Steven.
On Wednesday, January 15, 2014 3:15:19 AM, Steven Caron wrote:
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]
<mailto:[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>
<http://www.simonreeves.com>/
/www.analogstudio.co.uk
<http://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] <mailto:[email protected]>/
/www.simonreeves.com <http://www.simonreeves.com>/
/www.analogstudio.co.uk <http://www.analogstudio.co.uk>//
/
