When a weight map's weight values are being driven by an ICE Tree if you
freeze the weight map, it ends up removing that ICE Operator. It would be
nice if it didn't do this, because maybe I needed that ICE Tree for other
effects, but it's okay because I can understand why that ICE Tree might
have to go away in order to freeze the weight map.
What makes less sense to me is what happens with custom Static Kinematic
State nodes.
If I create a custom Static Kinematic State node and then access it in an
ICE Tree, freezing that ICE Tree will result in that Static Kinematic State
node disappearing. In this case, the property node is feeding the ICE Tree,
not vice versa, so deleting it doesn't make sense.
Any chance this might be a bug rather than a feature?
Second thing sounds like a bug, but for the first thing:
If you know beforehand you'll potentially want to freeze the weightmaps,
the trick is to store your weightmap data to a custom attribute, then with
a second icetree *on the weightmap* (just select the map when creating the
icetree) then you can read your custom attribute and set the weightmap data.
This way if you freeze the weightmap, it will freeze that icetree inside it
and not the first, so your other effects are safe. :)
On Fri, Jun 29, 2012 at 6:06 PM, Bradley Gabe <witha...@gmail.com> wrote:
> When a weight map's weight values are being driven by an ICE Tree if you
> freeze the weight map, it ends up removing that ICE Operator. It would be
> nice if it didn't do this, because maybe I needed that ICE Tree for other
> effects, but it's okay because I can understand why that ICE Tree might
> have to go away in order to freeze the weight map.
> What makes less sense to me is what happens with custom Static Kinematic
> State nodes.
> If I create a custom Static Kinematic State node and then access it in an
> ICE Tree, freezing that ICE Tree will result in that Static Kinematic State
> node disappearing. In this case, the property node is feeding the ICE Tree,
> not vice versa, so deleting it doesn't make sense.
> Any chance this might be a bug rather than a feature?
Yup, I've had workarounds for the weight map ICE Tree thing for a long
time, which is why I'm not so annoyed by it. But so far, no good workaround
for the Static Kinematic State issue.
On Fri, Jun 29, 2012 at 6:15 PM, Alan Fregtman <alan.fregt...@gmail.com>wrote:
> Second thing sounds like a bug, but for the first thing:
> If you know beforehand you'll potentially want to freeze the weightmaps,
> the trick is to store your weightmap data to a custom attribute, then with
> a second icetree *on the weightmap* (just select the map when creating the
> icetree) then you can read your custom attribute and set the weightmap data.
> This way if you freeze the weightmap, it will freeze that icetree inside
> it and not the first, so your other effects are safe. :)
> On Fri, Jun 29, 2012 at 6:06 PM, Bradley Gabe <witha...@gmail.com> wrote:
>> When a weight map's weight values are being driven by an ICE Tree if you
>> freeze the weight map, it ends up removing that ICE Operator. It would be
>> nice if it didn't do this, because maybe I needed that ICE Tree for other
>> effects, but it's okay because I can understand why that ICE Tree might
>> have to go away in order to freeze the weight map.
>> What makes less sense to me is what happens with custom Static Kinematic
>> State nodes.
>> If I create a custom Static Kinematic State node and then access it in an
>> ICE Tree, freezing that ICE Tree will result in that Static Kinematic State
>> node disappearing. In this case, the property node is feeding the ICE Tree,
>> not vice versa, so deleting it doesn't make sense.
>> Any chance this might be a bug rather than a feature?
The compounds were built Michael Arias, I'd be keen to see them fi anyone has a copy around.
Many thanks,
Adam.
________________________________ From: Adam Seeley <adam_see...@yahoo.com> To: "softim...@listproc.autodesk.com" <softim...@listproc.autodesk.com> Sent: Saturday, 30 June 2012, 16:23 Subject: Old tekkon particle presets
Hi,
I wondered if anyone had a copy of this file floating around from an old Autodesk Customer Story?
great read on a great movie – one of the best animated manga’s in my opinion.
interesting backstory – I didn’t know it had taken such a long time, since way before the Animatrix even.
From: olivier jeannel Sent: Saturday, June 30, 2012 7:11 PM
To: Adam Seeley ; softim...@listproc.autodesk.com Subject: Re: Old tekkon particle presets
The compounds were built Michael Arias, I'd be keen to see them fi anyone has a copy around.
Many thanks,
Adam.
--------------------------------------------------------------------------- ---
From: Adam Seeley mailto:adam_see...@yahoo.com
To: mailto:softim...@listproc.autodesk.com mailto:softim...@listproc.autodesk.com Sent: Saturday, 30 June 2012, 16:23
Subject: Old tekkon particle presets
Hi,
I wondered if anyone had a copy of this file floating around from an old Autodesk Customer Story?
On Sat, Jun 30, 2012 at 2:50 PM, <pete...@skynet.be> wrote:
> great read on a great movie – one of the best animated manga’s in my
> opinion.
> interesting backstory – I didn’t know it had taken such a long time, since
> way before the Animatrix even.
> *From:* olivier jeannel <olivier.jean...@noos.fr>
> *Sent:* Saturday, June 30, 2012 7:11 PM
> *To:* Adam Seeley <adam_see...@yahoo.com> ;
> softim...@listproc.autodesk.com
> *Subject:* Re: Old tekkon particle presets
________________________________ From: Paul Griswold <pgrisw...@fusiondigitalproductions.com> To: softim...@listproc.autodesk.com Sent: Saturday, 30 June 2012, 20:04 Subject: Re: Old tekkon particle presets
I just sent Michael Arias an email and asked if he still had them. He's in Japan and it's probably 4am, so it might take a bit for him to reply.
-Paul
On Sat, Jun 30, 2012 at 2:50 PM, <pete...@skynet.be> wrote:
great read on a great movie – one of the best animated manga’s in my opinion.
>interesting backstory – I didn’t know it had taken such a long time, since
On Sat, Jun 30, 2012 at 4:00 PM, Adam Seeley <adam_see...@yahoo.com> wrote:
> Well fair enough then :)
> Thanks a lot.
> Adam.
> ------------------------------
> *From:* Paul Griswold <pgrisw...@fusiondigitalproductions.com>
> *To:* softim...@listproc.autodesk.com
> *Sent:* Saturday, 30 June 2012, 20:04
> *Subject:* Re: Old tekkon particle presets
> I just sent Michael Arias an email and asked if he still had them. He's
> in Japan and it's probably 4am, so it might take a bit for him to reply.
> -Paul
> On Sat, Jun 30, 2012 at 2:50 PM, <pete...@skynet.be> wrote:
> great read on a great movie – one of the best animated manga’s in my
> opinion.
> interesting backstory – I didn’t know it had taken such a long time, since
> way before the Animatrix even.
> *From:* olivier jeannel <olivier.jean...@noos.fr>
> *Sent:* Saturday, June 30, 2012 7:11 PM
> *To:* Adam Seeley <adam_see...@yahoo.com> ;
> softim...@listproc.autodesk.com
> *Subject:* Re: Old tekkon particle presets
It's a possibility (and an unfortunate one actually) that the particles were done in the pre-ICE system, which might have been since retired from Softimage a few versions ago.
Hope I'm wrong, though.
-T
On Jun 30, 2012, at 11:34 AM, Adam Seeley <adam_see...@yahoo.com> wrote:
On Sat, Jun 30, 2012 at 4:09 PM, Todd Akita <tak...@earthlink.net> wrote:
> It's a possibility (and an unfortunate one actually) that the particles
> were done in the pre-ICE system, which might have been since retired from
> Softimage a few versions ago.
> Hope I'm wrong, though.
> -T
> On Jun 30, 2012, at 11:34 AM, Adam Seeley <adam_see...@yahoo.com> wrote:
On Fri, Jun 29, 2012 at 6:19 PM, Bradley Gabe <witha...@gmail.com> wrote:
> Yup, I've had workarounds for the weight map ICE Tree thing for a long
> time, which is why I'm not so annoyed by it. But so far, no good workaround
> for the Static Kinematic State issue.
> On Fri, Jun 29, 2012 at 6:15 PM, Alan Fregtman <alan.fregt...@gmail.com>wrote:
>> Second thing sounds like a bug, but for the first thing:
>> If you know beforehand you'll potentially want to freeze the weightmaps,
>> the trick is to store your weightmap data to a custom attribute, then with
>> a second icetree *on the weightmap* (just select the map when creating the
>> icetree) then you can read your custom attribute and set the weightmap data.
>> This way if you freeze the weightmap, it will freeze that icetree inside
>> it and not the first, so your other effects are safe. :)
>> On Fri, Jun 29, 2012 at 6:06 PM, Bradley Gabe <witha...@gmail.com> wrote:
>>> When a weight map's weight values are being driven by an ICE Tree if you
>>> freeze the weight map, it ends up removing that ICE Operator. It would be
>>> nice if it didn't do this, because maybe I needed that ICE Tree for other
>>> effects, but it's okay because I can understand why that ICE Tree might
>>> have to go away in order to freeze the weight map.
>>> What makes less sense to me is what happens with custom Static Kinematic
>>> State nodes.
>>> If I create a custom Static Kinematic State node and then access it in
>>> an ICE Tree, freezing that ICE Tree will result in that Static Kinematic
>>> State node disappearing. In this case, the property node is feeding the ICE
>>> Tree, not vice versa, so deleting it doesn't make sense.
>>> Any chance this might be a bug rather than a feature?
its legacy - all the scenes don't render but they load and play OK in
2012 . Ive taken the liberty of putting the original .zip on my
Google Drive thingy here
