Maybe Blender Partice Instancer Bug, but ....

[enzyme69]

I am making this setup for "procedural flipping". Previously I am using Drivers for this and measure the distance changes. Now I am doing it inside Sverchok.

So basically it is pretty simple:

1. Start with template grid.
2. I duplicate the template grid => this is for deformed grid
3. I measure the original point position with the deformed grid
4. On every point, I create Clones.
5. For every Clones, I transform it based on the distance data.

The thing works perfectly in Sverchok. But supposed I want to have better efficiency, I need to use Instances.

So, I use BMesh Viewer to output the "flipping animation mesh", and then using this as template for Duplication for Particles Instances.

Now this is when I found a "bug".

Somewhat when flipping value goes under or beyond the norm, the resulting Instances is not pointing at anything. It just snap to a weird rotation.

I am not sure if this is Sverchok related or Blender Particles. I am afraid this is Blender Particle + Instancer bug, but it is going to be difficult for me to report this to Blender Developer. I will try anyway. I will ask them to look at this thread.

[enzyme69]

Hmm... it looks perfect when using DupliFace... This seems to be Blender Particles issue when handling Instances and Normal. Or maybe I didn't set it up properly.

[enzyme69]

I reported to Blender Developer, hopefully they can give a nice explanation.

My feeling is that the Blender Particle Instancer got confused and interpolate the "initial" and current normal.

[enzyme69]

Further investigation, using Suzanne head, apparently I need to rotate the head of like 22.5 degree angle.

So this might be the Sverchok "issue". The output of normal need to be rotated or something.

How do we control the Normal Output Mesh from inside of Sverchok?

[enzyme69]

Uh-oh, rendering it out with Dupli Face duplication on top of BMesh = crashes Blender.

https://www.dropbox.com/s/2wr39pydi8c72ij/sverchok_procedural_flipping_011.blend

[enzyme69]

More bugs found: Adding Solidify Modifier to the BMesh Viewer does not seem to work and I cannot seem to render BMesh output.

[enzyme69]

Additional bug: Attach the svCylinder node into BmeshViewer, render = crash Blender.

Attach svCylinder into BMeshViewer, and then quickly create a cube = crash Blender.

Yes, some weird thing going on.

Sometimes when render is succesful, I get this:

And then move it, and = crash Blender.

[zeffii]

There is a reason I disabled selection of BMesh viewer objects, by default initially. Each frame or Each time an update is sent to bmesh node, the object mesh is wiped and replaced -- this means any external reference held by some other part of Blender will have predictably unpredictable results. Especially references to the mesh data.

But referencing the object matrix should safe, that only gets modified not removed+replaced.

Not sure this answers your question, or gives you insight into what you are experiencing.

[ly29]

Theese kind of bugs can be very hard to pin down. The crashing is most likely caused by bmesh viewer somehow, try to turn on print update timings and see what the last updated node is. If bmesh viewer finishes then the scenario outlined by @zeffii is the likely cause.

[zeffii]

I could probably collect and reapply modifiers on each update, but I think the on frame change event should be post frame change for rendering to work right -- I really can't help atm, i'm busy with other stuff.

[ly29]

it is post right now. fromnode_s.py

    bpy.app.handlers.frame_change_post.append(sv_update_handler) 

[zeffii]

maybe pre then? I think post will always be 1 frame behind

[enzyme69]

the crashing bug needs to be fixed first I think. it does not render when I click Animate button for BMesh output rendering. Used to work.

[zeffii]

Knowing something crashes is a good step towards finding a solution, but finding why it crashes happens next. May take time, i'm enjoying the great weather :)

[ly29]

I cannot help find since it doesn't crash for me.

[enzyme69]

@ly29 Oh no, then this is pretty bad. It keeps crashing on me.

This bug does not allow me to render BMesh Viewer mesh at all. Used to work.

Will try again on Mac.

[enzyme69]

I can record every crashing video.

[enzyme69]

Enjoy the nice weather! Just finished raining in Sydney.

[ly29]

Please provide as much info as possible and we will try to track it down. But it can be hard, not only because of the weather

[enzyme69]

Ok, first of all, when I click on "Animation" button to render the BMesh output, it is not stable, it occassionally just crashes Blender without reason.

https://www.youtube.com/watch?v=Q1xhjZDKcig&feature=youtu.be

[enzyme69]

how to "turn on print update timings and see what the last updated node is"?

[zeffii]

@enzyme69 current non-release windows builds are potentially unstable, i've seen Sergey and Ideasman42 reluctantly state this in IRC. "even with no addons installed"

I proposed the other day to make a 'Node Array' or Object instancer - The name is not so important, but the node would handle a very limited subset of what BmeshView does. https://github.com/nortikin/sverchok/issues/208

[ly29]

Do that in the preferences for Sverchok, in blender add-on preferences. It isn't finished yet so you have to turn if off and on every time you start sverchok. Will fix that soonish.

[ly29]

Hmm, in animation mode bpy.context has no selected objects. If I play using alt+a it works but if I play with animation button I get: Failed to update: NodeTree 'Context' object has no attribute 'selected_objects'

From this failure we know two things, the error msg is really bad. And we cannot rely on object selection to be possible... https://github.com/nortikin/sverchok/blob/master/node_BMeshview.py#L284

Not saying that this is the crashing problem...

[enzyme69]

Appears like it crashes if I do something with timeline while it is rendering the Animation.

