HD Mesh blender crash script corrupted

[Noname]

When using new HD import feature upon import Blender 2.82a crashes. After restart script is corrupted (issue with script corrupted was noticed before when while importing user kills blender and after restart script is corrupted and is required to reinstall it - error says script files missing in blender add-on panel).

Steps to reproduce:

• Daz - load HD model
• Daz - saze to DUF → export basic data → export HD DBZ data
• Blender → Import saved model

Imports starts than after some time blender crashes.

Best regards

PS. Tested model is G3F Lilith

[Noname]

Tested with G8F HD works fine.

[Alessandro Padovani]

The plugin uses a fair amount of memory to import HD meshes, or any complex scene as well. If your pc runs out of ram I guess the crash may happen. I’d suggest you to keep an eye at the task manager to check it. You may close daz studio and edge while importing HD meshes to save some ram.

Also the memory is not released after importing the HD mesh. I’m told by Thomas that this is because python has no control on ram de-allocation and blender is lazy. So you have to save the HD scene to the blend file then restart blender to get your memory back. This is so for any complex scene.

[Noname]

This is not RAM issue, G8 load correctly, G3 just crashes.

But I did tested RAM usage and crash happens when Blender reaches 3.5 GB so plenty to go to reach 32GB and then it should hit page file with I do have set to auto on Windows host so it should crash when that page file is fully populated (in my case on SSD) so around 190 GB.

[Thomas Larsson]

I can confirm that making HD meshes can lead to a crash on Linux too. For me it happens in the function Mesh.py_data on line 108 in geometry.py. This is a low-level function which builds a mesh without checking the in-data. This function has caused crashes before when the in-data was inconsistent, but it can probably also crash if Blender runs out of memory.

I’m pretty sure that this is an issue with Blender’s memory management rather than with the plug-in. That the problem happens at 3.5GB could suggest that there is some remnant of 32-bit code. Or maybe not.

[Thomas Larsson]

The latest commit prints a message in the terminal window right before and after the mesh is built. This does not fix anything, but at least we know which mesh causes the crash.

[Noname]

Here is log from import crash, base file is same as without HD option and removing *.dbz resolves crash (file loads fine):

Parsing data
Fitting objects with dbz file...
Highdef Genesis3Female 1 87394
Highdef new_gens_V7_4948 1 19631
Highdef Pubic Hair for NGV7_414656 1 414656
Highdef Round Stud Earrings_3358 1 3358
Highdef EverydayUpdo_151676 1 151676
Preprocessing...
Building objects...
TIFFFetchNormalTag: Warning, Incompatible type for "RichTIFFIPTC"; tag ignored.
Build HD mesh for DoD Mom: 87394 verts, 86224 faces
HD mesh Genesis3Female-1_HD built
Dependency loop: lToe lMetatarsals
Dependency loop: rToe rMetatarsals
Build HD mesh for New Genitalia For Victoria 7: 19631 verts, 19472 faces
HD mesh new_gens_V7_HD built
Build HD mesh for Pubic Hair for NGV7: 414656 verts, 196416 faces
HD mesh Pubic Hair for NGV7_HD built
Build HD mesh for Basics Stud Earrings: 3358 verts, 3326 faces
Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF688A14F94
Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF688A14F94
Module  : C:\blender-2.82a\blender.exe

‌

[Thomas Larsson]

The problem was how Daz represents triangles: as a quad where the last entry is -1. So a triangle with corners at vertex 1, 2, 3 is the list (1, 2, 3, -1), and Blender didn’t like the reference to vertex -1. Blender used a similar convention before bmesh, where the last vertex in a triangle was the same as the first.

So the problem should be fixed now.

[Noname]

Import doesn’t crash any more, so issue is fixed. Of course there are other issues like missing UV's but that's expected to not work properly.