Memory leak

[v.p.vlasenko]

Hi,
found interesting bug worth investigation.

I decided to rerender old scene, and at some point noticed that during render ram usage constatly grows and end up with max crash.

I narrowed it down to 2 objects in scene. If one of the objects is hidden, then all works fine, but if they both in scene - memory leak. Even more interesting - it's depends on viewing angle, at some angles problem aren't pronounced or even not exist.

Both objects use multi/sub-object materials with corona legacy mtl, by converting to physical - problem resolved. So I started to to convert those material one by one to physical. Seems like problem in materials marked green. When I replaced legacy "mirror" with physicalmtl "mirror" (red) the RAM usage was growing so fast that I didn't have time to click Cancel. In 2 or 3 second max used all 128 Gb and crashed.

While problem can be easily solved by converting all mtl to physical I think it worth investigation as there still a lot of legacy mtl in different model libraries and old scenes.
Attached screenshot with materials and file with those 2 objects.

Problem exists in latest daily and 13 h1.

[Aram Avetisyan]

Hi,

I will have a look and get back to you.

[Aram Avetisyan]

Ok, before "diagnosing" something as memory leak, please make sure there is nothing wrong with the scene. There is no leak, your scene is set up to eat up memory.

Your scene has Max ray depth of 100. If you know what this is for and deliberately changed it, it is expected for memory to pile up.
Change max ray depth to default value (25) and everything will be fine, with both materials.

[v.p.vlasenko]

"your scene is set up to eat up memory" - set up to eat memory with legacy but not with physical? )))

"it is expected for memory to pile up" - I didn't expected that changing max ray depth to 100 will eat 128 GB of ram in 2-3 seconds with 2 boxes scene.
Anyway - I sent you just 2 objects. Original scene is much bigger and working completely fine without those 2 objects or when I convert materials.
And with the scene I sent you - as soon as I run material converter my scene isn't set up to eat memory anymore?

So maybe I was too hasty in calling it a memory leak, but but something definitely wrong here.

[maru]

I think the crazy RAM usage here is the result of a few things in the scene, but they all seem to be related to the Legacy Mtl. For example, if you lower the Legacy Mtl's Fresnel IOR from 100 to the default 1.52, then it renders fine. Also, if you isolate either of the objects, it renders fine (even with the "wrong" materials and render settings).

Since the Physical Mtl is here to replace the Legacy Mtl and it already contains various fixes, I don't see a need to log this for the devs.

[pokoy]

I think the crazy RAM usage here is the result of a few things in the scene, but they all seem to be related to the Legacy Mtl. For example, if you lower the Legacy Mtl's Fresnel IOR from 100 to the default 1.52, then it renders fine. Also, if you isolate either of the objects, it renders fine (even with the "wrong" materials and render settings).

Since the Physical Mtl is here to replace the Legacy Mtl and it already contains various fixes, I don't see a need to log this for the devs.

There's still a use case for LegacyMtl - pure reflection and refraction, PhysicalMtl always introduces some darkening. I have scene where Legacy needs to work because of this (some optical trickery that just won't work with Physical).
Also, like in my case, there are many scenes that use LegacyMtl that I need to rerender with minor changes from time to time. I'd hate to see LegacyMtl produce problems since switching to PhysicalMtl is not always possible for various reasons. Please don't let it die...

[TomG]

The Legacy material isn't going anywhere, but the issue here is some wild values that should not be used, sounds like Fresnel IOR was 100 and the scene's Max Depth was 100. No need to use those values, and when you don't, there is no problem or error - so in this case, nothing for the devs to fix, as nothing is broken (other than the scene set up :) ).

[v.p.vlasenko]

Well...
guys, I got the impression that your attitude towards customers is drifting in the wrong direction.

I'm using corona more then 10 years and there a lot of not fixed bugs, but each time it was like yeah, there is a problem, we'll fix that (but not always happens obviously).

But for some time it looks like a gaslighting.

Almost a year ago I reported problem with tyflow and got anything but fix: questions why do I use it that way, advices with a workaround, and then a cool stories that it's a 3dsmax problem(no), tyflow problem(no) and that all renders work that way(no) - I had to spent time to do videos for you just to read - don't believe your eyes, it's not what it looks... and silence after - it's my problem from then.

Now I've got this problem, with old scene I decided to rerender in my free time. For me it was resolved in 5 min, as soon as I found which set of object causing "not memory leak, but wrong scene set up". They been added for certain camera which I deleted later and forgot to delete those objects. I could easily delete them.
But I thought - what if it'll happen to someone less lucky than me (or even for me in future) during work on tight schedule, when there is no time for those investigations?
So I spent time (now it looks like I just wasted time) to narrow it down from 120 object to 2 and send it to you, so you can fix it. I gave you a scene with a rare hard to catch bug that happens under certain conditions and instead of investigating and fixing it I see some childish and a rude approach - "You are a fool yourself"

