Blender "crash" with Exception_Access_Violation on exporting .babylon

Not sure if this is a bug or I am doing something wrong, but what could cause this error:

========= Writing of JSON file started =========
Address : 0x000000013F65BCA2

From the log it seems to stop at about the same place on cossecutive tries. Tried to export to different disks but crash on both, even on new/empty locations. I am nowhere close to running out of RAM. Might be a bad module tho i guess …

Exporter version: 6.1.1, Blender version: 2.80 (sub 74)

I also se a warning when i open blender from cmd;

Warning: class EXPORT_OT_bjs contains a property which should be an annotation!
assign as a type annotation: EXPORT_OT_bjs.filepath
assign as a type annotation: EXPORT_OT_bjs.filter_glob

Anyone else know what could be wrong ?

First, ignore the annotation warning. Every one is getting that.

I have never seen the access violation. GLTF exporter is built in. Does exporting through it produce the same result?

If you have textures, are you specifying a sub directory that doesn’t exist? Do not know that it must, but something to check.

Also, what is your Os?

the khronos gltf exporter works fine. Had some issues getting the .babylon exporter to work, sometimes it worked and sometimes it did not. But then I tried to “clean” up my scene, getting rid of nodes that needed baking and stuff, and now it stops consistently on that blend file. It seems to stop at around line 650-670 in the log, so i tried removing some objects that was loged as finished earlyer in the log to see if that changed anything, and it seems to do fine until it gets to about 650-670 lines again, so It does not seem to be a specific object that causes the issue either, thats why I was initialy thinking some ram allocation or bad chip issue or something. I am on Win7. I found some reports about this error and blender but seems to be in connection with graphics drivers, which should not be the case here i think…

It seems to create the directories and files fine, atleast as far as it goes, I saw on one atempt that it output a baked texture atlest before crashing.

I can try to move my project to a win10, and see if that helps…

I also tried to run blender as admin, that was a tip somwhere for this error, but that seemed to make no differance

Ok, you mention baking. In 6.1, baking performance was improved in speed by about 10x. This is at a cost of GPU memory. Unfortunately, I do not have a copy of 6.0.x. The repo moved while going to 6.1, but there are other ways.

With a problem like this, “Divide and Conquer” is the way to go.

  1. Get the absolute latest version of 2.80. Your version is probably less than 5 weeks old, after the final API changes, but not into wasting time when they fixed some memory leak last week. This is still beta Blender.

  1. Make a new version of your .blend file (keep the old one). In this version, start to break down things into logical collections. This is done by right clicking on Scene Collection, and picking `New’. You can then drag & drop stuff into the new collections to separate stuff.

A 670 line log file means you a really big scene. Once you are all broken out, try to export each collection individually. Skipping a collection is done by unchecking the box to the left.

You might actually want to keep this organization anyway.

  1. Assuming it is failing in a collection with a mesh that bakes, turn gpu baking off.

I do not have any more for now, but let’s see what has been isolated from this.

I don´t think it is the baking as i stipped most of that out before getting the constant crashes,but I wil double check and do some more testing based on your sugestions and see what i can find. Thanks.

I tried the old “Devide and Conquer” as you said, and finally found the culprit, and after splitting up the collection that was causing problems I managed to export the entire scene again. I should have tried that from the get go but the fact that it seemed to crash on the same “amount”/lines of log threw me of. I had some linking/instancing that I only used in that collection, which I now have restructured , so that might be part of the issue. Thanks for the help. :smiley: