Crash on OBJ mesh import on macOS 10.15.2

[virtualritz]

To reproduce:

1. Open Ready
2. File->Import Mesh... (knotty01.zip)
3. Run a pattern on the surface of this mesh
4. Bang!

The OBJ was generated in Wings3D.

Process:               Ready [38642]
Path:                  /Applications/Ready-0.9-Mac/Ready.app/Contents/MacOS/Ready
Identifier:            Ready
Version:               0.9 (0.9)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Ready [38642]
User ID:               501

Date/Time:             2020-01-02 03:36:16.626 +0100
OS Version:            Mac OS X 10.15.2 (19C57)
Report Version:        12
Anonymous UUID:        CB1ADE6D-EDCD-C07B-6E3E-5F914BF52197

Sleep/Wake UUID:       82A6A795-9078-4E97-A2CD-5DADBEAD2FCD

Time Awake Since Boot: 49000 seconds
Time Since Wake:       1300 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib          0x00007fff7070e7fa __pthread_kill + 10
1   libsystem_pthread.dylib         0x00007fff707cbbc1 pthread_kill + 432
2   libsystem_c.dylib               0x00007fff70695a1c abort + 120
3   com.github.gollygang.ready      0x000000010791e129 wxAbort() + 9
4   com.github.gollygang.ready      0x00000001079bde7a wxEvtHandler::WXConsumeException() + 154
5   com.github.gollygang.ready      0x00000001079bddb0 wxEvtHandler::SafelyProcessEvent(wxEvent&) + 32
6   com.github.gollygang.ready      0x00000001078abb9b wxMenuBase::DoProcessEvent(wxMenuBase*, wxEvent&, wxWindow*) + 139
7   com.github.gollygang.ready      0x00000001078aba74 wxMenuBase::SendEvent(int, int) + 196
8   com.github.gollygang.ready      0x00000001077c4569 wxMenu::HandleCommandProcess(wxMenuItem*, wxWindow*) + 121
9   com.apple.AppKit                0x00007fff36377018 -[NSApplication(NSResponder) sendAction:to:from:] + 299
10  com.apple.AppKit                0x00007fff36484f52 -[NSMenuItem _corePerformAction] + 312
11  com.apple.AppKit                0x00007fff36484cce -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 106
12  com.apple.AppKit                0x00007fff364d5b20 -[NSMenu performActionForItemAtIndex:] + 114
13  com.apple.AppKit                0x00007fff364d5aa5 -[NSMenu _internalPerformActionForItemAtIndex:] + 82
14  com.apple.AppKit                0x00007fff364d58ec -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 101
15  com.apple.AppKit                0x00007fff36467770 NSSLMMenuEventHandler + 908
16  com.apple.HIToolbox             0x00007fff37a9a711 DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1419
17  com.apple.HIToolbox             0x00007fff37a99ae0 SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 338
18  com.apple.HIToolbox             0x00007fff37aaf048 SendEventToEventTarget + 39
19  com.apple.HIToolbox             0x00007fff37b0ef24 SendHICommandEvent(unsigned int, HICommand const*, unsigned int, unsigned int, unsigned char, void const*, OpaqueEventTargetRef*, OpaqueEventTargetRef*, OpaqueEventRef**) + 368
20  com.apple.HIToolbox             0x00007fff37b35c0e SendMenuCommandWithContextAndModifiers + 45
21  com.apple.HIToolbox             0x00007fff37b35bb3 SendMenuItemSelectedEvent + 339
22  com.apple.HIToolbox             0x00007fff37b35a07 FinishMenuSelection(SelectionData*, MenuResult*, MenuResult*) + 96
23  com.apple.HIToolbox             0x00007fff37b36433 MenuSelectCore(MenuData*, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 603
24  com.apple.HIToolbox             0x00007fff37b3613c _HandleMenuSelection2 + 452
25  com.apple.AppKit                0x00007fff3630b1b5 _NSHandleCarbonMenuEvent + 215
26  com.apple.AppKit                0x00007fff3630b022 _DPSEventHandledByCarbon + 54
27  com.apple.AppKit                0x00007fff36131cda -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2962
28  com.apple.AppKit                0x00007fff361233ae -[NSApplication run] + 658
29  com.github.gollygang.ready      0x000000010780b21e wxGUIEventLoop::OSXDoRun() + 174
30  com.github.gollygang.ready      0x00000001079a6efc wxCFEventLoop::DoRun() + 44
31  com.github.gollygang.ready      0x000000010793d87e wxEventLoopBase::Run() + 158
32  com.github.gollygang.ready      0x000000010791ba73 wxAppConsoleBase::MainLoop() + 99
33  com.github.gollygang.ready      0x00000001077d472a wxApp::OnRun() + 26
34  com.github.gollygang.ready      0x000000010796c0d3 wxEntry(int&, wchar_t**) + 131
35  com.github.gollygang.ready      0x000000010767af20 main + 48
36  libdyld.dylib                   0x00007fff705c77fd start + 1

[...]

Model: MacBookPro11,1, BootROM 157.0.0.0.0, 2 processors, Dual-Core Intel Core i5, 2.6 GHz, 8 GB, SMC 2.16f68
Graphics: kHW_IntelIrisItem, Intel Iris, spdisplays_builtin
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x802C, 0x384B54463531323634485A2D314736453120
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x802C, 0x384B54463531323634485A2D314736453120
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x112), Broadcom BCM43xx 1.0 (7.77.106.3 AirPortDriverBrcmNIC-1435.3)
Bluetooth: Version 7.0.2f4, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM0512F, 500.28 GB
USB Device: USB 3.0 Bus
USB Device: Apple Internal Keyboard / Trackpad
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
USB Device: 2.4G Wireless Mouse
Thunderbolt Bus: MacBook Pro, Apple Inc., 17.2