before "diagnosing" something as memory leak

diagnosing in quotes? You mean than I'm incompetent to call it memory leak? You are right - I'm not one of corona devs so I can't say that))) Just corona sucked memory in 2 boxes scene so fast that when I saw memory usage growing like 30Gb/s in task manager I had no time to click cancel. Max crashed without any messages, and not only max but some other app and windows became completelly unresponsible. But no, than't not memory leak, as it well known that memory leak can happen only with default settings and if you change those settings within allowed values - it called bad scene setup. If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck bad scene setup:)

There is no leak, your scene is set up to eat up memory

If so, can you reproduce such setup in a clean scene? I mean setup that will eat all memory with few simple objects with simple materials. Can you? Because I can't.

they all seem to be related to the Legacy Mtl

Exactly, I wrote about that in first post.

Also, if you isolate either of the objects, it renders fine (even with the "wrong" materials and render settings)

This too. That's why I said interesting and hard to catch bug. And even more - it depends on camera position, object postion and rotation. By rotating camera or moving/rotating objects we can get absolutely normal ram usage, or 1-2 GB more than should be, or slowly growing or instant crash.

should not be used, sounds like Fresnel IOR was 100 and the scene's Max Depth was 100

Should I add link to your official support.chaos.com where we can see IOR up to 999 without any warning that it may cause crash/memory leak "bad scene setup"? Or max depth's tooltip whis says that it affects performance only?

I'm using different non default settings for GI/AA balance, max ray depth and max intensity in different scenes depening on how it affects result and up to now there was no problems with "scene setup".

And before saying that there is nothing broken except idiot behind keyboard who can't even set up scene, you should took that into attention:

I decided to rerender old scene

Rerender means it rendered not for the first time. And guess what? There was no problem with scene setup earlier, it perfectly WORKED back then but NOT WORKING now. Which means that something was broken in Corona between "then" and "now".

A bit of feedback based on some of reported bugs. Let's be honest, if you don't have time to fix something or not top priority or simply don't want to - just say that and it'll be ok. No need to say that all working as intended, working nice, "we're winning winning winning"© and gaslight person who reported bug.

Based on this bug and tyflow bug your attitude perfectly match gaslighing definition, as in both cases something wrong with corona, not me.
The American Psychological Association defines gaslight as: To manipulate another person into doubting his or her perceptions, experiences, or understanding of events.

[TomG]

No-one is calling you an idiot, nor did anyone say "you are a fool yourself". There was no such wording anywhere - that said, sorry you feel that the tone of replies implied that or gave that impression.

It does remain true though that from what I see here (not having tried the scene myself), there is no actual bug here. It will always be possible to come up with material settings and scene parameters that can consume memory or slow rendering massively, and that sounds like what has happened in this case.

Those are definitely extreme values. Max Ray Depth of 100 would be suited for, for example, a scene with a mirror reflecting a mirror 100 times before losing reflection, and as the tooltip says, it is usually best left at the default. There are very very few situations where a Max Ray Depth of more than 25 will make any visual difference, less where that difference would be necessary.

On IOR, "The highest IORs are found in metamaterials like the one created in 2011 with a positive IOR of 38.6, and in natural materials, the highest known IOR belongs to Germanium at approximately 4.05 in the infrared range and diamond at 2.42 in the visible spectrum. " - so again, a high IOR like that is not physically realistic. Now, bear in mind Corona used to not be as physically realistic as it is today - over time, we've continued to refine its realism, and that means some set ups that used to work, or even used to be necessary, no longer work, or are no longer required.

The maximum IOR in the Corona Physical Material is now 3.0. While the Legacy material is not going anywhere, some of the extreme values it allows may not work so well any more. So a scene that uses old set ups may have problems running under a new version of Corona, not because something is broken, but simply because things have changed (become more realistic, have been optimized, have new algorithms to calculate them, etc.) We do try and maintain backward compatibility as much as possible, but it's not always fully possible.

