1.–Try rename the ENU folder
C:\Users”active user”\AppData\Local\Autodesk\3dsMax\2012 – 64bit
C:\Users”active user”\AppData\Local\Autodesk\3dsMax\2014 – 64bit
Tested,issue did not fix.
2.–Could you please exchange with us a (“Save As” / “Archive”) this will allow us to test in our lab, and make a request to our developers if we don’t find the origin of this issue in the support side.
This is not my scene ,I need to contact my friend and let him send me the archive file if he agree of that.
3.By the way,all machine open it will cause this issue except one of my another friend’s ,that mean,he can reset this scene in 2~3 seconds,I don’t know what’s the difference between his 3dsmax and ours. :shrug:
yeah, please ask him of a archive of the scene.
And if possible – ask the one where it works to take a screenshot of his ‘about’ screen in 3dsmax, this shows the version of max + service pack he has installed. might be a difference there.
Here we go:
file download here:
http://www.freeuploadsite.com/do.php?id=43328
about the version,I am waiting his reply,thanks for submitting the scene again!
Got reply again today,
the issue seems to be Vray.
[size=2][color=black][font=Verdana][/color][/size][/font]
[size=2][color=black][font=Verdana]“A lot of internal component create a freeze, as they are from external plug-ins and hidden component without the presence of vray.[/color][/size][/font]”
So the work-around is to export as fbx and bring it back in a ‘clean’ scene.
I do not have Vray myself, so I cannot test with Vray installed.
All that I can confirm from my end is the same issue as you said – it freezes (I do not have Vray installed on my end).
the issue is that file has not ‘max built-in’ data stored with the scene. it’s about 12Mb. every plugin that stores anything in scene has to care itself about the way how delete this data.
because we don’t have this plugin we can’t delete its data. it cause max freezing (actually crashing).
my guess that data stored with VRay lights. deleting any of them is suspiciously slow.
if you delete all nodes (it takes ~10 min) from the scene and save ‘empty’ file you will still see the size of this file as about 12Mb. It’s the LOST data which max doesn’t have an idea how delete.
here is some update… i’ve debugged the process.
this data is stored with file. this data is absolutely hidden for max script.
with SDK i can see it. but i don’t have a way how to kill it yet.
so … it’s a new challenge for me. as i have a time i will kick them ass
momo2012,
it looks like your foreign partners are using (was using) some c++ madden plugin. it looks like written by dunce.
there is a miserable chance to clean the file without this plugin or a code of this plugin.
the max’s suggestion about an export/import is most realistic solution in this situation.
I don’t know what plugin he used,but I think export/import is not a best way to fix,just like I said,after export/import to a new scene ,many works lost,you need to set render settings again or do other operations,it cost lots of time, right?
I checked the scene and have to say:
those modelled vray light bands are insane ( >4600 light sources ). I can’t imagine this to be ever efficient. I guess alone the render preparation stage will take ages with this insane ammount of light sources
The light bands are modelled out of aligned planar light sources.
As vray supports mesh lights, why does the customer not model the light bands in geo ( i guess an outlined spline + mesh modifier would do ) and assign ONE vray light to each band object ?
4600 lights should not make max completely lock up either.
I have scenes with 10-50.000 objects that does not lock up max (all though it’s slow).
I can understand why you say it’s insane, but still it’s ‘just’ 4600 objects.
The issue here is not how he has worked with Vray – but why it’s locking up max.
denisT Thanks for your valuable info
I too love working on solving things like this.
I did’nt say that it should – question is: would 4.6K standard photometric lights lockup Max too ?
An additional note: most lights are instanced from some 2-3 base lights. That generates a hell of a lot notifications internally ( considering Max’s unoptimized internal referencing and notification system ). Each light signals all other instances as soon as something happens to it. Add some redundant call of such notifications in the code during node deletion, and you have pretty much hell going on during the reset/exit after this scene was loaded
Just load the scene and exit in a fresh max session – you’ll see the same lockup happen ( which most propably will recover after a long long time )