Hi Ilia, Thank you very much, I was not aware of that! Cheers!

Hey Ferdinand, thanks again for the quick reply. What we're going to do is basically have a "cache" location, as you said, where we will save the users' textures when they bake the stack. I would also prefer the approach you showed using the document's asset repository, but since the textures might be very heavy, it would probably lead to very large document sizes for a lot of users, especially if they use several textures/have several stacks with textures. I'm working on implementing solution 1.1, using the Message system to move things around. However, thank you very much for the code example, I will probably use something similar with other assets that are not as large as textures. Cheers, Daniel

Hi Maxime, thank you very much for your answer! I wasn't sure if storing things in the global document BaseContainer was a good approach, but it's working well. Cheers, Daniel

Hi @ferdinand, Thank you so much for the comprehensive reply! Given all this I don't think it would make sense to keep trying to unit test this particular part of our code with Python. The last approach you highlighted with testing directly on the C++ side seems like the best option, so I'll give that a try. I'll have to see how to integrate this test with the rest of the unit tests (we have a lot and they're all in Python) but hopefully that won't be too much of a problem. Thanks again for all the help, Daniel

Hi @ferdinand and @Cairyn, thanks for the answers. There may be a simpler way to achieve an effect similar to what we want (for example, by caching the world matrix at the time t) but I'm still thinking of alternate ways to be able to access the full mesh information at time t. Caching the full mesh is probably not a good option since we would have to update that cache every time the mesh is changed at any time before t (since this might change the mesh at t). A possible option is to restrict the usability a bit and always evaluate the mesh at time 0, I'm checking if this is something we can do. Feedback loops could be an issue, but it should never happen that (using the example @ferdinand wrote) P relies on T and T also relies on P in this specific plugin. Also, t should always be a time before the current time, although that might not alleviate this particular problem. In any case, I'm going to go ahead and mark this as solved, I think I got all the information I need to find a solution. Thank you both very much for helping me out, Daniel