Library loading multiple items take a lot of RAM

[RealViz]

Hello, I have again encountered a bug compared to FP8. If I want to load e.g. 30-40 objects at once from the library the whole 3dsmax starts to consume a lot of RAM and often ends up crashing or freez. Subsequent attempts to save the file are either very long, or fail (unless there is some RAM left and 3dsmax crashes).
However, this only happens when merging objects in V-ray proxy format. If it is a classic x-ref object everything seems to be OK.

[iToo]

Hi, we're unable to reproduce this issue.

What Display->Preview mode do you use for proxies ?
We introduced a change when display mode is set to 'show whole mesh' (to support Edge mode). But besides that, the loading process should be identical to FP8.

[RealViz]

I ran tests and other clue. This is the following structure:
Import is from one .max file, where there are about 500 vrmesh - People (as preview from file - edges). If there are e.g. only 30-40 vrmesh in the .max itself everything goes OK.

[RealViz]

I have prepared a scene, for size I will describe the procedure of what to do. Just convert the objects in the scene to VrayProxy (each object, one proxy). Then create a library in FP from these objects. This takes some time though (I don't know why. The first 1/2 or so of the objects is fast then it all slows down a lot).
When you try to import e.g. 100 objects from the library (but even 40) the whole max starts taking an incredible amount of RAM and usually crashes.
Everything works OK in FP8

[iToo]

Many thanks. This will help us to reproduce the problem.

[iToo]

I can reproduce the problem, but got same result using FP 8.2.6: loading 100 proxies from Library, memory raises up to 40 Gbytes.
Problem seems related with the XRef loading process, which we use to import items from the Library.

Please, would you repeat the test using FP 8.2.6 and checking memory of 3dsmax.exe in Task Manager ?

[RealViz]

So I tried FP 8.2.6 again. Loading is going relatively as planned. 100 objects (from my sample scene) are loaded at 20GB. Yes it's really a lot, but compared to FP9 when the whole max is practically stuck it's still OK.
Max 2024.2

[RealViz]

Anyway, it doesn't change the problem that the loading has a bug somewhere. Even if it's the same behavior for FP8 and FP9. Because the classic merge from the same scene is of course completely bug-free.

[iToo]

Anyway, it doesn't change the problem that the loading has a bug somewhere. Even if it's the same behavior for FP8 and FP9. Because the classic merge from the same scene is of course completely bug-free.

I know. But initially i though it was a problem with FP9, so we checked all differences in the code which would cause it.
But for some reason, in our tests there is not difference between both versions. It takes about 20 Gb. RAM.

Anyway as you said, something is not correct. It should not take so much memory.

Therefore, once we know the problem is not specifically of FP9, i checked the Library loading process.
And i found it seems caused by some issue with XRef and V-Ray proxies: we could reproduce it without Forest, just loading 100 proxies as XRef, using maxscript:

Code: [Select]

for i = 1 to 100 do
(
objName = "VRayProxy_Teapot" + (formattedPrint i format:"3.3d")
objXRefMgr.AddXRefItemsFromFile "C:\\tmp\\ProxiesTest\\VRayTeapotsHighRAM.max" objNames:#(objName)
)

I just reported the problem to ChaosGroup. I hope they find the cause.

[RealViz]

I don't do xrefmerge but classic Merge. It is much more logical for Vray Proxy. Still, even this classic Merge takes a lot of RAM. If the Merge is done via the standard max function it works OK of course.

[iToo]

Library browser uses XRef internally, even for the Merge mode.
This is necessary for several processes, which are applied before merging the objects to the main scene.

[RealViz]

OK, thanks for the info. I saw (and tried) the script and I was a bit scared that we all understood the whole post differently from the beginning :-) THX