View Full Version : Modeler 10: Layers edit functions buggy

03-04-2011, 10:50 PM
Not sure where this comment goes. So dice said here:

I have just spent 4 straight days doing serious editing work on a very large model with Lightwave10 modeler. It was just under 500 layers.

I found serious flaws in the editor. These are very nasty and not just annoying, they mangle data.

The process of deleting a layer takes inordinately long and does not allow for a series of layers to be deleted as one step - which is crazy. I had a sequence of almost 200 layers to delete (all had become empty from my editing). It took nearly a minute per layer. Do the math.

When you add layers or delete layers certain things begin to fail. The first eye catching one is that the black dots in the right column of the Layers List (F7) becomes nearly random. Some get turned on and others off even though I did nothing there. Worse, many layers pick up children, random children. There is a tendency for certain layers to become parented to many other layers that make no sense at all. I had to open every single layer and one by one set parent to none.

Later, I had to do it again... and again .. and again...

Somebody needs to look at the method of following layers. It seems to be working from matrix position rather than from a lookup table. The add layer or delete layer actions make this fail. This is basic data sorting stuff.

The list of layers seen from top to bottom ought NOT be the actual layer row sequence but read from a top to bottom list of pointers to that data file. Then deleting one or more layers becomes deleting one or more pointers. Indeed better practice is twofold pointers. A top to bottom list of pointers to the data file and a pointer list pointing to the pointer sequence array. So in a file of 500 layers, of which only 200 have data, the first pointer list would only have 200 entries. They point in the displayed reading sequence to the pointer array which orders the data list.

A cleanup function uses the two pointer arrays to create a new smaller 'cleaned up' data array. Perhaps as a disc action temp copy file first as guard against power failure - renamed on success.

Likewise the parenting functions fail and the layers representation of layers bugs out almost always. Regardless of how it is programmed, I recognize the error of miscounting matrix position when the matrix resizes and the prior size is used for the calculation. That is the unifying flavor of these flaws.

03-04-2011, 10:57 PM
Sorry, that should have included : LW10 on PC (Boxx) w Windows 7, 64 bit

03-04-2011, 11:01 PM
I would FobBuz this bug. It sounds like a nightmare what you had to deal with.

From a management point of view, does your object really need that many layers? I can't imagine dealing with an object with 500 layers.

03-04-2011, 11:15 PM
It is a very dense and detailed biologic model. My job was to get a smaller subset for solid (looking) animation. So removing lots and reorganizing was the big job.

Losing the hierarchy made it H O R R I B L E !!! But it is nearly done. (I think, kinda).

03-07-2011, 08:48 AM
Well, that's hard to be sure. There is a two fold issue here. I was never able to handle anything this big until I went 64 bit. The swap to 64 bit just happens to be when I formally fully installed LW10 (thought, new machine, new install, so do all at same time.)

Before (LW9x) I never altered layer SIZE (add or delete a layer), so a bug like this just would not come up. I am an old binary programmer whose eary days were 7bit word etc. I write my own CAD applications for specific research needs. I know certain stuff.

