BMesh Viewer doesn't update Skin modifier on frame_change

[zeffii]

I don't think it's ever been possible in an animated way, because effectively the BMV destroys the mesh of each scene.obj it's controlling and and assigns a new mesh to that scene.obj. So if you assign a skin modifier, it will display correctly until you frame_change. The previously held mesh data in the modifier points to invalidated memory locations.

It might possible to get the modifier stack to update, or make BMV aware of modifier stacks. maybe even as simple as sticking an .update somewhere. As a last resort we could store the names and order of the modifiers attached to the prime object, and all other objects would follow, reassigning the modifier stack on each frame.

That's as ugly as it sounds, but no more ugly than creating the objects and assigning a new mesh on each update. The necessity for this to be real-time is unjustifiable imo, as the intention of the frame change is to render stuff in the end. The processing required per frame change event (even in the worst case scenario) is minimal compared the render time of one frame.

If all updates to the BMV were only like shapekeys, then edges+faces would stay the same and only location of vertices per scene.obj would need to be updated. Currently there's no inbuilt awareness of this, though there could be.

I'll think about it

[zeffii]

for example the Screw modifier doesn't have this problem, so ... that's interesting.. Neither does subsurf modifier.

[ly29]

scene.update() is called from the frame change handler since a couple of days. That should help.
The modifiers work low level on the mesh and skin does something special.

[zeffii]

The presence of skin modifier might have to be checked, and vertex radiii set per frame
blender-python-to-access-skin-modifier-radius-data

bpy.data.objects['Alpha_4'].data.skin_vertices[0].data[0].radius[:]
(0.25, 0.25) 

[enzyme69]

Maybe some kind of Cache Node, as if. Just like Mesh Cache.
Maybe the Skin Modifier wants more info, such as Weight of each points.
Maybe Eval can start passing values to this kind of thing ;)

[zeffii]

edit:

I don't think Mesh Cache should be part of this conversation, but I do have ongoing ideas about it. In audo processing we have this term called Freeze or Bounce. When we establish that the we are happy with a part of a chain we force zero-new calculations on it, just bounce to wav and play that in sync with the other live elements of the sound chain. We can easily store mesh data as hidden blender mesh objects, I prefer this than custom (maybe faster) mesh structures. This actively prevents redundant or accidental recalcs. But this is a topic and Issue on to itself so if you want to discuss that further, it best be done in a new issue/thread.

Back on topic, yeah eval will do it, but right now we don't specify the order in which nodes operate (rather it is implied by distance to an end point or some other meaningful directedness). So if bmeshviewer changes at time X and the Eval node updates before time X the update is invalidated..(was useless)

That would be solvable, but first you have to be able to:

skin_vertices.foreach_set("radius", radii_list)

So far I have not succeeded. The problem is once the skin modifier is affected by a frame_change, there is no data in skin_vertices. In fact, I spent longer writing this response than trying to get skin_vertices working on previously invalidated mesh...

[ly29]

This is general problem with all side effects.
Right now the order of evaluation is from the node network, no additional logic is in place. Separate parts are evaluated per node group but the order between them isn't guaranteed.
The same with node groups/layouts.
Cache comes after #152 in all realistic scenarios.

[zeffii]

@ly29 agreed.

Focus of this thread should be bmeshviewer and skinmodifier.

[ly29]

I wonder if it is possible stop using bpy.ops and skip the whole select/deselect thing?

[zeffii]

I've been careful to avoid bpy.ops in as many places as possible. yes, not using bpy.ops would simplify a few things there with regard selections..

[zeffii]

it's also probably possible and desirable to use obj.data.from_pydata([],[],[]) directly instead of first making a bmesh

[zeffii]

removing bpy.ops now

[ly29]

👍

[zeffii]

9483a5e

[zeffii]

I don't think the skin_modifier issue is something that can be fixed nicely, and i've had no response from #blendercoders to my questions. I'm not prepared to implement further kludges just to get skin modifier working.

I'll have a go at using from_pydata instead of bmesh_from_pydata, it's something i've wanted to do for a while, but I doubt it will fix the skin_modifier mesh invalidation. so..

[zeffii]

by further kludges i mean

• check each mesh for skinmodifier
• if skin modifier, store some reference to the obj
• upon recreation remove the skinmodifier and place a new one in that position.

not sure it would need to deal with a plurality of skin_modifiers per object... ?

[ly29]

Other modifiers seems to be working, skin modifiers does something wrong I think. Might not really be a bug as far the blender devs see it but for our purposes it is.

[zeffii]

yeah, skin_vertices is a unique structure I think it is also read-only . To clarify, this means the structure is assigned or updated by blender once, and has a certain size, until blender updates it again from edit mode. The only interaction we can have via python is - if the skin_vertices are present we can change the radii, that's all.

But after Bmesh viewer overwrites a mesh, the new mesh doesn't have skin_vertices with assignable radii

[ly29]

It seems to be working in quick testing.

[zeffii]

what does?

[ly29]

The updated bmesh viewer in 9483a5e

[zeffii]

yeah - maybe deserves a version bump to get testers

[zeffii]

i thought you meant skin modifier

[enzyme69]

Bmesh worked with Skin Modifier at some point, but cannot remember when
and hard to proof. I remember it plays as animation, it disappeared when I
scrub the timeline, but if I go to frame one and let it runs, it animates
and renders with Skin Modifier. So, I thought at the time: maybe this is
the behaviour we have at the moment.

but just today when I tried it with the snakes setup, I realized the Skin
Modifier behaviour is different. works for a frame only, but not for
changing frame.

When dealing with Skin Modifier for many edges, I usually merge the edges
and then do "mark root" so that each edge has one root.

I guess for now, I will just MDD Cache it. best solution.

future wishlist: SV Sweep along Edge ala Curve. with UV.

sorry causing additional extra questions. can shelf this one until you
figure out another way.

would be nice when it works, since we already have vectorized lines now too
:)

[ly29]

If it has worked it would be interesting to know the combination of sverchok and blender.

[zeffii]

https://developer.blender.org/rB92733179aee8d7997c843149dfb640a508ade647
recent changes have been made.. in more areas than here

[ly29]

One would think it would be sane for the skin modifier to regenerate the skin vertex data if it can't find it...

[ly29]

should be an easy fix with horrible performance.

[zeffii]

maybe instead of overwriting the mesh data, which I currently do - I could do a different method to update. But no guarantee that this would contribute to a working skin_modifier.

A mesh outputter which restricts the mesh-data to a single length, would be possible.

[zeffii]

i'm closing this till there's more useful information about it.