PDA

View Full Version : VPR Bombs Layout, Corrupts Scene



DrStrik9
02-17-2016, 11:46 AM
I might be changing my label from "scene destroyer" to "bug magnet."

After working on a pretty large bullet sim for a day, (2-hour sim calc, 2.15 GB dynacache, scene save takes 50 minutes) I left VPR on while changing the view from camera to front.

BIG mistake.

Apparently, leaving VPR live while changing views is a very bad thing. Layout crashed, and now the scene is corrupted, and crashes Layout on open. :cursin:

This is the THIRD TIME Layout has crashed and corrupted the scene in the last two weeks. LW 2015.3

Another bug reported.

--

I am rather dazed and confused at the moment, to put it mildly. :mad:

DrStrik9
02-17-2016, 09:14 PM
So I rebuilt the scene. (Major deja vu.) This is (hopefully) the last time this will happen. Sim calc is done. I'm saving it now, so dynacache will be written to disk.

From now on, with bullet, I'm going to take extraordinary precautions against more catastrophic failure:

1. Load objects, set up dynamics, calculate the sim
2. Make one preview from one camera of the sim for review
3. Save the scene with dynamics on as a new number with cursor at frame 0 (-001, -002, -003, etc.) -- this saves dynacache to disk
4. Run a backup of the scene versions to a separate drive
5. Save the scene a second time the same way with new number (the first save is insurance for if and when the working scene becomes corrupted)
6. Run backup gain
7. Finish developing the working scene with lights, background, cameras, animation, etc. as per normal
8. Save the developed scene with dynamics off (since dynacache is already saved for that scene number)
9. Run backup again
10. Render various camera views

Somehow, when LW destroys three major scenes in two weeks, it makes one just a bit paranoid. :chicken:

