PDA

View Full Version : [POLL] How often does LW2015.3 crash for you?



jwiede
01-08-2017, 07:16 PM
There appear to be two distinct "camps" w.r.t. LW2015.3's stability, so I'm investigating whether different tolerances for "stability" are the distinction, or whether customers are really experiencing such broad differences in stability.

For clarity, a "crash" constitutes either "vanish to desktop", "crash reporter occurs", or lasting hang such that "force quit" was needed.

hrgiger
01-08-2017, 08:08 PM
It might have been helpful to ask in some way if you use a mac or pc. I'm on pc and crashes are infrequent and when they do happen, it seems to be pretty easy to pinpoint a repeatable reason(though not always). I won't count today when I crashed 6 or 7 times trying to open a file from 3 versions ago.

Greenlaw
01-08-2017, 08:30 PM
I'm not sure the results will be very accurate, at least if many users are like me. 'Crashiness' depends on what I'm doing with the software. I might go a few weeks without seeing a single crash, and then some particular task I'm doing might have Lightwave crashing a few times during the day.

For the most part, 2015.3 has been pretty stable for me though. (I chose 'once every few days'.)

jwiede
01-08-2017, 09:37 PM
It might have been helpful to ask in some way if you use a mac or pc. I'm on pc and crashes are infrequent and when they do happen, it seems to be pretty easy to pinpoint a repeatable reason(though not always). I won't count today when I crashed 6 or 7 times trying to open a file from 3 versions ago.

I'll cover that in a follow-up, but first want general results to see any "peaks" (presuming we get a decent sample, anyway).

Sensei
01-08-2017, 11:30 PM
I don't remember when it crashed by itself.
But actually it's Modeler and Layout, two different apps.

That also gives idea to make general log file, which will contain tools, command, and actions done by user.
By recording such logs, and then comparing with other users logs,
it would be possible to find out bugs caused by trashing memory (which are revealed much much longer than they really happened when trashed memory is used by app f.e. exit)..

prometheus
01-08-2017, 11:53 PM
had to vote for once every hour, but the poll can not accuratly describe the frequence I guess, sometimes itīs more than once every hour, sometimes itīs not every hour...depends on.
What I do know for me the lw 2015 version has been the worst ever in crashes, for me, it started already with the demo releases which then was confirmed as bugs, then a little better after I tested the fixes.but then back to more crashes and sometimes hard to track down.

Prince Charming
01-09-2017, 12:49 AM
Its once a week for me... Sometimes even less. Which is surprising because a lot of the time I am doing things that were not intended by nts development. There are times when doind certain things that I get them more often, but for me on pc it has been one of the most stable releases. Much more stable than Houdini for me... which crashes one or twice per session.... but at least in Houdini it is very rare to lose work when it does. In lw its been like 50/50 whether it lets me save before the crash completes.

bazsa73
01-09-2017, 02:09 AM
For me recently LW crashed after heavy VPR/surface tweaking sessions but only when I shut down the app.

MichaelT
01-09-2017, 03:02 AM
I wonder what some of you guys are doing to make it crash that often? I had crashes in the beginning, but when nVidia updated its drivers for 1080, I haven't had a crash like that in months. Freezes, yes.. but only because its calculations (modeler usually) end up in a painfully slow slooooow loop. Because it isn't using multi-thread when it could have.

inkpen3d
01-09-2017, 03:05 AM
As Prometheus and others have said, it very much depends on what you are doing. I am using 2015.3 on a PC workstation and my most frequent crashes seem to happen during data synchronisation between Layout and Modeler (but usually not the other way around). If I've been making changes in Layout (e.g. to object surfaces) and then switch focus over to Modeler, I have to make sure that I've saved everything or risk loosing work that I've done since the last save. But of course, there are times when you forget to do so and the air turns blue! I think this happens whether or not VPR is active. Seems like the Hub continues to be the weak link in the chain. It might be related to the Hub choking on high poly objects, but it's hard to pin down precisely.

gerry_g
01-09-2017, 04:04 AM
hardly ever use Hub, I mean its active but don't have Modeller and Layout open concurrently, like to keep modelled assets and render assets apart from one another in separate places and separate folders, same with textures and always run a standalone scene not a unified directory, Nodes and VPR refresh are biggest culprits for crash along with lousy modelling on my part in modeller, one point pollys and shared edges creeping into the model

fishhead
01-09-2017, 04:25 AM
I experience crashes of Layout almost only at occasions that involve changes on objects that have to do with maps or geometry - where I simply ignore or forget that I should have turned off vpr...
Recently my main focus was particle stuff that also involve HVīs. (astronomical visualization/space stuff...) I worked with it on a pretty much daily basis (even during the holidays...) over the last three weeks and remember 2 real crashes.
Maybe worth mentioning that I did not use surface nodes that much... Donīt know if that might make a difference..
Edit: And I almost always leave the hub running...

in general for me 2015.3 is pretty stable... I used it on on at least four differently equipped workstations (all win7 and at least 24Gig of RAM, though) over the run of the last year depending on the project/office I am at...

Asticles
01-09-2017, 04:56 AM
I normally turn off modeler if not needed.

Danner
01-09-2017, 05:54 AM
It is quite stable for me, unless I'm editing UVs

