Usage of cache nodes with complex types

StephenTStephenT Fabric for MotionBuilder Posts: 77

Hey all,

I'm wondering if I am using cache nodes right, and if using them wrong could cause unwanted side effects.

As I understand, a cache prevents upstream evaluation unless some input to the upstream changes.

There are many cases where this sounds handy - any time there is an expensive operation, I put a cache in.

However, the cache tries to make its value immutable. I see the sense of this for simple values, but for a complex class it just doesn't work. For example, I have one expensive operation (constructing an agent), another expensive operation (building a path), then a final expensive operation (generating/updating renderable items). Each of these operations are self contained, dependent on the prior state, but does not override the previous values.

In these cases, I'm getting around the caching by just casting away the const in KL, but this seems somehow... not good.

I guess if I was starting from Canvas rather than porting from KL, I would design the system so that each nodes output only related to what that node calculated (instead of having one container object that flowed through the whole graph. This sounds probably cleaner, but...

Is there any problems I might run into due to de-consting my cached instances? Is there a better method rather than what I'm doing?

Tagged:

Comments

  • Roy NieterauRoy Nieterau Posts: 258 ✭✭✭

    Immutable

    I think the reason behind the cache being immutable is because of the fact that the cache is the object in the state at that point in the graph. (It's actually that point in the graph in memory). If it was mutable and you would adjust its values that particular point in the graph in memory wouldn't be correct anymore.

    Making it mutable

    If you'd want to have a mutable copy of your cache you should be able to clone your instance. Basically it's saying "take a copy of what is in memory" which I believe would be the only correct way to leave the cached state unaltered (so it remains cached).

    I guess if I was starting from Canvas rather than porting from KL, I would design the system so that each nodes output only related to what that node calculated (instead of having one container object that flowed through the whole graph. This sounds probably cleaner, but...

    This totally depends on the amount of outputs it is calculating and whether these results are intrinsic to the state of the object. If there are many outputs and/or they are solely related to the object itself I would keep them on the object as you have. If the resulting value isn't meant to be part of the object I believe by design it shouldn't be a value on it anyway.


    To understand your thought-process: "How would you expect the cache to be alterable?"

Sign In or Register to comment.