PDA

View Full Version : Product support not being helpful



DaveWhitney
01-31-2019, 09:05 AM
I've reported a bug and I'm being blown off entirely. See the thread: https://www.lightwave3d.com/account/report/LWB-4626/

This is terribly frustrating and inclines me to stop being a customer. Has anyone else faced such frustration after filing a bug report?

Ma3rk
01-31-2019, 09:30 AM
That link just goes to the account login page.

On a completely separate note, I've a cousin in Seatle with your name. If that might be you, please send me a private note. I'll be offline though for about a week.

M.

Chuck
01-31-2019, 09:50 AM
The key phrase is "broken scene." Something is not correct in the scene file and loading it fails; it could simply have been corrupted somehow on saving. The mention of "user error" suggests that you may be attempting settings in the scene that are not supported in the product, so that may be what Layout is balking at when it hits that section of the scene file.

Have you tried recreating the scene from scratch, and if so, what were the results?

Have you tried varying the settings when you recreate the scene, to get within parameters that will load successfully?

Have you tried an alternative object, or objects?

Other than this post, did you try to workshop the scene and what you are trying to accomplish here in the forums with other users who may be able to help you work out how to successfully do what you are trying to accomplish?

RebelHill
01-31-2019, 09:51 AM
The dev responded... the scene file is broken.

I opened your scene file in 2015... resaved it, open in 2018... all is fine.

Its not a bug, its a broken file