bazsa73
01-09-2017, 05:59 AM
If you are in VPR mode and in modeler side you add a new weight map. That used to kill LW with fiberfx with one single blow earlier. This must be due to the non-unified nature of LW and
the outdated underlying structures.

Spinland
01-09-2017, 06:23 AM
More like maybe once or twice a month? Really, almost never. The most common issue for me is one of my own stupidity when I forget to turn off VPR before I do a TFD recalc. Even then it doesn't crash, just runs so slowly it's best I force quit and re-start.

MichaelT
01-09-2017, 06:31 AM
Yeah, freezes are usually the times when I force quite. Like subdivision etc.. why these are still single threaded is a big mystery. But VPR haven't caused a crash for me since summer. I never turn that off, except when I need the other views.

Snosrap
01-09-2017, 07:34 AM
Modeler is very stable - I can run it all week with no crashes. Layout can crash when I do a "load recent scene" and then hit render. If I just go out and get the recent scene I don't have an issue.

Norka
01-09-2017, 08:59 AM
For me, Layout very rarely crashes. Modeler crashes (freezes) sometimes with boolean operations, and sometimes when tripling many polys at once. But since Octane now supports n-gons, I don't need to triple as much, so I get less of those crashes. And I am doing more boolean stuff with MetaMesh, so those are less too. Would still be quite nice to have Modeler be rock solid though.

creacon
01-09-2017, 09:12 AM
For me every 5 minutes.
Oh wait, that's when I am debugging my own code... :-)

creacon

Kryslin
01-09-2017, 10:05 AM
I get about 1 crash a week, sometimes less, usually related to user stupidity, but not always.

jeric_synergy
01-09-2017, 11:00 AM
I get about 1 crash a week, sometimes less, usually related to user stupidity, but not always.

I think that's the wrong attitude: crashing is never the users' fault, it's always on the program. Something wasn't checked, boundary conditions not validated, etc.

Unless the OS is at fault. But the user is never to blame.

hrgiger
01-09-2017, 11:06 AM
Well not to blame but the user has an obligation to report bugs if they want them fixed.

Sensei
01-09-2017, 11:37 AM
For me every 5 minutes.
Oh wait, that's when I am debugging my own code... :-)


Start checking pointers whether they are null prior using,
start checking indexes to array whether they're in the right boundary prior accessing field of array (in array C++ class in [] operators implementation),
and it will stop crashing in 99% of the cases.. ;)

inkpen3d
01-09-2017, 01:05 PM
I think that's the wrong attitude: crashing is never the users' fault, it's always on the program. Something wasn't checked, boundary conditions not validated, etc.

Unless the OS is at fault. But the user is never to blame.

Wholeheartedly agree!

There's a software engineering term called "graceful degradation" whereby run-time errors are trapped and handled (e.g. by exception handlers) in such a way that the software doesn't catastrophically fail but instead maintains some degree of functionality depending of the severity of the problem (e.g. so as to recover from the error, automatically write backup data, or give users the chance to save their work). Catastrophic software failures usually indicate poor software design and/or implementation.

jwiede
01-09-2017, 01:43 PM
I think that's the wrong attitude: crashing is never the users' fault, it's always on the program.

Agreed 100% (obv. excluding "capricious" user-triggered aborts).

creacon
01-09-2017, 04:16 PM
That's easy. lol
But I am using PhysX and I can get the display driver on its knees and even produce a BSOD.
But to keep this on subject, LW itself is pretty stable nowadays.


Start checking pointers whether they are null prior using,
start checking indexes to array whether they're in the right boundary prior accessing field of array (in array C++ class in [] operators implementation),
and it will stop crashing in 99% of the cases.. ;)

samurai_x
01-09-2017, 07:53 PM
I think that's the wrong attitude: crashing is never the users' fault, it's always on the program. Something wasn't checked, boundary conditions not validated, etc.

Unless the OS is at fault. But the user is never to blame.

If the users are too cheap to pay for software so it has adequate support for bug fixing, testing, then well....you get what you pay for.


Surprisingly lightwave doesn't crash often. Once a week maybe.

jeric_synergy
01-09-2017, 10:00 PM
The best way to help a vendor reduce crashing is to supply good crashing examples, with guaranteed crashing procedures and 'poison' files.

So, submit those bugs, in as much detail as possible.

CaptainMarlowe
01-09-2017, 11:04 PM
Pretty stable for me also. In modeler, I sometimes crashes with LWCAD quad mapper, if I try to mak a loop where there is a triangle in the way. I sometimes crashes Layout when VPR is on, if I trigger too many actions too fast, especially when texturing.

Kaptive
01-09-2017, 11:45 PM
There is also an element of knowing Lightwaves weaknesses and adapting to them. It only takes a couple of crashes doing a certain thing until I apply all caution and progress slowly, giving LW its' best chance to make it through the process.

One obvious example that I am sure everyone has had, is if you change/update a model/texture in Modeler while VPR is running in Layout (with hub running) and you switch back, that will occasionally cause a crash. So, I try not to switch between the two in VPR mode. Simple. Another one for me, a very weird one (anyone else get this?) If I delete objects from a scene (entirely case dependent) it crashes layout, however, I have found that if I select them first in the old/original Scene Editor, they delete perfectly and it never crashes. So now, if I want to delete something, I always do it through scene editor. Just these 2 things have reduced my crash ratio right down.

