[fixed] Import OBJ from Blender,exported as selection,without having "join objects"

[Extrudeface]

Wings soft crash (does not import the model and a message appears, is not a fatal crash) when importing OBJ from Blender, having exported from there as "selection only"

True that is an improper way of exporting a mesh, probably, but a lot of people wont realize what's happening. Not 100% sure (could be some export setting from Blender OBJ's exporter, but strongly doubt it) but seems you can overcome the issue if instead of just selecting the meshes you want (to export the OBJ from Blender marking "selection only"), and hitting export (had played with the several objects/groups export settings) one hits in Blender ctrl + j to join the meshes (is not a physical melt of vertexes), then the "internal error" notification from Wings wont happen, neither the crash dump. It does not crash Wings in a fatal way, lets you work with it but recommends restarting it. Crash dump below, short version only, as I understood the long should be only provided under request. Meshes where closed, just cubes. Sorry, can't provide the model. It did seem to happen with Wings 2.17, but not with Wings 2.15.
Windows 7 Home Premium, 64 bits. GTX 1050 2gb. i7 860. 8gb RAM. HD 7200rpm.

Dump written 2018-11-17_10-39
Version: 2.1.7
OS: Windows 7 (build 7601, Service Pack 1), 64-bit edition
GPU: NVIDIA Corporation | GeForce GTX 1050/PCIe/SSE2
Window: geom
Reason: function_clause

Short stack trace:
[{wings,command_1,2,
[{file,"c:/Users/familjen/src/wings/src/wings.erl"},{line,746}]},
{wings_develop,time_command,2,
[{file,"c:/Users/familjen/src/wings/src/wings_develop.erl"},
{line,79}]},
{wings,raw_command,4,
[{file,"c:/Users/familjen/src/wings/src/wings.erl"},{line,629}]},
{wings_wm,handle_event,3,
[{file,"c:/Users/familjen/src/wings/src/wings_wm.erl"},{line,973}]},
{wings_wm,send_event,2,
[{file,"c:/Users/familjen/src/wings/src/wings_wm.erl"},{line,939}]},
{wings_wm,do_dispatch,2,
[{file,"c:/Users/familjen/src/wings/src/wings_wm.erl"},{line,840}]},
{wings_wm,dispatch_event,1,
[{file,"c:/Users/familjen/src/wings/src/wings_wm.erl"},{line,747}]},
{wings_wm,get_and_dispatch,0,
[{file,"c:/Users/familjen/src/wings/src/wings_wm.erl"},{line,651}]},
{wings,init_part2,2,
[{file,"c:/Users/familjen/src/wings/src/wings.erl"},{line,104}]},
{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]

[micheus]

Crash dump below, short version only, as I understood the long should be only provided under request.

You always can try to attach the crash dump file (it may have some limitations because of its size, but you can try )

So, please, if you can provide it maybe can be easier to know what happened because this short version isn't tell me much about the problem.

I can download an install Blender to generate a test file, but it's possible that I cannot be able to create the situation you have when experienced the crash. So, if you could create a simple test file which results in the crash I would be grateful.

[Extrudeface]

Long story short : Totally hunted at least the issue and quick workaround ... While not newbie proof as a solution, just not trusting on the OBJ exporter and selecting a bunch of meshes without joining, setting "selection only" is gonna make a proper group or object (even if marked the other setting for that!) that Wings can import without errors, as it wont. Or at least, not at this huge scene scale (maybe is unrelated).

I tested that meshes can be totally separated (several cubes in this test) , but if select them all, hit ctrl + j to join the objects (which in blender is not a boolean, meshes keep disconnected), be sure the now single object is also selected, export just the same ("selection-only"(non default) , and etc, pretty much defaults in that OBJ exporter) as I've done with the file causing the error, if ctrl+j joined, it will open without triggering the error message. Still, the problem of the massive memory or whatever prob yet happens later on (my other bug I reported today, http://wings3d.com/forum/showthread.php?tid=2712 ). [as mentioned, none of these bugs are stopping my work a single bit, just reporting]

So, I am attaching a zipped file, containing :

error.png --> the notification error it triggers if not ctrl + j in blender.
test.blend --> blender scene file which am using to provide these test files
scene.png --> settings needed in blender to actually "see" something, as if not, at that size the clipping (far and near scene clippings) wont let you see anything. (settings areas highlighted)
test.obj and test .mtl --> The exported obj file that triggers the error in Wings.
test_joined.obj and test_joined.mtl --> a file with ctrl+j applied to the meshes, so at least it will not trigger a error message window (the large scene wont be really something that can be handled, tho, as explained in the other report-thread ).
log_window.txt --> output in the Wings3d log Window, inside wings 3D UI, which I could select all + copy in one of the tests with this test scene.
wings_crash.dump ---> crash dump produced by this when not doing the ctrl + j objects join, and importing the obj in wings.

[micheus]

Extrudeface, thanks for the information and files.

In regards to the test.obj file we can experience a real bug when importing that file. Thanks for report that.
[EDIT] I took a look in the current code and the problem was already fixed. it will be available soon in the next release.

As for the scale/view issue, you have the option to scale down the objects during the importing process. By using the file you provided me (test_joined.obj) a value equal or less than 0.001 was the value that Wings3D started to handle the object properly - be able to select elements. Something we may need to find a solution.

Because of the need to put the camera too far from the origin, it's "mandatory" to hide the Ground Plane before you start to work on this scene. That is causing the system overload when you try to frame the scene as reported in your thread Memory problem (freezes system) when framing a selected OBJ of a huge scale 2.17,2.15.

In order to be able to see this enormous scene you have to adjust the viewer clip, which you can do in View->Camera Settings and changing the Far Clipping Plane parameter from 10000.0 to a value like 1000000.0. The Near Clipping Plane may need to be increased proportionally in order to avoid strange artifacts on screen.
That should allow you to properly frame your scene.

[Extrudeface]

Thank you very much, Micheus, just took notes from your explanations, will apply to every scene of this kind (although seems a lot of it has been fixed. ) . I am sorry that I lost track of this issue, I'm a disaster some times :S (right now messing around with the notification settings, as I don't visit the forums so much, solely for time lack, as I really like these forums).

I'm specially glad if it helped to detect some detail.

(not replying the other thread, so not to bump two old threads, but I wanted to express my gratitude and apology, at least.)

Cheers,

[micheus]

No problem and yes, some zoom issues were addressed.