Hi,
I’m currently working on a “Virtual-Mirror-Project” for which I route a Videosource (C920 Camera) in to the Cube Map of the skybox light. As soon as I the the Image gets routed into the skybox light, it fills the RAM. In my Case, I had like 60GB written into the RAM within about 20h. And I have this problem on all three very different PCs I’ve tested it on.
Not sure but I guess it’s caused by the VideoSourceToTexture creating a new texture for every frame returned by the VideoIn. Most likely the SkyboxLight or at least some part of it gets recreated when the texure changes and something isn’t properly disposed in that process. The RenderTexture on the other hand will output the same texture/instance as long as none of input parameters like for example the Size changes.
You can see this by checking the little “dial” in the upper left corner of the tooltip. When it’s filled the output is changing, if not then not.
Or connect a Changed node to the output:
The memory leak can be reproduced by doing something like this:
We just came across a very similar issue, in which the RAM was filled up over night up to 60 GB. And although it is not exactly related to the solution @bjoern provided, I want to add here that we accidentally had the “Force Build” input pin of the SkyboxLight enabled, which seemed to be the cause of our memory leak. Maybe that helps somebody else in the future.
I also came across the very same issue with the force build option, because I had another very random bug, that prevented the texture of the cube map from updating, until I enabled force build. But then also the memory leak kicked in. But for some reason, it simply works now, without force build, since I just rebuilt it exactly the same way in a new empty patch. No idea, why my old patch had this “curse”. but then, I was confronted with the very problem, that started this thread.
if there is a copy texture object involved (somewhere) then it is very possible that is also the number one suspect causing the memory leakage, had this experience in the past. Generating mipmaps also may be responsible for the this. I know, I am speculating, but it happened few years ago to have simiar issue, it can be a recurring problem if something is changed under the hood.
@bjoern I’ve started to build the patch with your suggestion and while it did definately not leak, I was foold, by seeing the Moving Background of the skyboxlight node. But what I’ve had to learn, that the metallic reflections in the 3D objects I need, will only work, when I enable the force build, or I’m going to put in an intermediate node like the “totextureview” inbetween, which literally has the same function as force build, but also the same problem as before.
Here my usecase:
So yeah, es long as I want the reflection in the “Sodacan” to be live, I have to force build, but then Memomory fills up, until the computer is nearly unable to work.
Took a cursory look at the code but didn’t find anything too obvious on the quick. If you know your way around C# you can try debugging, fixing and making a PR for it. Or if you have some budget you might get the devvvvs to fast-track a fix.
If you only need reflections, enable the “Specular Only” flag. This will avoid a lot of texture passes when pre-filtering the cube map.
The classes for the texture filtering are the NoCompute ones, which might be slower than the ones that use compute shaders. Assuming vvvv works with DirectX11 it should be safe to use the compute shader ones.
@bjoern for now I will work with a batch file that restarts the patch every couple hours. I’m not to familiar with coding, but maybe one or two people I know will enjoy a little bug hunt.