bobakabob
01-10-2017, 08:04 AM
In modelling, animation, rendering LW is dependable here and no less stable than Maya (2014 and 2017) or ZBrush ... every few days a crash.

Re the user debate, inexperienced users especially are bound to do some pretty extreme or
mad things. It would be interesting to know how far engineers broaden the scope of parameters taking account of this.

Kryslin
01-10-2017, 09:48 AM
Since I'm being somewhat taken to task on the whole "User / Stupidity || Initiated Crash" thing, more often than not, I can't remember what I was doing at the time when the crash occurs in order to duplicate it and report it. I chalk it up to something I did, go back to my last save, and get back to work. That happens less and less as I get better with the software. Plus, I don't know if it's the OS and other, installed software interacting in a strange way with lightwave causing an issue.

Oh, well, back to work...

jeric_synergy
01-10-2017, 12:17 PM
Re the user debate, inexperienced users especially are bound to do some pretty extreme or
mad things. It would be interesting to know how far engineers broaden the scope of parameters taking account of this.
I remember I found a crashing bug (!!!) from some innocuous action, something like Welding when only 1 point was selected.

That's just SLOPPY. And a real failure of imagination by the coder. Users shouldn't be expected to NOT do knuckleheaded stuff, they do it all the time. It's the coder's job to anticipate such nonsensical states, and gracefully move around them, OPTIMALLY notifying the user that the input made no sense.

Sensei
01-10-2017, 01:07 PM
I remember I found a crashing bug (!!!) from some innocuous action, something like Welding when only 1 point was selected.

If crash happened just once, and then never again,
you can't know whether it was crash caused by code of tool that you just used,
or it was memory trashing that has been just revealed.

jwiede
01-10-2017, 06:15 PM
It would be interesting to know how far engineers broaden the scope of parameters taking account of this.

(TL ; DR -- summary of standard C/C++ code analysis tools and best practices)

It's more about ensuring that all failure cases (incl. parameter bounds and allocation failures) are handled in the code, more so than actively "broadening" parameters' scopes. Crashes are an indication the app is completely "off the rails", after all, not just mildly dysfunctional -- unhandled exceptions and fatal access errors are typically the final result from a chain of code defects, single-point defect crashes are much less common these days thanks to much better compilers (presuming the devs are actually listening to their compilers, of course). Well, that, and not unexpectedly aborting the app as an error handling strategy (unfortunately common in older code).

Modern compilers like Microsoft's, Intel's, and GCC's all include extensive static analysis and profiling tools, which when used can detect the vast majority of structural and operational memory and variable allocation/initialization/access errors. The simple answer is, if the dev is disabling error-checking at module level, and/or broadly compiling without "warnings as errors", the majority of quality-sensitive software companies would consider that dev's behavior reckless and unsafe. It's uncommon, but there are cases where pragma-based temporary disables are merited, however those should only be done for the specific lines of code that require the disable -- again, disabling at module-level or above is reckless behavior.