DrStrik9
02-17-2016, 09:26 PM
Mac OS X tid-bit: When saving a large bullet scene, which can take a LONG time, the Activity Monitor (OSX's unix-like list of all current system processes) shows Layout as "Not Responding," even though it is actually saving out dynacache. This temps one to force-quit the operation. But don't do it! It may take more than an hour or two to save a huge dynacache file, so just be patient.

I'm not a programmer, but I suspect there is a "developer thing" that could more accurately report the saving of a bullet scene to Mac OS X so Activity Monitor can report what is actually happening to the user.

DrStrik9
02-17-2016, 09:30 PM
double-post deleted.

spherical
02-17-2016, 10:09 PM
Mac OS X tid-bit: When saving a large bullet scene, which can take a LONG time, the Activity Monitor (OSX's unix-like list of all current system processes) shows Layout as "Not Responding," even though it is actually saving out dynacache. This temps one to force-quit the operation. But don't do it! It may take more than an hour or two to save a huge dynacache file, so just be patient.

Exactly. When an OS doesn't receive anything from the application after a period of time, it (incorrectly in some cases) says Not Responding. Killing the process corrupts the files being modified because they are not yet complete. Just because a robot says something does not necessarily make it absolute.

DrStrik9
02-17-2016, 10:20 PM
Exactly. When an OS doesn't receive anything from the application after a period of time, it (incorrectly in some cases) says Not Responding.

"Not Responding" actually happens almost instantly on OS X when saving a bullet scene in Layout. Since bullet scenes can take extended amounts of time to write dynacache, it would seem prudent for Layout to regularly inform the OS what it is doing. It's a detail, but can become a major "gotcha" if the user doesn't already understand what's happening. While we're dreaming, it would also be great to add a "saving dynacache" progress bar (even if it wasn't perfectly accurate).

magiclight
02-18-2016, 05:00 AM
When an OS doesn't receive anything from the application after a period of time, it (incorrectly in some cases)

It's not in any way incorrect, it's the way it works on both Mac's and windows, when the UI thread is not responding within a few seconds you get "Not repsonding", if the application do not want this to happen the long running operations should not run on the UI thread.

When an application look up the UI thread for a longer period of time the application is not responding (the UI thread is locked so it cannot respond to any messages from the OS), so if the message say "Not responding" this is always correct, it does not mean the application is dead, it just mean the application is not responding at the moment.

ianr
02-18-2016, 05:18 AM
I would report your findings directly to a LW3dG guy,

say Matt Gorner (GUi man) I am sure he'd get to the right Dev.

Best it's fixed now it's only gonna grief up future Revs

lardbros
02-18-2016, 06:57 AM
I would report your findings directly to a LW3dG guy,

say Matt Gorner (GUi man) I am sure he'd get to the right Dev.

Best it's fixed now it's only gonna grief up future Revs

Yep... what he said! :D

DrStrik9
02-18-2016, 08:30 AM
I would report your findings directly to a LW3dG guy,

say Matt Gorner (GUi man) I am sure he'd get to the right Dev.

Best it's fixed now it's only gonna grief up future Revs

I reported it yesterday, and got a nice response this morning saying it is a "great feature request." :+)

jwiede
02-18-2016, 12:09 PM
It's not in any way incorrect, it's the way it works on both Mac's and windows, when the UI thread is not responding within a few seconds you get "Not repsonding", if the application do not want this to happen the long running operations should not run on the UI thread.

When an application look up the UI thread for a longer period of time the application is not responding (the UI thread is locked so it cannot respond to any messages from the OS), so if the message say "Not responding" this is always correct, it does not mean the application is dead, it just mean the application is not responding at the moment.

It's an application _bug_ actually (apps are NOT supposed to run long, uninterruptible tasks on UI thread). Lack of progress bar is also a bug (UI bug, in that case). Both should be filed with LW3DG. If you don't plan to do so, say something and someone else here will file them for you.

DrStrik9
02-18-2016, 12:59 PM
It's an application _bug_ actually (apps are NOT supposed to run long, uninterruptible tasks on UI thread). Lack of progress bar is also a bug (UI bug, in that case). Both should be filed with LW3DG. If you don't plan to do so, say something and someone else here will file them for you.

I don't really care if they want to call it a bug or a feature request, as long as it's fixed. :D And as I said before, I did file it yesterday.

gerry_g
02-18-2016, 01:44 PM
Yes Lightwave and Modo both, long lockouts while app executes at 100% on one thread for all eternity with only option of waiting it out or force quitting, should no be stealing UI in process bad programming, feature request my &$)%& !!

spherical
02-18-2016, 03:32 PM
It's an application _bug_ actually (apps are NOT supposed to run long, uninterruptible tasks on UI thread). Lack of progress bar is also a bug (UI bug, in that case).

Well, I wouldn't class these as a _bug_. Not thorough programming to provide feedback while a known potentially long task is being computed and properly interface with the UI, maybe. Is the application doing something in absence of feedback code that would let the user know that it is still thinking? Yes. But bug? No. That's why it is in the Feature Request column. Isn't there at all, so must be added. Is it annoying? Yes. Is it code that is not working correctly? Not exactly. The code is absent, so it can't have a bug. At least that is how I have come to know bugs over 48 years of programming. I get that now the term is used in an incorrect manner all the time; mostly because the majority of people (not you John) don't really know what a bug is, so they call every unexpected result a bug—even if it is user error. Grinds my goat.

Heck, there are many, many applications that show "Not Responding" in the title bar when they aren't hung at all. Mozilla and Adobe should get a clue in this regard if there is some missing code that would play better with the UI.

jwiede
02-18-2016, 08:53 PM
Well, I wouldn't class these as a _bug_. Not thorough programming to provide feedback while a known potentially long task is being computed and properly interface with the UI, maybe. Is the application doing something in absence of feedback code that would let the user know that it is still thinking? Yes. But bug? No.

Not that it matters, but the reason it is a bug is because blocking for such durations on the UI thread prevents timely processing of potentially time- and power-senstive OS events, etc. Traditionally, blocking the UI thread for even a few seconds was seen as potentially user-intrusive, and we're potentially talking about blocking for much, much longer in this case. There have been admonitions against extended blocking of the UI thread since early Win32. In WinRuntime apps, the OS will even terminate apps which fail to respond to events in a timely manner. This issue is obvious, 100% reproducible pathological behavior by the application, failing to follow OS protocols regarding UI threads, and blocking the app from responding to certain important OS events in a timely manner (incl. keep-alives, pwr mgmt, etc.). Ergo, bug.

spherical
02-19-2016, 02:38 AM
Agreed. Adobe Reader needs a kick in the head, then. That is one application that I see Not Responding more than any other. IOW, LightWave isn't an isolated case.