LoopCut also causes crash

[MasterJames]

Here is another crash error! When these happen the display screen starts drawing blank in odd locations etc. some kind of super nasty GL disruption.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Users\Everybody\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\a
ddons\retopoflow-master\modaloperator.py", line 172, in draw_callback_postpixel
    self.handle_exception()
  File "C:\Program Files\Blender Foundation\Blender\2.79\scripts\modules\bpy_typ
es.py", line 601, in __getattribute__
    properties = StructRNA.path_resolve(self, "properties")
ReferenceError: StructRNA of type CGC_LoopCut has been removed

[vxlcoder]

Thanks for the report, @MasterJames. In order to debug this issue, I'll need a little more information on how to reproduce this bug.

If possible, can you post a screenshot?

Can you explain how to reproduce the problem?

Also, the exception copied above happened after the first crash, so it doesn't explain what caused the problem. Was there more info in the terminal before this?

Thanks!

[vxlcoder]

Is this happening in RetopoFlow 1.3 or 2.0 beta?

[MasterJames]

version, 1.3.2 yes similar crash to #470 I did notice that there was more to see in the crash log after the fact I didn't think it would show more useful stuff but would aspire to pass it on with screenshots when it happens again. [Not really using it right now.]

Tried to reproduce but I think it's partly random maybe it needs a large mesh and then a timing issue.

I get things like this easily enough but it's not the same, doesn't crash, but might be related.

RetopoFlow Shader Info
  attribs: dotoffset, offset
  uniforms: clip_start, perspective, object_scale, clip_end
RetopoFlow updater verbose is enabled
RetopoFlow Updater: Read in json settings from file
2018-05-18 01:40:51.323 DEBUG:  updateTarget:Sphere
2018-05-18 01:40:55.844 DEBUG:  updateTarget:Sphere.001
2018-05-18 01:41:07.406 DEBUG:  updateTarget:Sphere
RetopoFlow updater: Running background check for update
2018-05-18 01:41:15.980 DEBUG:  updateTarget:Sphere.001
2018-05-18 01:41:15.980 DEBUG:  updateSource:Sphere.001
EXCEPTION (<class 'ValueError'>): vert_splice(...): verts can't share a face
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\
addons\retopoflow-master\op_polypen\polypen_modal.py
000 1000:handle_action_selface() bmesh.utils.vert_splice(bmv, bmv_opposite)
001 0795:handle_action() return self.handle_action_selface(context, eventd)
002 0393:modal_wait() return self.handle_action(context, eventd)
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\
addons\retopoflow-master\modaloperator.py
003 0245:modal_main() nmode = self.FSM['wait'](context, eventd)
004 0300:modal() nmode = self.FSM[self.fsm_mode](context, eventd)

[MasterJames]

As a side note (feature request) I've noticed it's annoying when maybe I move a segment and one of the points is somehow below the source mesh and can't be selected. You have to go into edit mode and pull the vertex up above surface to regain control. I think maybe an option of setting a distance offset would be good as that can make the baking of normals better I think. It's so nothing falls below the original baking surface via smoothing etc. and has to be raised in the normal map. If that makes any sense to you great. Maybe there is a warning or a way to apply a correction in the areas where it's low. As well as a pick through to lost point option, maybe a salvage lost point selection modifier. How about away to move the selection from an edge to the point you can't select. Ctrl-Arrow if single edge selected, the selection moves to the left or right point/vertex depending on which arrow you select. If same from a point to an edge you could move the selection around, with up&down to, if selection at a quad apex you could move the selection those ways too.

Super useful tool. Much thanks to you.

[MasterJames]

Got another error

EXCEPTION (<class 'IndexError'>): list index out of range
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\retopoflow-master\op_loopcut\loopcut_data.py
000 0119:find_face_loop() self.face_loop_fs = loop_faces[0]
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\retopoflow-master\op_loopcut\loopcut_modal.py
001 0189:hover_target() self.loopcut.find_face_loop(self.trg_bme,test_edge)
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\retopoflow-master\op_loopcut\loopcut_ui_modal.py
002 0060:modal_wait() self.hover_target(context,eventd,settings)
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\retopoflow-master\modaloperator.py
003 0245:modal_main() nmode = self.FSM['wait'](context, eventd)
004 0300:modal() nmode = self.FSM[self.fsm_mode](context, eventd)

[MasterJames]

Here is another one...

EXCEPTION (<class 'ValueError'>): faces.new(...): found the same (BMVert) used multiple times
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\retopoflow-master\op_polypen\polypen_modal.py
000 0630:create_face() bmf = self.tar_bmesh.faces.new(lbmv)
001 1135:handle_bridge_nearest() bmf = self.create_face([bmv0, bmv1, bmv2])
002 1014:handle_action_selface() return self.handle_bridge_nearest(context, eventd)
003 0795:handle_action() return self.handle_action_selface(context, eventd)
004 0393:modal_wait() return self.handle_action(context, eventd)
         C:\Users\James\AppData\Roaming\Blender Foundation\Blender\2.79\scripts\addons\retopoflow-master\modaloperator.py
005 0245:modal_main() nmode = self.FSM['wait'](context, eventd)
006 0300:modal() nmode = self.FSM[self.fsm_mode](context, eventd)

I've come to realize, (well I forgot temporarily I suppose) the importance of remembering to check quad distortion, so when 4 points that make a square polygon are not aligned in a plane, bad shyt happens.

I earlier recommended some ideas about using arrow keys to shift selection around for managing lost points. I now remember it's in BMesh when you say keep 'faces' above source mesh, and now I'm thinking it would be nice to have that as well as align all points of quads. I guess they would work together to try and snap points to the surface is good but to keep a face or quad optimized it would require maybe at least an option to not allow distortion of polygons. so some complex optimization relative the normal etc. not so easy but these are likely the sources of these problems it just starts getting messy (so not surprising it can crash in code too). I've found myself triangulating when normally retopo is nice with all quads. Further on the Web and THREE JS you can do a subdivision there, keeping the file smaller in transit. Maybe subdividing helps with these issues then, but it's more susceptible to the distortion issues on the web I think.

Also if you could visualize the distortion as color like you can in edit mode via "Mesh Analysis" Distortion while in Polypen one could save grief flipping back and forth trying to find culprit polygons to split or hope the points snap to the surface when moved would find an aligned point.

[vxlcoder]

thanks for the details, @MasterJames !

the distortion visualization is an interesting feature request. if you would, please open a new issue for this.

When 2.0 is officially released (beyond beta), we're planning to remove the 1.3 tools, because they have some quirky code that's hard to debug. RF 2.0 was built from scratch to handle (better) cases like these. Please try 2.0, and let us know if you continue to find bugs. If PP 2.0 is missing features from PP 1.3, let us know that too. At this point, unless I've totally missed something, PP 2.0 should have all of the same features as 1.3.

If I get some time, though, I may poke around in the PP 1.3 code to see if I can find the source of the bug.

[vxlcoder]

I believe this issue applies to v1.x only, so I'm going to close this issue now that v2.0 is officially released (see release/2.0.0 branch or Blender Market page). If this is still an issue with v2.0, please reopen, and post more details. Thanks for reporting this issue, and we look forward to seeing how v2.0 helps your retopo workflow!