Notifications
Clear all

[Closed] Merging linked layer references in custom attributes conundrum

Very curious. For me it crashes when doing it through the UI 100% of the time.
I had a look at the minidump generated, but that doesn’t give much more insight into what’s going wrong either. :
Exception Information: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.

ok. i found a problem.
it’s not our fault. it’s max’s fault as usually. in manual merge mode max before(or after) merge deletes all lost reference targets. in quiet mode max doesn’t do it. after first quiet merge, the system gets lost attributes with lost target. these ‘remains of pre-merged layers’ cause the crash.

the next step is to find antidote

Then I wonder, would the crash still occur if we do the merging in two completely distinct operations? I.e. merge1, save file, close max, start max, load file, merge2.

edit: yes it does…

Renaming the layers that were merged the first time before merging the second ones results in it not crashing by the way. I’m not sure whether this means that the layer names are the cause, or merely that the setName has a sideeffect that means the circumstances for the system exception are no longer there though.

mergemaxfile (getdir #temp + "\crashtest.max") #(#Sphere01) quiet:on
(LayerManager.getLayerFromName "Layer01").setName "tempLayer01";
(LayerManager.getLayerFromName "Layer02").setName "tempLayer02";
mergemaxfile (getdir #temp + "\crashtest.max") #(#Sphere02) quiet:on

Actually just renaming Layer02 does the trick.

Pier,
i really don’t like to lose. as i have a time i will kick MAX’s butt.

4 Replies
(@pjanssen)
Joined: 11 months ago

Posts: 0

Yeah it sucks to lose, especially losing to a computer program…

So I’ve kept digging a bit too, and have noticed something odd. I implemented the nested layers CA as I described a few posts back, using a handle and a string array to store the hierarchy names. So the CA contains no object references. And still the crash occurs…

(@denist)
Joined: 11 months ago

Posts: 0

the situation is worse. the crash happens also if any layer has any CA. i made CA with no parameters and no paramBlock, and add it to a layer . the system crashes all the same.

(@pjanssen)
Joined: 11 months ago

Posts: 0

Hmm that is pretty bad. In fact, that is very bad.
I’m now starting to doubt my own memory however (not for the first time,hehe). I thought I had an implementation with just layer names in a stringTab which worked… Let me see if I can go back to that version and test it a bit more rigorously.

(@denist)
Joined: 11 months ago

Posts: 0

my old tool works because i don’t add any CA to layers. i add CA to the scene root node

So how does that work when merging a single object then though?

1 Reply
(@denist)
Joined: 11 months ago

Posts: 0

simple it doesn’t merge nested layers. it uses what max does. max merges the only layer which contains the merged node. if the layer already exists in current scene, the node will be added to the layer; if it doesn’t exist – the layer will be created but without its parent layer.

Hmm I wonder if that’s the sort of behavior I would expect. How does it work when merging/xrefing a scene? Does that bring the nested layers into it?

I’ve also tried to get the most general case where the error can be reproduced. Like you Denis, it was with an empty CA definition on a layer. And it seems to be about a layer with the same name (which I assume is how max identifies its layer when merging) is already in the scene.

testCA = attributes testCA attribId:#(0x6d0e527e, 0x7024d6d6) ( )

layer = layermanager.newLayerFromName "test_layer";
layer = layer.layerAsRefTarg;
custattributes.add layer testCA;
layer.current = true;
sphere()

savemaxfile (getdir #temp + "\ca_crashtest.max");

--Merge object in a new scene, works fine.
resetmaxfile #noPrompt
mergemaxfile (getdir #temp + "\ca_crashtest.max") #(#Sphere01) quiet:on

--Merge object in a new scene after creating a layer with a different name, works fine.
resetmaxfile #noPrompt
layerManager.newLayerFromName "differently_named_layer";
mergemaxfile (getdir #temp + "\ca_crashtest.max") #(#Sphere01) quiet:on

--Merge object in a new scene after creating a layer with the same name, system exception.
resetmaxfile #noPrompt
layerManager.newLayerFromName "test_layer";
mergemaxfile (getdir #temp + "\ca_crashtest.max") #(#Sphere01) quiet:on

You can replace mergeMaxFile with xrefs.addNewXRefObject by the way, and you’ll get the same result.

Perhaps we should file an error report to Autodesk about this…

Hi there,.
I notice you’re working on a fix for the merge-nested-layers-crashing-max problem. How are you getting on with finding a solution?
I’ve just setup a project to work with nested layers, then realised there was a bug with outliner that pretty much renders this approach unusable, so I was wondering if you were close to releasing a fix?

One thing I thought could get round the problem, certainly when using xrefs, would be to place all the layers in a layer named after the xref. That way there shouldn’t be any duplicate nested layer names. This works at first, but if you disable the xref, the outliner doesn’t remove the layers created when the xref was originally loaded, so when you re-enable the xref it crashes max, I assume, due to the same duplicate layer name problem. Perhaps if you ensured when an xref was unloaded, removed or otherwise not imported, that the outliner would strip out the layers associated with that xref? You could potentially remove the duplicate layer names completely if each xref’s layers were placed in their own hidden parent layer that only exists in the parent file when the xref is loaded. Not an ideal workaround I know, but perhaps something to get the functionality back without having to negotiate a solution with autodesk!

Thanks as always for the plugin, its great.
Cheers
p.

Thank you for your reply Patrick. I got your email too, but I’ll just reply here so others here can read it too if that’s ok.

So, let me start by saying that if you use the 2.0.97 beta, you will also get a macroscript to remove all nested layer data from a scene, should you hit troubles that block you from merging scenes.

It is turning out to be a very tricky problem to tackle. In fact, I don’t believe that it is possible to find a solution, since it’s a definite 3dsmax bug. So instead we’ll have to find a good workaround. There are several ideas, but so far none of these are entirely satisfying.
The script I posted in the opening post of this thread will work, as long as you have it running by the time you merge. As a result it is not a complete solution, since it would still leave broken scenes from those not using the Outliner. But it might work for you as a temporary solution. Note that it isn’t thoroughly tested though!

One thing I thought could get round the problem, certainly when using xrefs, would be to place all the layers in a layer named after the xref.
The issue crashes max even before you would have a chance to do this. The only thing you can catch before the crash occurs is the premerge callback, at which point you basically know nothing about what will be merged.

You could potentially remove the duplicate layer names completely if each xref’s layers were placed in their own hidden parent layer that only exists in the parent file when the xref is loaded.
The layer hierarchy as such is not the root of the issue. What we found out in this thread, is that max crashes as soon as you merge a layer with any (even empty) custom attributes attached to it, if a layer with the same name already exists in the scene.

Not an ideal workaround I know, but perhaps something to get the functionality back without having to negotiate a solution with autodesk!
Nothing at all against Autodesk, but I don’t think we should count on this being fixed. The fact is that it doesn’t affect users directly, but only when a third party such as the Outliner uses maxscript in a particular way. And this might make it a rather low-priority issue. But who knows.
Either way, even if it will be fixed, it will only be fixed for 2013+, and the issue will persist in all previous versions. And looking at the Outliner stats, that means that it will continue to affect users of previous versions for years.
So my aim is to find some solution which avoids the current troublesome implementation altogether, and hopefully without making too many compromises in functionality. But it is tricky…

Page 3 / 4