For motion analysis, which I have been doing since about 1974 using main frame I was early to port to an Apple][ that was fitted out with a virtual memory board and then to Amiga. Even so, large models cost speed by this mechanism:

The key to speed is random access data - a predefined place for everything that is coming. But setting aside that huge matrix costs memory. The big trick was to put the fast access empty matrix somewhere it would not be in the way (on a dedicated disc or in high mem outside the working code reach etc). You can't resize that random access file or stuff gets goobered - just as we see here. Been there. Done it.

So you use a temporary huge file which has pointers to it. Given only , say, five layers the pointer file is only 5 words long (kinda in simple terms). Better is a double pointer file. So file 1 points from first to last 1,2,3,4,5 but points to file #2 which only also has five entries. Those point in order to huge file layers 352, 7,8, 143, and 1 for example. So layers would LOOK at content in this last order 352, 7,8, 143, and 1 as if they were 1,2,3,4,5.

Clean up is to make a storage file that only stores the big file data from 352, 7,8, 143, and 1 and does so in only 5 layers now reordered. The pointer files are now 1,2,3,4,5 and 1,2,3,4,5 and only the large file layers 1,2,3,4,5 now have data. It is "compacted" To reorder layers you only reorder the first pointer file. Data does not move.

Better is when the data MATRIX does NOT use the first column (the 0th)and data starts from 1,2,3,4,5,6,7 as columns and leaves the zero column open for a UNIQUE identifier that never gets altered and is truly unique. Even if the data matrix gets shuffled from an outside program, the layers can be reordered by column zero identification. This is ideal. Typically this number has a second entry in another matrix of unique identifiers (numbers) and what people call them (names). So when Margie Lupis gets married and tells her bank she is now Margie Wolf, only the name identifier associated with her unique identifier number gets edited. Nothing else needs to be changed. Her bank is not thrown into disarray by name change.

I don't think there are unique identifiers here based on how the parent-child relationships get lost as they seem to be simply matrix position related.

I know this is long winded - but I am trying to be helpful rather than critical.

Given such a large model, my attempts to reorganize it so that related stuff appeared near on the same screen so I could edit without endless searches, I used the 'add layers' and 'delete layers' commands to make space (for stuff residing in the 300's) to put right after item # 25. Then as they left large gaping nothings in sequence, delete the deadwood.


It may well be that this error has been there all along. If you don't resize, you won't encounter it.

Sorry for the long winded answer.


03-08-2011, 10:35 AM
Well if I don't at least try, I know I will get itchy & scratchy all over. Details like that make me crazy if I don't. I'll drop my current (mind numbing) stuff to go try that.
- ahl bee bock...

03-08-2011, 01:24 PM
This is huge, but this is how I debug, I keep notes to me: Here are the notes:

OK, fired up LW9.6 and loaded the file (on 64 bit machine, W7)

First thing I notice is in the Layers listing

where [o] is the eyeball before the hierarchy thingy.

when I click on V in the top name box which should bring all layers into foreground and open the layers list vertically,
NOT ALL layers are included in the making visible (foreground). Some are left out.

Which ones? At the extreme right in the [o] column we see those dots which ONLY AFFECT WHAT IS SEEN in LAYOUT (so the manual says) and has NO EFFECTS in modeler... If there is no dot in that row then that layer does NOT come to foreground when you click the top [F] thingy.

Now you can shift click those unseen layers and they do appear.

But it looks like the last row (layer) is a series of layers gets consistently unmarked in that right [o] column and thus unseen. So a content bearing layer .. not consistent

just before (above) an empty layer is typically unmarked & unseen, but not all.

I remember checking every single layer with content before my last save so that these dots which seem to actually do stuff would not muddle my work. So either that function is messing things up OR something that messes up messes the rightmost and leftmost choices together.

This file has 302 layers. There are two empty ones after the last one with content (300) as is proper. The resave did trim the end of the file and knock off about 150 trailing empty end layers. That ought not cause the error, as it is an END TRIM and counts run from low to high.

Now to test the resizing (adding or deleting layers within the range of those with content from 1 to 300 in this case).

Mmmmmm, lets add layers near the front. My first blank layer is #32.

In a long run of empty layers, in the name section many just have a dash but one or two might have (unnamed)
like this
even though they are all unnamed and empty on examination. Double clicking on a dash bearing layer to see what's in it generates (unnamed) as you exit. A 'FEATURE'?? It ALSO puts a dot in that [o] column which is hard to call a feature. Bug.

First I have to go through the list to be sure I don't still have any unwanted children

Oh geez, lots of them. AGAIN.. kill the children... get all the dots on for data layer, and off for empty layers,..., click [V] to turn everything on

(foreground) and save with a new name. [ Hey you St. Peter! I want this time back, ok? Write it down. I get credit for this!]

========================= LW 9.6 test really begins here as we don't know if what we just fixed was junk saved by LW10.

Close everything. Quit. Reboot program. Reload new named file.

OK. First thing I see when I expand layers
click the V

Is that in the long list of layers ... SOME ... have no dot in the right column [0] and typically these are layers last is a long sequence of content layers and just before a span of empty layers. An unnamed layer has a dot and is checked as foreground. I didn't do that. But not every case.

Now will it bug on resize? (The last layer is #302, the last layer with data is #300)

AHA! One answer immediately. I never had a bug with inserting a layer because my menu does not offer THAT choice!! So I never did it (in 9.6). Edit menu and add Insertlayer (it is there as an option). So let's try THAT. View/Layers/InsertLayer

Lets add 3 blank layers at position 22 (one at a time as that is the only way)

OK. It too 40 seconds and a blank layer appeared at position #22

What was at position #22 is now at #23...
Layer 300 is now 301 and there are now 303 layers (trailing two blank being maintained. Did I get any children?

Ooooooo, look. There are no layers named dash. ALL THE EMPTY LAYERS ARE NAMED "unnamed" except the last two terminal ones which are dashes.
That is unlike the LW10 behavior. Can't find any kids.

Let's add a few more empty ones.

Inserting a new layer at position #1 took 25 seconds.
at position 304 it took 50 seconds.

There were only three layers to be moved at position 304 and it took 50 seconds. The technical term for such an algorithm is lame from the Etruscan LAME-O.

I cannot imagine what strategy in a sort of data would do this! Even if the data is correct, this is bogus. But it seems to be correct. Did we get pregnant?



Now let's delete empty layers.

start at #141
Takes about 45 seconds deleting from central in the layers list.
The empty position one layer I added before took 50 seconds to delete.
Interesting. There are now 4 unnamed layers following the last layer with data. Plus the original two with dashes. If you use delete layer on these -

nothing happens. So terminal trims only happen on file save and reload.


Let's check those children for Berth defects. No.
Let's make some. Yup. They do assign properly. Show the hierarchy version of the list. Works.

This file is about as clean as I have gotten so far.

============ Go back to LW10 and load in the repaired LW9.6 properly childrened version, saved just before and without the additional empty layers we just played with.

Kaspersky is telling me that LW10 has a keylogger: PDM.Keylogger kernal mode memory patch. Don't see that warning with the LW9.6

File loaded and Hierarchy is lost. The children I created are gone.
Note that the LW9 has 'InsertLayer' and 'DeleteLayer' whereas LW10 has 'Insert Layer' and 'Delete Layer'. So unless they are renamed there may actually be differing innards?

Running this file in Hierarchy view mode seems to stabilize the behavior...

Ooooo I _KNOW_ this behavior. Let's load an older version before I weeded the garden.
Big file in the high 400s Look at the children.

Ahhhhhhhhhhhh. Quite a few layers which have no data ARE PARENTS. This is a poisoned file!!!

Poisoned files are files which contain data that is illogical to the host program. They will confound internal tests.

So we see a very large file that needs to resize and loops through layers - some layers with data and some empty. BUT some of those empty layers seem to have been used as headers (labels as in a different file format as happens when stuff is PORTED from another format). Some stuff gets ported and some deported.

I think LW10 was wigging out on the disconnected parent child relationships.

Understandible - but a bug. A cursory look at P/Ch ought to be part of the load. And then set a bright red color on layers that have illogical connections.

Also, enable a block of layers to be removed or inserted (making sure they are empty and NOT PARENTS of other layers claiming to be children!

Warning: Cannot delete this layer as it is parented to xxx,xxx,xxx, ....

Conclusion: Shared guilt. Source file was not properly formatted. But program load was deficient in not checking basic valid relationships.

03-08-2011, 05:45 PM
Conclusion: Shared guilt. Source file was not properly formatted. But program load was deficient in not checking basic valid relationships.
I got ridiculed when I suggested some parsing checks here once.....

03-08-2011, 06:16 PM
I find Modeler does tend to crash. 10 seems better than 9.6 but I will never trust it & make sure I have plenty of increments saved, probably too many!

Some of my models get up around a 150 layers with about 100 used. Some good tools to manage layers would make life so much easier.

03-08-2011, 06:34 PM
Support issues belong in the appropriate support section, and I have moved this thread to General Support.

Thanks for the detailed information; please do take the time to enter a fogbugz report on the issue and content we can reliably replicate the various issues with would be critical to the engineer in getting at the problems. Please include a link to this thread in the report as well.



03-09-2011, 06:14 AM
FogBugz - um - I would but I have never done that and am not coming up with a link when I search 'FogBugz'. So whoever knows how, jesdoit???

As to using documentation as a COVER for software - no. A proper editor is like a vital organ. So - as two of your heart arteries are plugged, just don't move too fast or go too far or you will die. [That is the documentation method in action].

Stent please.

03-09-2011, 06:47 AM
FogBugz - um - I would but I have never done that and am not coming up with a link when I search 'FogBugz'. So whoever knows how, jesdoit???

An instruction link is in Chuck's signature. "Fogbugz" is just the name of the bug reporting system they use

If you dont want to read, just go here:

Simplify the scene as much as possible, zip it up and attach it. State the steps to reproduce the problem as clearly as you can. Keep it as short as you can. Make it as easy as you can on the developers. That way, your bug will have a chance of being fixed :)

03-27-2011, 12:35 PM
Well, clarity was not what I had to share. I am a good debugger - when I have actual code, which I don't. This is so severe I don't consider it as ' my pet bug' or annoyance. This is a serious product killer. Fatal flaw. Lethal bug. I have stepped away & come back to it, retested and have decided my ONLY option is to drop Lightwave altogether. I began with this product back in earliest Toaster days.

Here is what is clear to me. In hierarchy mode, if you delete a layer or insert a layer (not on the tail end) then any of several errors follow (all of which through my eyes are layer pointer errors):

A layer, away from where you were working, and its object disappears.
You may find somewhere else, that object now in a ghosted form as points only ? in unnamed layer.

When you delete one or more empty layers (say you have 20 consecutive empty layers and you need to see things closer together). So you delete some of the empty unnamed layers (which takes inordinately long and why I suspect bad programming direct to data base without pointer lists)(should be instantaneous). What happens ? Somewhere else, a layer which was parented to something is no longer parented to it.

Indeed layer names get swapped.
I know my anatomy and I would never accidently name the left adductor hallucis brevis as the right triceps muscle, then do again three more times always after a deletion somewhere else.

A L biceps parented to the L humerus pops up parented to the right hemipelvis.

How can anybody work this way? It is badly flawed and needs repair pronto. After pronto repair it needs a better interface for easier edit reorganizing - basic stuff.

03-27-2011, 12:48 PM
I passed to FogBugz.

03-27-2011, 07:32 PM
I just took another pass at it. Tried to get the leg hierarchy right by looking at each layer and being certain, then pulling one or two from the general layer sequence into a parented position and boing sudden 150 layers have names off by one. Each object in a layer is the actual name of the layer before it. And somehow two unnamed layers got parented.

I am sorry but there is no getting around this. This is a drop everything else issue. You can't have a product out there that can scramble $38,000 models! hoplessly! and do so in very normal use. Data pointers are getting lost. That is a fatal programming flaw. Not an irritant. Death.

04-03-2011, 06:36 PM
Rather than deleting layers you don't want to keep - as a workaround - you may be able to take advantage of the fact that Export To .obj will omit layers that are set neither to FG nor BG on export. Assuming the .obj exporter doesn't choke on so many layers... .obj will preserve the layer names.