TrailPOP VRAM usage can only go UP, never DOWN

[Papacci20]

I searched a bit on the forum but I believe no one has made a post on this so far, feel free to update me/close this post if someone else reported this.

I was experimenting a very basic TrailPOP setup with a custom pointcloud from my previous post and started noticing how compiutationally intensive the trail lenght can be.

This normally wouldn’t be an issue, just revert the changes back to the previous values, except that doing so/using the reset parameter of the TrailPOP actually doesn’t clear up space on your system.

For my testing scenario I simply chose to use a PointGeneratorPOP with only the highlited parameters modified from the default one (check first picture), the only thing that will change from my original scenario is that I will have to exaggerate the trail lenght by quite a lot compared to when I had my custom .ply, everyting else applies in the same way.

Here’s every case scenario I tested/I can recall of:

Starting point, TrailPOP is not connected nor does it have any custom values:

TrailPOP is added in the node flow but it has default parameters:

Trail Length has now been increased to 32 seconds:

Here is what happens when we bring down the Trail Length back to 1 second

Solutions tested so far:

Toggle Off and back On the “Active” parameter inside the TrailPOP - Doesn’t solve it

Pressing the “Reset” button parameter inside the TrailPOP - Doesn’t solve it

Toggling On and Off the new “Bypass” parameter under the “Common” tab for POPs - Doesn’t solve it

Toggling On and Off the ““old”” bypass button present on the node itself - Doesn’t solve it

Disconnecting the node’s only input and reconnecting it - Doesn’t solve it

Ctrl + X followed by an immediate Ctrl + V - Only case that has solved it

Again, all of this was tested further down the rabbit hole only because I didn’t see any forum posts, if it has already been discussed I’ll close/delete the post myself.

[Guillaume.L]

Hello @Papacci20
POPs have this behavior in general and this is intentional. Allocating memory is expensive and we avoid doing it repetitively if we can.

You can check these threads where we give more details on the subject.

GPU memory not freed after being filled with POPs

performCHOP to observe GPU mem + e.g. gridPOP. If you fill the GPU mem once my adding a lot of points, most of it won’t be freed when reducing the # of points again. Only deleting the POP will free it (or restarting the project). I’m on 2023.31801 Windows 11, RTX 3070 Ti Laptop, Nvidia Studio Driver Version 566.14 gpu_littering.tox (846 Bytes)

Polygozie pop do not reset the memory when change size of texture3D input

Hi, just got the pop yesturday. so can be i am doing something wrong. I saw that if i have a texture 3d with N depth connected to a polygonize POP, when i incerese N gpu mem rise… that is ok… but when i drop it down mem does not get free. deleteing the polygonize POP is solving the issue (mem goes back to normal usage). do we have some base line of how much we can polygonise ?? like 1 milion points = tot VRAM ?? Thanks!!

Although, resetting Trail POP is not an operation happening every frame, so it should be pretty safe to recreate the buffers. We’ll look into this.

[Papacci20]

Ah I see, my mistake was to assume this was exclusively a TrailPOP issue since that was the only one I noticed it with, now it makes a lot more sense.

I’m sure you guys already know via the other posts but I really hope to see an improved way to handle memory usage, whether that happens via a direct user command (button) or a “smarter” way to allocate memory (I don’t possess as in-depth knowledge to better express it but I think the point gets through).

Thanks for taking the time to link me up to the other posts, really apprieciate it!