Hi Sandy,
This is a well-known issue for ICE for quite some time now. I am
intrigued you have not faced it so far. Most probably you are not
caching some user-defined (custom) attributes in your scenes. If you
are, then probably you are using these attribute down somewhere in your
tree which causes them to evaluate.
Anyways, beware if you do not already know, that custom attribute just
sitting in a tree and not being used anywhere will not be cached.
Cheers !
Alok Gandhi
Lead TD
ModusFx.
On 06/02/2013 1:23 PM, Sandy Sutherland wrote:
funny thing is I have not really been having these problems here -
cache away on the farm here and all attributes we wanted cached have
worked so far [touch wood and hope that I did not just put a curse on it].
S.
__
Sandy Sutherland <mailto:[email protected]> |
Technical Supervisor
<http://triggerfish.co.za/en>
<http://www.facebook.com/triggerfishanimation>
<http://www.twitter.com/triggerfishza>
------------------------------------------------------------------------
*From:* [email protected]
[[email protected]] on behalf of Martin
Chatterjee [[email protected]]
*Sent:* 06 February 2013 19:24
*To:* [email protected]
*Subject:* Re: [Mini rant-let] Caching attributes - again.
I'd second that.
I normally use all attributes I want to force evaluation for to
construct a zero length 3D vector. Then I do *GetPointPosition -->
AddMyZeroVector --> SetPointPosition* as the last Execute in my tree.
Has been working this way for me for years now.
Cheers, Martin
--
Martin Chatterjee
[ Freelance Technical Director ]
[ http://www.chatterjee.de <http://www.chatterjee.de/> ]
[ https://vimeo.com/chatterjee ]
On Wed, Feb 6, 2013 at 5:35 PM, Alok <[email protected]
<mailto:[email protected]>> wrote:
I would still advise using the forcing to be done through some
arithmetic nodes - like adding a zero vector to point positions etc.
Alok
Lead TD
Modusfx
On 06/02/2013 11:14 AM, Vladimir Jankijevic wrote:
the problem with this is that with the log node present in the
tree, the icetree will evaluate on every frame even if you have
two different evaluation stacks. Like if you have a tree in the
modeling stack and additionally to that a tree in the sim stack.
If you now put a log node into the tree in the modeling stack, it
will force the tree to evaluate on every frame even though the
sim stack would make the stacks below only evaluate on the first
frame. Hope this makes sense. This case makes it even more clear
that we need a way of disabling the automatic optimization of ICE
values.
Vladimir
On Wed, Feb 6, 2013 at 5:00 PM, Christian Keller
<[email protected] <mailto:[email protected]>> wrote:
yep, that´s the most reliable way to do it. just make a small
compound with the log node and deactivate the log checkbox.
then you can drop it onto your connection to the set data or
whatever node ...
--
christian keller
visual effects|direction
+49 179 69 36 248 <tel:%2B49%20179%2069%2036%20248>
[email protected] <mailto:[email protected]>
http://vimeo.com/channels/96149
Am 06. Februar 2013 um 16:05 schrieb Vladimir Jankijevic
<[email protected]
<mailto:[email protected]>>:
one way of doing it is to put a "Log Values" between the
data and the setData node. Even if the log node is muted,
Log is unchecked, this node forces the attributes to be
evaluated.
Cheers
Vladimir
On Wed, Feb 6, 2013 at 3:51 PM, Rob Chapman
<[email protected] <mailto:[email protected]>> wrote:
I know I know, I used to have various hacky ways to
'force' an
attribute to be stored in a cache. daisychaining them or
storing
userdata in the color or whatever ;) all of them have
failed me at
some point until I happened upon a demo ICE topo scene
provided by
Ciaran Moloney and saw that every single attribute used
in the tree
was diligently applied as a separate Custom attribute
display. Even
some built in attributes that you would expect to cache.
when trying
to recreate the exact setup, if any of those attributes
were NOT in a
custom display attribute then the topo caching / read
/write system
would fail.
so, like I said, to me, this is the ONLY way to reliably
store user
stuff in a cache that I have found so far. I like to
think when I am
setting up each of these custom display attributes
(after a failed
attribute cache) that each button press and menu select
in the process
is like hammering in a nail . that *hit* goddam *hit*
attribute
*hit* had better *hit* store *hit* this time!!! *Hit*
*Hit* *Hit*
On 6 February 2013 14:28, Sebastian Kowalski
<[email protected] <mailto:[email protected]>> wrote:
> ...or multiply by 1 and key that param, or put an
fcurve in between.
> still i would prefer a "do what i told you to" switch ;)
>
> Am 06.02.2013 <tel:06.02.2013> um 15:21 schrieb Rob
Chapman <[email protected]
<mailto:[email protected]>>:
>
>> long way around but definitely a brute force
approach. make a custom
>> attribute display for each attribute you need storing.
>>
>> On 6 February 2013 14:14, Sebastian Kowalski
<[email protected] <mailto:[email protected]>> wrote:
>>> +1 for brute cache !
>>>
>>> Am 06.02.2013 <tel:06.02.2013> um 15:06 schrieb Dan
Yargici <[email protected]
<mailto:[email protected]>>:
>>>
>>>> While I appreciate the software's efforts to cache
only the ICE attributes that it deems necessary (unless
I list all the ones I want - in this case, many); can we
please, please, get a "Just bastard cache everything, I
don't care how big the cache files are" button?
>>>>
>>>> I've lost hours today trying cheap and dirty tricks
to get a reliable cache.... grrrrr.
>>>>
>>>> DAN
>>>>
>>>
>>>
>>
>
>
--
---------------------------------------
Vladimir Jankijevic
Technical Direction
Elefant Studios AG
Lessingstrasse 15
CH-8002 Zürich
+41 44 500 48 20 <tel:%2B41%2044%20500%2048%2020>
www.elefantstudios.ch <http://www.elefantstudios.ch>
---------------------------------------
--
---------------------------------------
Vladimir Jankijevic
Technical Direction
Elefant Studios AG
Lessingstrasse 15
CH-8002 Zürich
+41 44 500 48 20 <tel:%2B41%2044%20500%2048%2020>
www.elefantstudios.ch <http://www.elefantstudios.ch>
---------------------------------------
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2012.0.2238 / Virus Database: 2639/5583 - Release Date:
02/05/13
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2012.0.2238 / Virus Database: 2639/5585 - Release Date: 02/06/13