[timhutton]

Thanks for reporting this. It happens on Windows too, with this OBJ.

There's something about that OBJ that vtkOBJReader doesn't like. If I import the OBJ into MeshLab and then export it back to OBJ with just verts and faces then it works fine in Ready. (Try: knotty01_recoded.zip)

Looking at the code for vtkOBJReader.cxx, it makes sense - it doesn't support the f 1// 6// 1343// 1296// format that your OBJ uses.

~I'll take a look at filing this as a bug in VTK.~ In the meanwhile you have a workaround - either re-encode the OBJ or try a different format.

[timhutton]

And just a note to say that for best results in Ready you probably want to subdivide your mesh a little first. e.g. in MeshLab:

Filters > Remeshing... > Turn Into a Pure-Triangle Mesh
Filters > Remeshing... > Subdivision Surfaces: Loop

[timhutton]

Of course Ready shouldn't crash. And looking into this a bit more, it seems we should be catching these sorts of errors - Paraview (which uses VTK) gives a polite message when trying to load this file:

ERROR: In C:\bbd\7cc78367\build\superbuild\paraview\src\VTK\IO\Geometry\vtkOBJReader.cxx, line 590
vtkOBJReader (00000159E9F42C60): Error reading file near line 1352 while processing the 'f' command

So Ready should do the same, at the very least.

[virtualritz]

Maybe Ready could also offer automatic triangulation on import?

[timhutton]

Hi @virtualritz. That wouldn't help in this case though - vtkOBJReader just can't read this kind of OBJ file, because of the format of the f lines.

~I think the format of the OBJ is technically valid so it's a bug in VTK. Until that is fixed it's just a question of how Ready handles the error. (We could write our own OBJ reader but I'd rather not go down that route.)~

[timhutton]

Another possibility is that this is a bug in Wings3D - maybe that f 1// 2// 3// thing isn't valid after all. See this discussion: http://www.wings3d.com/forum/showthread.php?tid=865

[timhutton]

From the next release, Ready will print an error message in this situation instead of crashing.

The OBJ format issue is either a bug in Wings3D or in VTK or both. Or possibly neither, if there's no agreement on what the OBJ format means.

[virtualritz]

The original OBJ spec is indeed not clear iff 1// is a valid or invalid OBJ token. It says double slashes are used when the texture index is absent as in f vi//ni where vi and ni are the vertex- & normal indices. But it doesn't explicitly say that having trailing double slashes is invalid.

I have been using Wings3D since 2003. As a VFX professional I imported meshes from this app into every major DCC app. Maya, Houdini, XSI, etc. No crashes/errors/issues.

I've written several OBJ parsers myself and they've always been dealing well with this specific syntax. My MacBook Pro running Catalina previews the Wings3D OBJ files in the macOS Finder just fine.

But the strongest argument is this: the Maya OBJ importer was based on the original Wavefront OBJ importer because Maya was created by Alias|wavefront before the latter got bought by Autodesk, many years later.

IMHO, if the OBJ reader of the format's inventor eats it w/o hiccups so should any good 3rd party one. :)

[timhutton]

@virtualritz I'm sympathetic to this viewpoint. I agree that the spec isn't very clear. But there are clear examples in the spec of vi-only faces and so I think it makes sense for Wings3D to follow that since there's no reason not to. ("Be conservative in what you output...") Let's see how they respond.

I think there's an argument to be made that vtkOBJReader should accept f vi// just to keep the peace ("...and liberal with what you accept.") given that there is at least one piece of software in the real world outputting this format and many packages accepting it, as you helpfully point out. But the place for that discussion is on the VTK issue tracker, not Ready's. We are downstream users of VTK in this case, along with ParaView and many other pieces of software. That's why I have closed the issue here (now that we no longer crash).

[virtualritz]

Indeed. :) I filed an issue upstream here.