[fixed] Memory problem (freezes system) when framing a selected OBJ of a huge scale

[Extrudeface]

Wings 2.17 stable.
Windows 7 (build 7601, Service Pack 1) Home Premium, 64 bits, GTX 1050 2GB, i7 860 (2.8 GHz, 4c/8t, 1st gen 2009)), mechanical HD 7200 rpm (Seagate).

Probable memory problem (freezes system) when framing a selected OBJ (imported *.OBJ from Blender) of a huge scale. (I was not paying attention to scale, but seems I was exporting a model in a 2.5 million scale in Blender units, lol). When importing, it imported fine, but once hitting ctrl + a to select all objects, to frame it with shift + a, it gets (edit: probably gets into the loop when the framing action, shift + a ) into an intense memory loop (hard drive starts spinning quite non stop, no ctrl +shift+escape will load the task manager, no response other than cursor move, can't execute anything), and freezes all except the cursor. I can get out of most system crashes, yet these 2 times had to do a hard restart of the machine (meaning, needing to use the switch ON/OFF button). Simply seems the loop it gets into is too intensive in resources, somehow. I believe is when trying to frame the model with shift + a, but could have been triggered from before, with ctrl + a. As mentioned, I believe can be produced by exporting the OBJ in such a huge scale from Blender. Sorry, no crash dumps. Am subscribing to these 2 bug reports threads I made today, in case I'm needed at some point in time for these. No biggie for me, as I can avoid the issues. Just in case helps.

EDIT: I believe the trigger is the huge scale at which was exported from Blender, and then trying to frame the selected objects inside Wings.
Edit 2 : Seems shift + a (I mean, FRAME), has some problems in 2.17. Over a cured file, working fine, using it, crashed wings with the shift a, this time the message not allowing to close wings normally or save, needed to kill the erl process. (still, can be related with the quite non common scene scale)As a reminder, I also detected t his in 2.15.
Edit 3 : "Aim" (a) seems not to have problems.

[micheus]

Thanks for report us

Edit 2 : Seems shift + a (I mean, FRAME), has some problems in 2.17. Over a cured file, working fine, using it, crashed wings with the shift a, this time the message not allowing to close wings normally or save, needed to kill the erl process.

In this case you probably get a dump file or some information in the Console window, maybe?

If the problem is related to a big scale, maybe if you use the Tools->Unitize then the problem can go on.

[Extrudeface]

It happens with "A", too (aim). (edit: and reset view)

Oki. I'm preparing a very complete post in the other report (the one about OBJ import) . Is very related with this one, as is same type of blender scene. The other case (the actual import stage) I have it more ironed, but with this one is less than I can do, as it seems that my total crash was... probably graphic card memory that gets totally stuck (or whatever in the card or something OS-graphic related, card involved or not). It can't redraw. Whole Wings3D window can't paint any change, the thumbing rotation wont rotate the axes in the corner, and cannot even open the log window, neither any window, and nothing in menus highlights on mouse over. Luckily, the rest of the system (my Windows) responds, this time. But instead of killing erl, this time waited quite, and it finally reacts, I see the actions I did taking place (a RMB over the 3D space, etc) Then I could open the log window, this was all the content :

wings-2.1.7
Reading preferences from: c:/Users/.../AppData/Roaming/Wings3D/Preferences.txt
wings_wm:837: Dropped Event autosaver: redraw

There is no crash dump generated with this.
Doing the unitize thing does not solve the problem (practically unresponsive, but with patience I can -this time- quit the app, etc).

Consider all this is with an extreme case of a really crazy scene with a 3.5 millions as dimension in the object, related to Blender unit, exported as OBJ and imported into Wings. I had happened to be just randomly in such a scene while making a project's concept freely, but I thought could be a good case to check if is there something going on.

EDIT :Actually, not sure if it just fills up card memory or whatever-the card thing, in another instance it really leaves the system unresponsive, checked the task manager, and the erl.exe process was taking almost 6GB (5.76, and I believe, growing) of my poor 8GB RAM (this tends to kill the machine). So, it can't redraw the windows app window, but it also takes huge system resources. Again, I guess is such a crazy scene scale. I believe maybe is when there you tell it to frame an object. To do the operation in such scene. It happens with AIM, FRAME, and reset view.

[micheus]

As I already posted in your other thread, that is because you need to put the camera too far from the origin (due to the high scaled scene) and at this scale the auto-grid feature becomes a problem.
So, it's "mandatory" to hide the Ground Plane before you start to work on a scene big like this.

It's a problem that may need some attention to be fixed/workarounded.