Mesh Onion Skinning prototype

Hey Devs,

I’ve started working on a prototype for Onion Skinning meshes in Blender and displaying via overlays. #107641: WIP: Onion Skinning Prototype

The logic goes like this.
Store the evaluated Mesh from frame x
Draw the stored Mesh on frame y with a certain color + alpha

The problem I have is with storing the Mesh
I might be wrong on this, but I shouldn’t store the data on main, because it’s not an object that actually exists in the scene.
That’s why I’ve used Mesh *copy = (Mesh *)BKE_id_copy_ex(NULL, &mesh->id, NULL, LIB_ID_COPY_LOCALIZE); which to my understanding copies the Mesh data to be used at a later arbitrary point.

However my issue is that I get a null pointer error when trying to render that.
So where am I wrong?
Does the copy function not do what I assume it does.
Or does the rendering need data that is in main?
or something I haven’t even thought of. Maybe the whole approach is wrong

3 Likes

I don’t know which specific null pointer error you are running into. But this code is making a copy of an unevaluated mesh datablock and storing it in an unevaluated scene, which is just not integrating with the depsgraph at all. Datablocks in main are not used for depsgraph evaluation or drawing, that happens on copies made by the depsgraph.
https://wiki.blender.org/wiki/Source/Depsgraph

This needs a bigger picture design about where this integrates with the depsgraph, how it’s evaluated, stored, invalidated and updated. And then also how it can have good performance, multi-threaded evaluation.

The design challenges for this are similar to cached animation playback, and probably there should be a shared underlying implementation.

2 Likes

thanks for the reply and for the link to the depsgraph. Still learning all that

for this first prototype I wanted to bypass the depsgraph completely and just store the resulting Mesh on the current frame and render it later. This is probably quite a hack but as a prototype I think it would be fine.
Yes I agree for the final implementation we want to have cached playback first. But that is a tricky topic

If you are saying it’s not possible to bypass this complication I will leave this topic for now and focus on other things

If you want a quick hack, the operator could add an actual object in the scene for each frame, with a copy of the evaluated mesh assigned. And then you can set some flag on that object to mark it to be rendered differently.

I wouldn’t say it’s impossible to make it work when storing them in a custom list as in your patch, but it’s probably not a good use of time to try to figure out all the hacks needed to make that work.