You mention that the scene is fine from some angles, and this makes sense based on what has been described - at certain angles, rays will spawn back and forth between two materials, where those materials are set to not obey proper energy conservation (so the rays don't reduce in importance and can be ignored, but instead all the rays have to be calculated, requiring more and more memory) where at the same time the scene settings have been changed to also allow that "almost infinite continued propagation" of rays, rather than clamping them after 25 bounces. At some angles, rays will bounce off one object, miss the other, and there is no problem. At some angles, rays will bounce off object 1 to object 2 to object 1 to object 2.... and so on, with settings that don't prevent this excessive spawning of more and more rays.

This does mean that the fix is in the scene, not in Corona - realistic values that follow physical laws are best to be used. This is kind of like the ray equivalent of setting displacement to World with units of .00001 - while it is in theory possible to calculate, it will run out of RAM trying to do so, and this is not a bug as the fix would be similar, adjust the values being used in the scene.

Old scenes no longer rendering, no longer looking the same, or even crashing now when they didn't before, is not always something broken in Corona. As mentioned, we do try and maintain backward compatibility, but it is always a possibility that something - especially where the settings are quite extreme - now causes slow rendering or a crash where it didn't before.

So no gaslighting here, there really isn't anything broken in Corona, and no-one is calling you an "idiot" or similar as it isn't your fault either, you set up a scene that worked fine back then, so both sides of your definition are incorrect. All it comes down to is that the solution here is that the scene and material settings need to be updated to account for the updated version of Corona, and neither you nor Corona are "broken".

Hope this helps!

[TomG]

Oh not to forget though - what was the problem you experienced with Tyflow? Is there a ticket number for it (even if that ticket was closed), so we can take a look at what happened there? If not, can you share the links to the threads (assuming it was something posted here on the forum). It would be good to check and see what was happening there, if there is something to fix, and if  things have changed with updates to Max, Tyflow, and Corona in the meantime. Thanks!

[v.p.vlasenko]

Thanks for the detailed reply Tom.

There are very very few situations where a Max Ray Depth of more than 25 will make any visual difference, less where that difference would be necessary.

Volumetric clouds, the difference isn't that big, but it's there. So for the main scene (from which I exctracted 2 problematic objects) I increased max ray depth.

As for IOR - it used for mirror, and the second object is glass shower screen. Before physicalmtl the only way to do mirror was to increase IOR.

As mentioned, we do try and maintain backward compatibility, but it is always a possibility that something - especially where the settings are quite extreme - now causes slow rendering or a crash where it didn't before.

I'm completely fine with that, if some old scenes may crash and nothing can be done then it's ok. As said above for me problem could be easily solved just by deleting problematic objects (or converting mtl to physical), as they aren't visible anyway. But I decided to report it as something similar may happen to me or someone else in future due to the huge amount of models that use legacy mtl, like maxtree libraries or a lot of other models available on the market and then it would be harder to figure out why that happening.
As for tyflow, here link to thread:
https://forum.corona-renderer.com/index.php?topic=43809.msg231702#msg231702

[Aram Avetisyan]

Hey,

Seems you got the wrong impression from the responses. Let me try to wrap this. Heads up - take the wit with some humor:

diagnosing in quotes?

Yes, as a doctor diagnosis an illness for a human being, not an artist a scene.
Don't take my word for it, The American Psychological Association defines it as "the classification of individuals on the basis of a disease, disorder, abnormality, or set of characteristics." :)

Let's agree that "scene freezes unless converted", "scene freezes with legacy mtl" is a better description than a "memory leak". No dev-level vocabulary is needed.

If so, can you reproduce such setup in a clean scene? I mean setup that will eat all memory with few simple objects with simple materials. Can you? Because I can't.

I can, please don't make me :)

I decided to rerender old scene

Software evolves, including render engines, and we called it legacy for the reason to allocate all the resources for a newer, better material model. Backward compatibility can be a pita (not the bread, the abbreviation. Not sure if APA defines it :), and is actually a significant time consideration for any new feature. That is why we encourage to move to newer CoronaPhysicalMtl, so users can avoid issues, and we can troubleshoot it and know it is meaningful, not an edge case to support a legacy functionality/feature.
You can rerender the scene(s) with the version you created it with, it should render no problem.

For all the rest you wrote - I did ask support team to see, if there is anything to investigate and improve (in fact before your long reply). There are enough "solutions" provided for devs to even look at it - use default values, use newer material. I will try to confirm if it is actually the ray(s) getting stuck jumping from glass to mirror, each time consuming more data to calculate. Your description of it - being view angle dependent - hints towards it.

You know what else fixes your scene (bug_.max), keeping everything as you sent - "fixing" the geometry (no pun intended with quotes). It may be because how it was imported or modeled, maybe because of chamfer modifier (known to cause hell with version differences), but if you apply a vertex weld modifier with a threshold of say 0.2, it will render all fine. So something related to materials and/or model(s). The scene also has material-based medium resolving - this was introduced well after CoronaPhysicalMtl became the default. Not to say disabling it fixes memory consumption, but not sure if it is even meant to work with LegacyMtl in all cases, they have different shading models.

In short, general troubleshooting steps apply well here.

And yeah, thanks for being a long time Corona user!