Blenderbim crashing when selecting the Bim tool?

2»

Comments

  • Hey @cvillagrasa I just installed the latest Blenderbim-20221004 and unfortunately I stumbled upon the million Ifcbeam bug again, see vid attached, not sure what changed to bring it back?
    Windows 10, Blender 3.3, I can't seem to get it to replicate on Blender 3.2 at the moment

  • Ohh no, does it happen consistently or only sometimes?
    Could you go to .../scripts/addons/blenderbim/bim/module/model/prop.py, line 148, and manually increase the delay?
    It's this line. Say, after changing default=3e-2 to default=0.2 and restarting Blender, does it keep happening?

  • Ohh no, does it happen consistently or only sometimes?

    It happened 3 times in a row then not again,

    Could you go to .../scripts/addons/blenderbim/bim/module/model/prop.py, line 148, and manually increase the delay?

    I'll give that a go !

    Say, after changing default=3e-2 to default=0.2 and restarting Blender, does it keep happening?

    Let you know in a bit

  • Say, after changing default=3e-2 to default=0.2 and restarting Blender, does it keep happening?

    So I made the change to default=0.2 and it still happens pretty consistently,

    So I tried default=0.4 and it happened on the second try
    I tried default=0.5 and it seems to fix it, I can see it doing something, like it loads a beam in and unloads it instantly but the bug doesn't happen, on the fourth try it loaded the Ifc beams

    I tried default=0.6 and it seems to fix it, same thing as .5, on the third try it loaded the Ifc beams
    I tried default=1 and it seems to fix it, same thing as .6, on the third try it loaded the Ifc beams
    I tried default=2 and it seems to fix it, same thing as 1, on the second try it loaded the Ifc beams

    The higher the delay it's supposed to be less likely to bug out, correct? What threshold should I be looking at?

    I tried again on 0.5 because that seemed the most effective but this time it loaded the bug on the second time I tried a new Ifc file

    This is how I test
    1. New Ifcproject with Ifclibrary loaded
    2. n panel
    3. Bim tool
    4. then the bug hits

    theoryshaw
  • Superthanks @Ace for the thorough report!

    On one hand, once that we know that the bug is happening again, if one cause is related in some way to "computational overload", then yes, I would expect higher thresholds to prevent it from reproducing. And thanks to your testing, that's now confirmed. By the way, the single object creation and removal that you are able to see with superhigh delays is exactly what it's supposed to happen when everything works OK (the object is being created in the scene as if you pressed SHIFT + A, it's converted to a Blender asset in order to generate a preview and finally it's unlinked from the scene, hence we end up as before, but with the preview we want to show in the UI, if all of it happens fast enough it's a good solution).

    On the other hand, that doesn't mean that a possible solution to this bug can be to just increase the delay of the timers. Both because it'd be laggier and it wouldn't be reliable for every scenario. Could we mathematically tell whether the bug disappears for all delays >= 0.25 seconds? Of course not. For illustration, I tested it in my system until it worked reliably, but you're finding out it's not at all the case in yours.

    So, I have either to find the real underlying reason why a Blender timer call "evaporates into thin air" for no reason, or to just give up on a nice preview menu showing up the way it's doing it now. If we just execute the Python code sequentially, with no timers, as it was before, that's what was causing this eventual crashes you guys experienced.

    Summary up to now:

    • Calling obj.asset_generate_preview() and right away obj.preview.icon_id can lead to crashes (critical bug).
    • Delaying the call to obj.preview.icon_id by means of timers can lead to never ending + continuously starting timers, creating a ton of nonsense objects (also a critical bug).

    I'll have a thought on all of this! Thanks again for the testing @Ace and @theoryshaw !

    Acetheoryshaw
  • Sorry @cvillagrasa :)
    https://www.dropbox.com/s/8h15rrgufijm3ng/2022-10-07_11-53-17_Blender_blender.mp4?dl=0
    as of...

    Revision: fb6d24b3edc87603476255f6989006f83de5fc13
    Author: fbpyr <73931454+fbpyr@users.noreply.github.com>
    Date: 10/7/2022 6:14:04 AM
    Message:
    add choco alpha version tag, description fixes (#2484)
    

    It's always consistent now, however... that is, if you select the cube, and then go to the 'BIM Tool', it creates that phantom beam. :)

    Ace
  • Thanks for the report @theoryshaw ! I've been a bit distracted from this issue during the last couple of days but I'm aware it's not working quite good at the moment 😅 There are a couple of things I'll try, like queues and modal operators. I'll give it a shot during this weekend.

    Ace
  • There is an alternative approach now in the codebase that is enabled by default that uses a different technique to @cvillagrasa 's implementation. In theory, there are less moving parts and might be more stable, but it would be good to hear if anybody has been experiencing crashes. You'll know if you're testing the newer version if you see wall / profile cross section thumbnails.

    Ace
  • Hi @Moult trying the latest BBim no crashes so far on any blender version. Nicely done!

    Coen
  • Hi @Ace , one question out of curiosity, do you have the BlenderGIS add-on installed?

  • @cvillagrasa said:
    Hi @Ace , one question out of curiosity, do you have the BlenderGIS add-on installed?

    Hey @cvillagrasa I do for some Versions of Blender, I saw... was it you?... Well someone saying they had no problems after uninstalling BlenderGIS

  • Well, the Blender core devs answered @Moult with a first message stating that there shouldn't occur crashes with the original version of the construction browser (the one before this thread). And then, @theoryshaw had crashes again with the recent version of the browser from @Moult, which they tracked down to a conflict when using BlenderBIM and BlenderGIS at the same time.

    So I wonder if the cause from the original crashes was the same...

  • I bet you it is hahah, I am starting to get new 'old' issues on one of my installs, so it's probably BlenderGis, It's just so damn useful

    cvillagrasa
  • Well things are still a bit uncertain. The Blender dev implies that the two times I use while not obj.preview: pass in module/model/product.py is unnecessary. I just tried commenting it out, and indeed it seems to work fine on my machine - I put it there as a conservative, low-tech measure based on reports of crashes.

    We also cannot yet identify the cause of the crashes. For the most recent crash report by @theoryshaw , we isolated it to either caused by a Blender setting, or by a Blender add-on, but we did not isolate it further than that, so we cannot make assumptions about BlenderGIS being the culprit. BlenderGIS was an issue elsewhere which on the surface seems unrelated, but I haven't dug deeper either.

    We also don't know if the crashes from the original version and the current version are caused by the same thing. There are lots of differences. The most significant is that the original version crashes were intermittent, suggesting race conditions, potentially non-fatal garbage memory, or something heavily dependent on a permutation of user events. The current version crash report was a "normal crash" i.e. replicated every single time. This observation correlates with differences in the code - the original had a significant number of moving parts and executed during both a draw context and a timer, so maybe it correlates to the screen resolution, maybe it correlates to the definition of a tick in a timer on a machine, maybe it correlates to the frequency of mouse movement that triggers draw operations, maybe it correlates to the IFC generation (maybe it's an IfcOpenShell crash?) or Blender generation of new objects, or updating the depsgraph (the original created tons of new data), or maybe correlating to the syncing of the undo stack. The current version is significantly more "dumb" and executes in a traditional synchronous manner in an Operator context, and doesn't create any objects. So all those things I mentioned no longer become factors in the crash hunt.

    We still need more testing, I believe.

    Ace
Sign In or Register to comment.