peebeearr
01-31-2019, 10:02 AM
I can't access the link posted but I can concur in double, possibly even triple checking your issue.... I've dealt with that recently with this thread:
Refraction issue (https://forums.newtek.com/forumdisplay.php?18-LW-Community)

Thought I was totally on to something.... only to discover I screwed it up myself and in the process wasting everyone's time trying prove my point.

Moral of the story: triple or quadruple check your uploads. People here are very helpful.... even to the extreme sometimes. You gotta be gentle with that.

Chuck
01-31-2019, 10:07 AM
Also - what version of LightWave did you originally save this scene in? It shows a scene version of 3, which would be v9. LightWave 2018 and 2019 are at 5. If you have 2015, you can load it, save it to a new scene name and current version, then try that scene in 2019.

Edit: And RH got here first! I also had input from other team members and some terrific LightWave users who looked at your post and the info and doped this out.

A good first step when you have a problem, before putting in a bug report - check it out here in the forum. They can really help focus in on what the specific issue is.

And yes, apologies, we do need to review that case again.

DaveWhitney
02-01-2019, 06:37 AM
Also - what version of LightWave did you originally save this scene in? It shows a scene version of 3, which would be v9. LightWave 2018 and 2019 are at 5. If you have 2015, you can load it, save it to a new scene name and current version, then try that scene in 2019.

Edit: And RH got here first! I also had input from other team members and some terrific LightWave users who looked at your post and the info and doped this out.

A good first step when you have a problem, before putting in a bug report - check it out here in the forum. They can really help focus in on what the specific issue is.

And yes, apologies, we do need to review that case again.

The scene is directly from the OGO_TAIKI archive of sample scenes, except I manually edited out the demand load of the plugin itself to eliminate that as a factor. You'd need to ask the author of that ancient no longer functioning plugin what version he used. Probably LW 7. I last emailed him years ago and he never responded, so good luck. In any event, some old version of LW created the file and I don't think it's a stretch that any future version of LW ought to load it w/o issue. The original bug I filed has a copy of the scene that I had saved myself with some fairly more recent version of LW (perhaps LW 9 or 10), so LW creating the corrupt scene (and still being able to load it) lived on for some time.

I can pretty well guess the brokenness of the file - the objects have textures that reference other NULL objects in the scene, which are declared later. Older versions of Lightwave could handle this situation, but LW 2018+ cannot. I'm betting LW 11 and earlier loaded all the objects first, then resolved references and LW 2018 and later resolve references inline while loading. That's what I've been reporting - Lightwave silently ignores the remainder of the file after failing to properly load the first object (likely due to the fact that the texture references as-yet undefined objects). There could be an untold number of scene files in the world that will appear to load, but in reality will not. LW 2019 should either fix the load order bug, or report the load error to the user. You can imagine the diagnostic nightmare of some scene file defining a few hundred objects and there's a single out-of-order issue there and LW silently eats half the file with no indication of a problem.

I can load the scene piecemeal using "load from scene" by first loading the latter 5 NULL objects, then loading the two Mountain objects. All is perfectly fine after that.

- - - Updated - - -

The very fact that LW 2015 loaded it w/o issue and LW 2018 and later cannot clearly shows there's a bug. There has been a regression in functionality.

gar26lw
02-01-2019, 07:38 AM
I can pretty well guess the brokenness of the file - the objects have textures that reference other NULL objects in the scene, which are declared later. Older versions of Lightwave could handle this situation, but LW 2018+ cannot. I'm betting LW 11 and earlier loaded all the objects first, then resolved references and LW 2018 and later resolve references inline while loading. That's what I've been reporting - Lightwave silently ignores the remainder of the file after failing to properly load the first object (likely due to the fact that the texture references as-yet undefined objects). There could be an untold number of scene files in the world that will appear to load, but in reality will not. LW 2019 should either fix the load order bug, or report the load error to the user. You can imagine the diagnostic nightmare of some scene file defining a few hundred objects and there's a single out-of-order issue there and LW silently eats half the file with no indication of a problem.

I can load the scene piecemeal using "load from scene" by first loading the latter 5 NULL objects, then loading the two Mountain objects. All is perfectly fine after that.

- - - Updated - - -

The very fact that LW 2015 loaded it w/o issue and LW 2018 and later cannot clearly shows there's a bug. There has been a regression in functionality.

oh what? I hope this gets fixed!

raymondtrace
02-01-2019, 08:55 AM
...I don't think it's a stretch that any future version of LW ought to load it w/o issue. The original bug I filed has a copy of the scene that I had saved myself with some fairly more recent version of LW (perhaps LW 9 or 10), so LW creating the corrupt scene (and still being able to load it) lived on for some time...

That is a fair expectation, however...

I compared the LWS file shared by RH and the original file from my archive of OGO using Winmerge. The original scene file dates to January 2005. Nothing seems extraordinary. There is a good chunk of data at the end of the original file that is missing from RH's file because it relates to the 32 bit plugin that you're not running anymore.

I'm not understanding why you're bothering with this scene if you cannot make use of the 32bit plugin it was showcasing. The mountain object is not a mountain. It is just a flat polygon that is displaced within the scene. There's very little in this scene that could be repurposed in a 64 bit host application. If you want to address a bug in the realm of variances of displacement, use an actual scene that you have created which is affected. This 32bit plugin demo scene file is useless.

The effects of this plugin were never stable between LW releases. This is why OGO provided a LW6 and a LW7/8 version...and should probably have provided additional versions as time progressed.

144001

144002


...I manually edited out the demand load of the plugin itself to eliminate that as a factor...

Isn't that breaking a scene?

DaveWhitney
02-01-2019, 09:18 AM
That is a fair expectation, however...

I compared the LWS file shared by RH and the original file from my archive of OGO using Winmerge. The original scene file dates to January 2005. Nothing seems extraordinary. There is a good chunk of data at the end of the original file that is missing from RH's file because it relates to the 32 bit plugin that you're not running anymore.

I'm not understanding why you're bothering with this scene if you cannot make use of the 32bit plugin it was showcasing. The mountain object is not a mountain. It is just a flat polygon that is displaced within the scene. There's very little in this scene that could be repurposed in a 64 bit host application. If you want to address a bug in the realm of variances of displacement, use an actual scene that you have created which is affected. This 32bit plugin demo scene file is useless.

The effects of this plugin were never stable between LW releases. This is why OGO provided a LW6 and a LW7/8 version...and should probably have provided additional versions as time progressed.

144001

144002

Isn't that breaking a scene?

I don't care two hoots for the scene file. I was cycling thru old stuff because I was trying to find a reference to something I'd lost track of some time ago. In any event, I exposed a bug. I can probably manufacture another scene file that older LW versions will load and LW2018 will not. The fundamental problem is an object file makes reference to a scene element. I could perhaps make a scene that includes the mountain_r object, but has no instance of the NULL it references and LW probably won't load that scene either. Will have to experiment.

Chuck
02-01-2019, 09:56 AM
The scene is directly from the OGO_TAIKI archive of sample scenes, except I manually edited out the demand load of the plugin itself to eliminate that as a factor. You'd need to ask the author of that ancient no longer functioning plugin what version he used. Probably LW 7. I last emailed him years ago and he never responded, so good luck. In any event, some old version of LW created the file and I don't think it's a stretch that any future version of LW ought to load it w/o issue. The original bug I filed has a copy of the scene that I had saved myself with some fairly more recent version of LW (perhaps LW 9 or 10), so LW creating the corrupt scene (and still being able to load it) lived on for some time.

I can pretty well guess the brokenness of the file - the objects have textures that reference other NULL objects in the scene, which are declared later. Older versions of Lightwave could handle this situation, but LW 2018+ cannot. I'm betting LW 11 and earlier loaded all the objects first, then resolved references and LW 2018 and later resolve references inline while loading. That's what I've been reporting - Lightwave silently ignores the remainder of the file after failing to properly load the first object (likely due to the fact that the texture references as-yet undefined objects). There could be an untold number of scene files in the world that will appear to load, but in reality will not. LW 2019 should either fix the load order bug, or report the load error to the user. You can imagine the diagnostic nightmare of some scene file defining a few hundred objects and there's a single out-of-order issue there and LW silently eats half the file with no indication of a problem.

I can load the scene piecemeal using "load from scene" by first loading the latter 5 NULL objects, then loading the two Mountain objects. All is perfectly fine after that.

- - - Updated - - -

The very fact that LW 2015 loaded it w/o issue and LW 2018 and later cannot clearly shows there's a bug. There has been a regression in functionality.

Just send this text in a reply to the case to reopen it, and that should set off the light bulb for the developer. The team uses a system like that so they can work past misunderstandings that may crop up. But they need real additional information, and this is it.

DaveWhitney
02-01-2019, 10:12 AM
See the thread in the first iteration of the bug report: https://www.lightwave3d.com/account/report/LWB-4442/ somehow, the analysis shifted to me not noticing actual loaded objects because they were scaled too large. I stayed on track about LW not loading things at all, but I was eventually blown off.

I have replied to the mail on the new bug. We'll see what happens next. Thanks!

DaveWhitney
02-01-2019, 10:16 AM
Instantly blown off. Case marked closed.

SBowie
02-01-2019, 10:41 AM
Instantly blown off. Case marked closed.Thanks for mentioning that, but I wouldn't read to much into it. The process some use closes a case, but doesn't kill it (I know that can be confusing). In our system, at least, when a case is really "blown off", it will typically be marked "Resolved (By Design)", or "Resolved (Won't Fix)".

raymondtrace
02-01-2019, 10:43 AM
I don't care two hoots for the scene file.

If you did care, you might see the problem shown in the original file before you manually edited it, and likely mangled it further. There are scene element references buried within the "Plugin VolumetricHandler 1 OGO_Taiki" declaration that are probably ignored when that plugin does not load in newer 64 bit versions of LW.

Additionally, there is an extra "EndPlugin" in the original LWS file when there is no initializing "Plugin" declaration. The file was broken from the start. Older LW versions may have just been too dumb to notice. Maybe newer versions could offer an error message.

DaveWhitney
02-01-2019, 11:07 AM
Additionally, there is an extra "EndPlugin" in the original LWS file when there is no initializing "Plugin" declaration.

I hadn't noticed that. I don't think that comes into play, however, since the file is successfully parsed to the point that "load from scene" can ID all objects and other elements, as well as let me pick and choose to load them. However, if I attempt to load all the objects, and nothing else from the scene, it still only loads one instance of mountain_r. I will re-try with a fresh copy of the original scene file, unaltered. I'm also going to try the experiment of a fresh scene using multiple instances of mountain_r w/o including the referenced NULLs.

It'll have to wait until I get home, however - I'm at work doing other stuff my employer actually pays me to do.

raymondtrace
02-01-2019, 12:41 PM
Right, I'm not suggesting that extra "EndPlugin" was the issue. It just illustrates that bad LWS files can be formed and LW may or may not warn you about it. That was just something that jumped out at me. There could be other malformed data in there as well.

The reason why Load from Scene works is that it isolates sections of the LWS file. However, if you select everything in the Load from Scene dialog, the scene bombs just as if you loaded it normally.

You can manually edit the LWS to move the nulls before the mountains and it loads the nulls fine, but it still chokes on the mountains. There's something in them hills.

DaveWhitney
02-01-2019, 04:18 PM
OK, the superfluous "endplugin" is not a factor. Order of the objects doesn't seem to matter either - specifically in relation to the referenced NULLs. No matter what I do, LW stops loading after it loads the first Mountains instance. No further objects are loaded, and the light and camera aren't loaded either. I've moved stuff all around in the file and it definitely stops loading the scene after loading the first instance of Mountains.

One thing that's interesting is the first instance declared in the file wants to be parented by the 2nd instance declared in the file. However, swapping them doesn't seem to help.

Now, there's nothing specifically wrong with the object file itself, as I've systematically recreated the scene in LW 2019 and that scene saves and reloads OK. It doesn't seem to be an issue with loading v3 files - I have a few other such files that load OK. The mystery deepens.

gar26lw
02-01-2019, 09:45 PM
you kinda want a log written some place so you can see what’s up as it loads. feature request?

DaveWhitney
02-02-2019, 01:52 PM
OK, the problem is with the Displacement map declarations. If I remove them entirely, the scene loads completely.

DaveWhitney
02-02-2019, 02:51 PM
And it's not confined to that scene. There's an old Newtek-provided scene called TvGuy that exhibits the same load failure. Several objects are declared in the scene. However, the first object has a Displacement map assigned to it and hence, nothing after that first object is loaded - no other objects, no lights, no cameras. However, the object's bones are loaded.

EDIT: All the v3 scenes from Newtek that feature an object with a DisplacementMap fail to load correctly.
Landscape\CaveFire.lws
Landscape\snowyMountains3.lws
Surface\Sunset1.lws

however, v5 scenes load OK.

jwiede
02-02-2019, 05:22 PM
Thanks for mentioning that, but I wouldn't read to much into it. The process some use closes a case, but doesn't kill it (I know that can be confusing). In our system, at least, when a case is really "blown off", it will typically be marked "Resolved (By Design)", or "Resolved (Won't Fix)".

Steve, where should that "Resolved (By Design)"/"Resolved (Won't Fix)" info be presented in the customer-visible bug report information?

There doesn't appear to be any specific "Disposition" field or equivalent visible to customers in the new system's bug report display (and that's where such info normally resides).

Also, what you're stating makes "Open"/"Closed" bug status effectively meaningless from a customer perspective. Yet "Open"/"Closed" status is also easily the most visible and prominent field presented to customers in the bug lists & specific bug reports. Is that also recognized/acknowledged as a significant issue?

SBowie
02-02-2019, 06:49 PM
Is that also recognized/acknowledged as a significant issue?I don't even know for sure that the LW group users the same bug system. But either way, it remains true that there can be all sorts of activity in cases that is not accessible from outside. And in the video engineering system at least, all it takes to reopen a case is an email.