Any dev writing code using Microsoft compilers should have OACR active and set to at least default (or more conservative) settings, and ensure that their code receives a "green" rating from OACR. Don't just trust the devs, either, run (at least) nightly automated builds with OACR/prefast checking as part of those builds (or some form of "continuous integration" builds), and ideally run automated "submit gate builds" with OACR enabled to further deter devs from checking in code with a less-than-green OACR status. After building, run the outputs through their automated unit tests with app verifier active (or driver verifier, for drivers), which checks runtime code behaviors as well, just to be certain there's no problems. See this MSDN article for a description of MS C/C++ code analysis usage instruction and guidelines (https://msdn.microsoft.com/en-us/library/ms182025(v=vs.100).aspx).

That whole suite of MS static analysis tools was designed and implemented after extensive analysis of huge quantities of Windows-reported (via WER) app crash data, and the issues and errors the suite raises are extensively documented as responsible causes in large quantities of app crashes. It may seem nitpicky, but there is a clear, demonstrable correlation between fixing those kinds of issues, and very sizable reductions in app crash-level failures. Likewise, runtime analysis tools like driver/app verifiers exist because they provide an additional notable reduction in driver/app crash-level failures. They're all basically either included with Microsoft's compiler toolchain, included with Windows, or (often free) dowload from MSDN -- devs using Microsoft tools (such as Visual Studio or MS cmd-line compiler tools) for software development have zero excuse for NOT using them. Apple, Intel and GCC all offer largely-equivalent capabilities in their toolchains as well.

Hope that helps. The practices described are definitely "broadening scope" in app safety-checking, but not so much in a way where devs actively need to themselves broaden parameters' scopes or such.

jeric_synergy
01-10-2017, 06:26 PM
If crash happened just once, and then never again,
you can't know whether it was crash caused by code of tool that you just used,
or it was memory trashing that has been just revealed.
Of course a one-time event is not diagnosable. But repeatable crash events should certainly be submitted.

jwiede
01-10-2017, 06:52 PM
As for the results so far (granted, very limited sample), the current results show a substantial percentage of customers experiencing crash-level instability frequently enough to represent a serious quality issue (~50% crashing more often than once a week, with ~25% crashing daily or more often (!!) -- that's quite a tail).

I'll provide quality references and a more thorough analysis this coming weekend, need time to run the stats.

MichaelT
01-10-2017, 07:34 PM
Another good habit is design by contract.

hrgiger
01-10-2017, 08:49 PM
It seems to me that about half of users are experiencing very infrequent crashes while the other half is a mixed bag of once every few hours to once every few days. Hell, I put in 5 or 6 hours in Zbrush, if I get less than 2 or 3 crashes I'm happy and Modo crashes a couple times a day quite regularly and for the oddest stuff usually I can't repeat. Whoops, up pops the Foundrys little bug reporter. I guess in other words, depending on how long of sessions you're putting in with various softwares, crashes seem par for the course and one crash every day or every few days isn't even worth mentioning unless its repeatable. Just my experience but LW has been fairly solid overall and I have lots to complain about but stability isn't it.

Snosrap
01-10-2017, 09:06 PM
I guess in other words, depending on how long of sessions you're putting in with various softwares, crashes seem par for the course and one crash every day or every few days isn't even worth mentioning unless its repeatable. With the exception being Photoshop. Man is that thing rock solid. :)

Paul_Boland
01-10-2017, 09:38 PM
I'm practically living in Lightwave the past few months as I work on my game, Dungeoneer. Lightwave very rarely crashes on me and I can have the software running for hours on end.

Marander
01-11-2017, 12:08 AM
...I guess in other words, depending on how long of sessions you're putting in with various softwares, crashes seem par for the course and one crash every day or every few days isn't even worth mentioning unless its repeatable. Just my experience but LW has been fairly solid overall and I have lots to complain about but stability isn't it.

I do not agree, it's because you're used to the crashes you experience, which should not occur. Once you are used to stable software, you can't stand crashy software anymore (and one crash every day or every few days is crashy to me). How it should be: like rock solid C4D which NEVER crashes in my case no matter what type of scenes I create and how many plugins I use, except with Vray during the beta phase). It might get slow / not responding for long due to user error (for example too high values for subdivision or displacement, particle spawning etc.), provided it has enough memory it continues working. Same in my line of work, those enterprise solutions just continue to work under heavy load and any other behavior wouldn't be acceptable for my customers. No software is completely bug-free but it should never randomly crash. LW used to be more stable in the 11.6.3 release than 2015.3 for me. Many LW plugins are a pain to use due to their instability as well as some built-in tools which were never fixed.

fishhead
01-11-2017, 04:26 AM
As for the results so far (granted, very limited sample), the current results show a substantial percentage of customers experiencing crash-level instability frequently enough to represent a serious quality issue (~50% crashing more often than once a week, with ~25% crashing daily or more often (!!) -- that's quite a tail).

I really canīt second that impression.
If I compare it with the other apps used around me, Autodesk and Adobe mostly - operated by a mix of professional individuals - LW (2015.3) seems very stable to me.

p.s. I voted "every few days..." because I did not wanted to come across to fanboyish, but it possibly is much less often in average... So given we only have less than a hundred votes that actually might count... ;-}

MichaelT
01-11-2017, 05:05 AM
I've managed to get C4D crashing. But it doesn't happen often. I only had it happen twice in the autumn, and when it happened Maxon immediately contacted me. To me it says that crashes happens so rarely, that they can afford personal contact like that. But I no longer have access to C4D.. so I'll see if I get back to using it. A complete version really is quite the hefty tag.

lardbros
01-11-2017, 05:27 AM
As for the results so far (granted, very limited sample), the current results show a substantial percentage of customers experiencing crash-level instability frequently enough to represent a serious quality issue (~50% crashing more often than once a week, with ~25% crashing daily or more often (!!) -- that's quite a tail).

I'll provide quality references and a more thorough analysis this coming weekend, need time to run the stats.

Think it depends on what you're measuring here really and sounds like you're just trying to discredit Newtek's product.

LightWave without plugins is VERY VERY stable indeed. But nothing mentions this in the poll question.
Most people don't use vanilla LightWave do they? Generally speaking, we mostly also use 3rd party plugins. I answered the poll based on using 3rd party plugins, like LWCAD, DPont's stuff, Mike Wolf's plugins etc. and they are mostly stable, but it's usually plugins that cause crashes for me. I get a crash once every few days, but I can go weeks on end without any issues at all, or just a crash on exit after a full day's working on it. Still a crash, so answered accordingly.

souzou
01-11-2017, 05:37 AM
Think it depends on what you're measuring here really and sounds like you're just trying to discredit Newtek's product.

LightWave without plugins is VERY VERY stable indeed. But nothing mentions this in the poll question.
Most people don't use vanilla LightWave do they? Generally speaking, we mostly also use 3rd party plugins. I answered the poll based on using 3rd party plugins, like LWCAD, DPont's stuff, Mike Wolf's plugins etc. and they are mostly stable, but it's usually plugins that cause crashes for me. I get a crash once every few days, but I can go weeks on end without any issues at all, or just a crash on exit after a full day's working on it. Still a crash, so answered accordingly.

Quoted for agreement. C4D regularly crashes for me but it is usually the Octane plugin causing it. LW rarely crashes but when it does it is usually when I'm using a plugin.

I think the biggest cause of crashes for me over the years (and these will hang the system) have all been Wacom driver related...

Marander
01-11-2017, 05:44 AM
I've managed to get C4D crashing. But it doesn't happen often. I only had it happen twice in the autumn, and when it happened Maxon immediately contacted me. To me it says that crashes happens so rarely, that they can afford personal contact like that. But I no longer have access to C4D.. so I'll see if I get back to using it. A complete version really is quite the hefty tag.

Interesting, thanks for the insight. Maybe it was an older version of C4D? But yes, I guess in rare circumstances every application can crash (sometimes maybe even a memory hickup / i/o error etc.). My colleague who is a design professional and working with C4D every day (on Mac) told me the only crashes he ever had were Vray rendering related and so is my experience on PC.

Marander
01-11-2017, 06:10 AM
LightWave without plugins is VERY VERY stable indeed.

I agree to that (vanilla) LW is stable in most situations and plugins cause most crashes. But there are also some old unfixed bugs / crashes like Rounder, switch to VPR and for example another bug I mentioned recently (reproducible with few clicks) in Transform tool. I submitted a bug report for one of the native LW motion plugins (Ask professor or whatever weird name it has) but it never got resolved. And this is the bigger issue I see with NewTek, every release except the current one (not even that one) is abadonware while other companies provide fixes for old versions of their products.

creacon
01-11-2017, 06:49 AM
Is this your opinion or a copy paste of something you found on the internet?
If it is your opinion, do you write code yourself? For a living, as a hobby?

creacon


(TL ; DR -- summary of standard C/C++ code analysis tools and best practices)
Hope that helps. The practices described are definitely "broadening scope" in app safety-checking, but not so much in a way where devs actively need to themselves broaden parameters' scopes or such.

Norka
01-11-2017, 07:16 AM
Oh, and also: my previous workstation had ECC memory (gosh, I miss that), and very rarely crashed. Practically never. Does anyone else currently have ECC, and can help corroborate my theory that ECC possibly makes LW much more stable?

MichaelT
01-11-2017, 07:21 AM
Since I can't even remember a situation where I have encountered corrupted memory. I'd be willing to say that it probably doesn't affect LW that much in that regard. For me it seems to be more sensitive to how good the graphics drivers are. But that is just my observation.

magiclight
01-11-2017, 07:40 AM
I think it's very difficult to compare, I would imagine that it depnds a lot on what features of LW you use, if I work in Layout creating a scene moving things around and so on it will never crash, but with some physics or fibers it can crash sometimes, there are also some nasty bugs in "Load items from scene" (loading only envelopes for rigs) that can cause trouble, what I put on the positive side is that it has never destroyed any LWO or LWS files for me when it crashed.

But yes it does crash a little often if you ask me, what I find very very strange is that sometime you can open a scene try do do something and it will crash, if you then restart and do the same thing again it will not crash, that is very very odd.

allabulle
01-11-2017, 07:53 AM
I use plugins and I can't remember the last time it crashed on me.

Kaptive
01-11-2017, 08:41 AM
I think the emphisis on the word serious, is a bit over the top. All programs crash... every single one of the bleeding things.

I've pushed LW to many extremes, where I would normally expect a higher crash ratio, and it has often suprised me in terms of stability. Not perfect by any means, slow downs, other things, but crashes not so much.
The thing is, if LWs crash ratio is trully serious, then all crash experiences are serious. What do you use to measure against? The factors and variables are far too great to possibly nail it down. 1-2 crashes in a 40 hour (minimum) week seems less serious to me and is related to time spent in the program and the tasks performed.

Is the crash a corruption of the object? The scene? Is it the graphics drivers? Is it windows? Is it the new program i just installed creating some weird conflict? Is my space mouse unplugged? (guaranteed crash that one), or is it just a weird quirk?..
There are so many things to take into account that it is like asking "how long are several pieces of string when you tie them together?"

Perhaps it'd be better to attack it from the other end...

1. What is the most frequent cause of your crashes?
2. What are your best practices and tips for avoiding them?

jeric_synergy
01-11-2017, 09:25 AM
Is the crash a corruption of the object? The scene?
I'd say these are some of the most unforgivable of crashes, since the intake of data is completely under program control.

IOW: Poison files should not be possible, since the parsing process has the opportunity to absolutely control the formatting of data. It should be rejected if it does not conform to requirements.

Obviously, LWG can't be held responsible for 3rd party plugin behavior.

01-11-2017, 10:13 AM
With 2015, I have had the good fortune of being able to end my sessions, on my terms.
That is to say, I have been able to quit the app based on my being done, not frustrated by a crash that made me go away.

This has been a saving grace for 2015.

At home, the pc is rock solid. AP causes the most crashes but that's not LW proper. Once a month I get crashes.

At work, macs are used. LW has always 'left them wanting more' as it was a bit crash happy when not doing simple things (You know, fiberfx). 2015 has had the classes able to actually use fiberfx and the like.

The most stable version in recent memory.
Robert

MichaelT
01-11-2017, 01:56 PM
A sure way to crash LW is to have a fairly highly detailed model without UV map, then create an Atlas UV map on it. In those cases I usually create that UV map in another program, then bring it back into LW. Since I know this happens, I typically don't even try to do it in LW.

You can try the following.. Create a box in modeler. Make it 200x200x200 segments.
Then proceed with trying to create an Atlas texture on it. It will most likely crash as soon as you hit 'Create'.

Btw.. don't try to create that cube in Modo.. you'll be sorry :) But C4D will eat that challenge for breakfast
So will Maya, 3DSMax & Houdini.. but Blender will crash if you are creating something too heavy
(meaning, it *can* create it, but if you're not careful with the subdivider.. it will crash.)

jwiede
01-11-2017, 02:01 PM
Is this your opinion or a copy paste of something you found on the internet?
If it is your opinion, do you write code yourself? For a living, as a hobby?

I have over 20 (ugh) years of career experience as a driver/kernel-level system software developer, incl. developing for IRIX's kernel at SGI, and Windows OS drivers, kernel, and hypervisor at Microsoft. Said companies consider broad and deep understanding of software quality, as well as ability to practically apply that knowledge, as a "core competency" required of their software engineers. I wouldn't have worked and continue working at the level I have, and on the jobs I am, without knowing this stuff. At Microsoft, I actually worked directly with the WER group on a project while our team was designing and implementing the Hyper-V hypervisor.

Microsoft, Apple, Intel, and most other medium- to large-scale software-producing companies I'm familiar with (incl. SGI back in the day) all consider deep knowledge and application of code quality concerns a fundamental requirement for software career advancement, including requiring extensive continuing education into software quality (which, in turn, includes extensive review of academic and commercial research derived from data from WER at Microsoft (http://www.sigops.org/sosp/sosp09/papers/glerum-sosp09.pdf), Crash Reporter at Apple (https://developer.apple.com/library/content/technotes/tn2004/tn2123.html), and so forth).

Microsoft's internal (and as of VS2015, external) CI/SQA build methodology is heavily based on the results of collaborative industry research efforts utilizing that data. Understanding how the underlying data and principles correlate to the tools provided (and other code quality initiatives) is taught as part of Microsoft ongoing education program for software engineers. I know Apple and Intel both have parallels in their own internal methodologies and developer education programs, and I'm aware of equivalents in many other medium to large software-producing companies as well. The benefits of applying such CI/SQA tools and methodologies have been substantial among early adopters (there's various SIGOPS papers discussing stats, incl. the prior WER paper and related references, which also discuss the beneficial results).

This isn't just a concern only the top few largest companies can afford to care about, either, it's become a critical area of ongoing industry-wide R&D and adoption. CI/SQA tools and methodologies are being practically applied today across thousands (at least) of software companies already (confirmed by Microsoft, Apple, Intel, GCC, etc. toolchain usage and uptake stats, as well as strong commercial adoption/successes of a number of CI/SQA tool vendors' products).

Hope that answers your question(s). I take software quality very seriously, because it is a very important software concern.

jeric_synergy
01-11-2017, 07:55 PM
::looking at qualifications above:: ::holy cow:: :eek: Wow, that's a heck of a resume'. :thumbsup:

And me? I'm just SUPER-opinionated!

jeric_synergy
01-11-2017, 07:57 PM
You can try the following.. Create a box in modeler. Make it 200x200x200 segments.
Then proceed with trying to create an Atlas texture on it. It will most likely crash as soon as you hit 'Create'.

I'm sorry I tried that. Ugly things happened.

jwiede
01-11-2017, 08:08 PM
::looking at qualifications above:: ::holy cow:: :eek: Wow, that's a heck of a resume'. :thumbsup:

Thanks, just passionate about software and been doing it a long time. I prefer to let arguments rely on own their references, but he did ask.

jwiede
01-11-2017, 08:28 PM
Since I can't even remember a situation where I have encountered corrupted memory.

To be clear, when I'm referring to memory/data corruption, I'm discussing software self-instigated corruption of its data in memory, not "hardware-level memory corruption" of the sort that ECC and kin are intended to address. That used to include self-corruption of apps' code as well, but modern "desktop" and server OSes protect application code from being overwritten by even the app itself now (in all but a very narrow set of conditions), so app self-corruption is now largely contained to its data memory (aka working set).

@norko: ECC is primarily intended to address memory corruption stemming from electrical, thermal, and EM transient effects (EM as in RF & cosmic rays) that inadvertently change the physical memory contents (in-situ). ECC and kin cannot really protect against software-driven corruption of memory contents (from the memory's viewpoint, there's no way to differentiate valid and invalid accesses by software). Transactional memory is a bit different, in that it enables software to recover from corruption, but the mechanism itself does not inherently "protect" memory from software corruption either -- the OS software still needs to detect and enact rollbacks). Does that make it any clearer?

Kaptive
01-11-2017, 11:34 PM
I'd say these are some of the most unforgivable of crashes, since the intake of data is completely under program control.

IOW: Poison files should not be possible, since the parsing process has the opportunity to absolutely control the formatting of data. It should be rejected if it does not conform to requirements.

Obviously, LWG can't be held responsible for 3rd party plugin behavior.


To be fair, I think I've only ever encountered a couple of instances of file corruption over the years. In at least one of those instances, it was the external interuption of the saving process (like a windows crash) or power fault with the external device being saved to.

jeric_synergy
01-12-2017, 12:18 AM
To be fair, I think I've only ever encountered a couple of instances of file corruption over the years. In at least one of those instances, it was the external interuption of the saving process (like a windows crash) or power fault with the external device being saved to.
I've only seen a few. Often it was something that was transmitted to me, and corrupted in the process.

I always try to send these on the devs so they can see what weakness is being exposed by that particular corruption. "Poison files"-- some people really object to that name, I don't know why.

Aww167
01-12-2017, 06:32 PM
LW seems to crash at least once a session for me on average, particularly if I'm using for several hours at a stretch - I also include when a tool becomes unresponsive and I have to close out of the program. Mostly it's an error report being generated from some unknown (to me)cause. Often I'll forwarded it to Newtek but less likely if I'm heavily into the workflow. I'm inclined to think it's partly due to my handling of the program - much of the time I 'm concentrating more on the end result than the way I'm actually using the software and maybe neglecting some of the finer points of correct procedure. I do wonder why it isn't possible for the program to more easily recover the previous stable state once an error has occurred, without completely crashing? If a command or series of commands results in an error of correct processing, can't it simply fail to do anything and inform you of the error without actually collapsing entirely? Presumably I'm highly ignorant of software architecture and someone far more knowledgeable can enlighten me?

jeric_synergy
01-15-2017, 02:41 PM
re Crashing: I just experienced a boatload of crashing, relating to working with Instances.

And, IIRC, a lot of it tends to happen when SAVING. I'm not keeping records (I don't get paid by LWG), but that seems to be the case. In this case, it was making a SCENE PACKAGE that killed it.

In one one-hour session I experienced 4-5 crashes. This really puts a damper on my enthusiasm for diving back into LW. I'd certainly never want to make a presentation of it in front of a group.

lardbros
01-15-2017, 03:35 PM
What were you doing with the instances? I've had HUUUGE instancing scenes that have never crashed while working but they did crash on exit, and that was repeatable for whatever reason.

Package scene can be a bit buggy though... It's always worth saving before you do that. Think it may save before you do that anyway, not sure though.

jeric_synergy
01-15-2017, 05:12 PM
Nothing big. I think it has more to do with SAVE, or possibly memory de-allocation following instancing.

Quite depressing.

MichaelT
01-16-2017, 11:51 AM
Probably the same reason the box I mentioned crashes. Buggy memory allocation implementation. Worse still, if it is linked to some arbitrary memory limit in the code, which I suspect it is. Something I hope they have fixed in the new version. It would at the top of my todo list anyway. That, and getting rid of the single core only sections. Such as creating the segmented box. Seems to me that it creates a polygon, then builds on it.. until it is fully created. Rather than simply creating all the faces independently. A perfect candidate for multi core operation, if there ever is one.

jeric_synergy
01-16-2017, 05:51 PM
Something I hope they have fixed in the new version.
The thing is, with the overhaul I'm expecting, any bugs will be totally NEW bugs, unrelated to any old code. With this amount of time, shouldn't all the code have been redone from the bottom up?

MichaelT
01-17-2017, 12:00 AM
The thing is, with the overhaul I'm expecting, any bugs will be totally NEW bugs, unrelated to any old code. With this amount of time, shouldn't all the code have been redone from the bottom up?

It is my understanding that they rewrote much of it at least.

Nicolas Jordan
01-17-2017, 07:09 PM
I usually have a crash when using VPR if I load a scene work on it for a while then clear it and load a different scene in the same session after working on it for a while. It seems to be much more stable if I close Lightwave and start it up again fresh after clearing a scene. I haven't really been able to pin point anything more specific than this though in my day to day work.

samurai_x
01-25-2017, 07:54 AM
So the real question is, how come Microsoft brought back the blue screen of death in windows 10?
Can we ask a microsoft engineer? Oh wait....

jimiclaybrooks
04-23-2017, 04:33 PM
Its been a long, long time since I last posted. Glad to say, its good to be back! Got a new machine and the latest version of Lightwave, and boy am I having issues! My OS is Windows 10 Enterprise. Got an Intel Core i7-7700k CPU @ 5GHz. Have 32 GB or Ram, and a GTX GeForce 1080 graphics card, so I can say, handling the hi-poly scenes is a breeze. The problem is, Lightwave keeps crashing, and today is just my first day with this machine. The Wacom tablet feels alot different too. Doesn't respond like it did with 9.6 on my old machine, seems to be slightly slower to select and move things around. I read that the install should be to a dedicated C:/Newtek folder and not to the C:/Programs/Newtek folder, which is exactly what I did. Layout seems to be ok, and I'm loving VPR, but Modeler is a nightmare. Couldn't even change layers without crashing. The hub seems to be a problem as well. Anyone else had these kind of problems? Thanks

jimiclaybrooks
04-23-2017, 04:52 PM
Oh yeah, BTW, I also forgot to mention the slow downs. Had quite a few of them. I believe it was a Wacom issue, and I'm working on that.

jperk
04-23-2017, 05:00 PM
The big question here..how often does LW crash compared to Autodesk's Maya? I've only used Maya 2015-2017 w/ expansions and service packs. It's a total crash-a-thon.

Dodgy
04-23-2017, 05:58 PM
I use it all day every day, and while it does crash, for the main it tends to be fairly stable and my crashes are fairly predictable. If I clear a scene I sometimes get a crash, if I load two scenes with instances one after the other, it tends to crash, so I don't have too many crash problems with it. It has an autosave feature as well which is very smart and well worth using, it only saves if a change has been made and at intervals set by the user. Having separate objects and scene files, you don't tend to lose much if you do have a crash. I set my Scene file saving to every 5 mins as they tend to be small (for me at least) and objects at 15mins or more, as they tend to be a lot bigger.

Sensei
04-23-2017, 06:13 PM
If I clear a scene I sometimes get a crash,

For 99% it means that memory has been corrupted somewhere else,
and freeing memory, just revealed corruption, maybe even after many hours of working..
Somebody else might not have so much luck.



if I load two scenes with instances one after the other, it tends to crash,

Loading scene is equivalent to clearing + loading. So it could be the same as above.

jeric_synergy
04-24-2017, 10:13 AM
Programmers, what makes CLEARING such a fraught procedure? I'd expect, in my ignorance, that THAT would be one of the easier operations, and probably a low-level OS call, eg "De-Allocate All The Memory I've Grabbed".

magiclight
04-25-2017, 04:15 AM
It does not work like that, the OS has one memory manager, the application has another, the application grabs a chunk of memory (OS) and then allocates small blocks from it (application) until it runs out of free memory in that chunk, so it will grab another one and so on, this is no problem, the "chunks" are released when you shutdown the application no matter what, the most common problem is that you allocate a block of memory and then release it but some code still reference it later on and that will cause trouble or a crash.

This is also why it takes a long time to wait after a render is finished in LW sometimes, for example if you have different subdiv levels for render and view, there can be a huge amount of small blocks of memory to free and it takes long time to clean that up.

But as I said, there are many things that can go wrong with memory allocation, reference to memory no longer allocated, reference outside an allocated memory area (you allocate 10 bytes and think you have 15 bytes) and so on, writing outside the small blocks of memory allocated inside the bigger chunk usually does not cause a GP failure unless it's a null reference so it can overwrite something that will cause a crash much later on, tricky to find).

The application must keep track of every little memory block allocated and just free the ones that are not needed for the scene any more, there is no "clear scene memory" function to help you with that, Java or .NET can do that for you, but not C/C++ applications like LW.

MichaelT
04-25-2017, 06:08 AM
There are memory managers for c++ that can help keep things more tidy. But it is usually more complicated when you are working close to the metal. For example, a program can call an external program in the computer, resulting in added allocated memory. But when the application ends, and its memory is released, the memory allocated by the external program might not be. Due to a bug, or simply the fact that it wasn't even told to release the allocated memory by its client. And so on.. memory is a complicated issue in any programming language that uses the system, or anything external to allocate memory. In programming languages like Java, not really, since you rely mostly on its own system to handle it. But even there it is possible to mess up, especially if you still use external resources to allocate memory.

jeric_synergy
04-25-2017, 08:58 AM
It does not work like that, the OS has one memory manager, the application has another, .....
Thanks for the explanation. I figured that memory allocation would be an OS-level task. Of course, if many crashes are attributable to memory mis-management, maybe it should be.

ncr100
04-25-2017, 10:17 AM
Programmers, what makes CLEARING such a fraught procedure? I'd expect, in my ignorance, that THAT would be one of the easier operations, and probably a low-level OS call, eg "De-Allocate All The Memory I've Grabbed".

Deallocating is not the problem, typically. Using deallocated memory is a problem.

An analogy - return a rental car to the agency then go back out into the lot and drive away with the car. That is a problem.

The OS will detect this illegal activity by the app, the usage of deallocated memory, and then go Judge Dredd on the app, killing it.

maceye
02-15-2018, 10:16 PM
All appropriate boxes are ticked across the board, but 2015 crashes every single time I try to render a frame or animation, which pretty much makes Layout completely worthless to me. Really have gotten fed up with Newtek as it's literally been years of putting up with buggy nonsense from the Mac version of this programme. For the record, I'm using (or was trying to use) LW 2015.3 on OS X v. 10.10.5 (Yosemite); I've now had to revert back to using 11.6.3 on OS X 11.7.5. Needless to say, I'm more than slightly reluctant to give Newtek any further dosh whenever they dangle their latest sparkly carrot in front of my eyes. I know I'm venting (been one of those nights here) so apologies for the rant to any die-hard supporters, but my experience with Lightwave has been anything but a pleasant one down through the years. All the more frustrating because I know it is capable of so much, but bugs and inexcusable rubbish like the continuing quirks of Rounder (how many eons have they had to iron those out, anyhow?) regularly turn what should be a stimulating creative process into a blood pressure-ratcheting barrage of profanity.

-FP-
05-04-2018, 01:44 PM
Somehow I never noticed until recently that there is a Lightwave 15.3 update. 15.2 has been working fine, but I got the update out of curiosity. It seems okay, no more or less stable than 15.2 - except the hub crashes immediately upon starting Modeler or Layout. It will not run. However, the programs work fine. I actually prefer to run without the hub, but a few years ago I believe Newtek made the hub mandatory. Apparently it no longer is. Now I work in Lightwave like I used to, no longer afraid that a misstep in one program will wreck a model open in the other (years ago I got used to the "insurance" of having an object open in the other program in case I made a surfacing error and reflexively saved a model).
Since 15.3 installs in a completely new directory, if I ever desired to run the hub for some reason I could still use 15.2.