However, last time when I reported the crashing, it crashes very randomly. I tried it just now to make it crash, but it was pretty stable. Until it crashes for no apparent reason.

https://www.youtube.com/watch?v=l9JWC3FMTWE&feature=youtu.be

I have to test again.

[enzyme69]

Aha... @ly29 @zeffii it's probably something to do with "selected objects" thing that I mentioned the other day.

[enzyme69]

Previously, whenever BMesh Viewer is active, the node will deselect any selected objects, which is not good because when I tried to export OBJ (to export baked OBJ mesh every frame), the exporter just didn't work, because BMesh Viewer keeps on deselecting whatever currently selected.

So, Zeffii did something with it and the deselect is no longer happening, the OBJ exporter mesh is working now.

However, I didn't know if that is causing unstability.

[zeffii]

Failed to update: NodeTree 'Context' object has no attribute 'selected_objects'
Failed to update: NodeTree 'Context' object has no attribute 'selected_objects'
Error: Error setting option flags2 to value fastpskip.

yeah, at rendertime context is not the same context we have normally. I might have a simple solution for that

[enzyme69]

Ok, I don't mind a bit of unstability. Occassionally it is performing okey. Sudden crash that often shocked me a bit.

[zeffii]

in def remove_non_updated_objects( there's one line that assumes bpy.context is permanently the same context. But while rendering bpy.context does not have the same content, ie, it doesn't have an attribute selected_objects . (just think... if we are rendering do we ever need to know which objects are selected?)

[ly29]

Okay, I could now reproduce the crash. not sure what causes it exactly.

# Blender 2.70 (sub 0), Commit date: 2014-04-10 11:49, Hash f93bc76
File written by newer Blender binary (270.5), expect loss of data!  # Error
bpy.context.space_data.context = 'RENDER'  # Property

# backtrace
./blender() [0xfbf104]
./blender() [0xfbf35a]
/lib/x86_64-linux-gnu/libc.so.6(+0x36ff0) [0x7f535466eff0]
./blender(cent_quad_v3+0) [0x18bdf20]
./blender() [0x1565a9c]
./blender() [0x1563c87]
./blender() [0x1564d45]
./blender(object_duplilist_ex+0xcc) [0x156604c]
./blender() [0x134438b]
./blender(RE_Database_FromScene+0x1c0) [0x13454b0]
./blender() [0x13533e2]
./blender() [0x135373d]
./blender() [0x135584f]
./blender(RE_BlenderAnim+0x3c4) [0x13563e4]
./blender() [0x1122fde]
./blender() [0xfcc5fa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e) [0x7f535500ff6e]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f53547329cd]

[zeffii]

One thing we don't want is for Sverchok to be known as an unstable thing in infancy, because as a rule it's quite stable and already great at the things which were part of the Vision.

Animation, while we've attempted to cater to some degree, is not a priority. But we all agree that the potential for parametric driven animation and motion graphic is phenomenal within Sverchok and nodes in general.

Perhaps don't consider any failures with animation as bugs, but more as features not implemented yet - as this is closer to how things are.

[zeffii]

@ly29 bpy.context is different when Blender is not in a render state than when it is.

[enzyme69]

Good point, zeff, I will keep that in mind. Especially when it comes to animated and change in frame, one need to be careful.

[ly29]

It doesn't look like it crashes inside Sverchok, but some interaction with bmesh viewer might trigger the bug. If we can prevent this kind of crashes it is good thing.

@zeffii Yes I get that. The question is to check for that in safe and simple way. I guess try or test for certain kins of context...

[nortikin]

animation curves and integration to animation graph is hard to implement because of C# coding in many places of blender. we can not do that. + context is undocumented properly and it is hard to do itself - to document dinamically changing context

[ly29]

No C#, mostly C and C++ but yes otherwise.

[zeffii]

@ly29 sorry, I didn't see the whole post where you already stated what I said below it. I think sometimes I get only a partial feed because it looks like we talk past eachother sometimes.

[zeffii]

so, yeah

if bpy.context.selected_objects:
    # then we are not in render state
else:
   # use alternative way to collect `selected` objects in the scene.

[ly29]

No worries, It might be my problem, I should stop updating comments and learn to write properly.

[zeffii]

shame github doesn't notify in a popup bottom right, if comments have been updated in 30 second intervals to keep refresh sane. And highlight which comments have have edits, or when the last edit was.

If it pissed me off enough I will write a chrome extention :)

[ly29]

You have to check if it exists with try sadly.

[nortikin]

sadly. yes. but how to color exact node, that has initial error with self.usecustomcolor for user to see error? try for update definition not will work that way.

[zeffii]

uchh :( i'll dig around, probably can find some other way

[zeffii]

actually, we don't ever need to use bpy.context.selected_objects.. --it's a convenience method

[ly29]

@nortikin that can be done in util.py but needs some more work to be usable. mostly to print a much better error msg to restore the default exception which contanins more info than is there right now. It is not a good idea to just use the commented code there. Check do_update_debug it is on my todo list but not working on actively.

@zeffii sounds good

[nortikin]

@ly29 :+1: @enzyme69 good night

[zeffii]

    objects_to_reselect = []
    for i in (i for i in objects if i.select):
        objects_to_reselect.append(i.name)
        i.select = False

[zeffii]

that fixes the render issue, but may will break layouts.

[zeffii]

If you really need to load an old layout that uses bmeshviewer, then appending does work. Loading a .blend with an existing bmeshviewer will close blender.

[ly29]

What causes that crash from how we select objects?