Memory leak with bss Get Object Vertices

Bug Reports
1

Steps causing the bug to occur

  1. Create a 3D scene with Add Noise to 3D Object.
  2. Connect 3D noise to the bss Get Object Vertices node.

Have you found a workaround?

No.

Other notes

  • Vuo version: 2.3.2
  • macOS version: macOS 11
  • CPU: arm64
  • How severely does this bug affect you? It prevents me from completing a specific task with Vuo.

After connecting Get Object Vertices, memory usage for the Composition Loader in Activity Monitor shows rapid rise (as in, kaboom!). I started getting the force quit menu “no more memory” message, tracked the issue to this. (The attached comp has the node in place, not attached.)

TriangleGrid-bssGetObjectVertices-bug.vuo (5.18 KB)

2

Hi Jersmi ;)

While I was not able to see which version of the Get Object Vertices node you’re using since we’re not using the same and we don’t get version info for missing nodes (I’m using the compiled version, not the .c version), those nodes could probably be optimised, to reuse the same mesh data if nothing has changed etc.
That’s why I wrote on that node to keep voting for an official stock node by the team if interested, and as you may have seen, this has been changed to “Chosen to be Implemented” so an official version is coming ;)

Beside that, checking your joined composition :

  • When Get Object Vertices is not attached I get about 50-60% Processor workload for the composition.
  • When attached, it spiked at about 100%.

But when you check the Output Port of Add Noise to 3D Object (before the Get Vertices node), you"ll see that it outputs at about 80 FPS.

Capture d’écran 2021-10-27 à 11.58.28.png
Capture d’écran 2021-10-27 à 11.58.28.png1261×612 55.8 KB

At some point I will have myself to take some time and analyse again the different ways events travel and are handled in Vuo, I have lost overview

  • Why for example here it’s 80 FPS and not 60, because we have Fire on Display Refresh at 60 FPS and the Build List that outputs at 20 FPS, it’s spitting an end rate of 80 FPS).
  • As you mentioned on your other discussion, why events don’t come out in standalone composition for published ports.
  • How events flow in sub-composition.

Etc, but the team recently expressed again how they prefer us to split discussions and keep it on topic so I’ll make a different topic for that.

Anyway, back to the topic, when adding a Hold Value node for example after the 3D Grid node, it keeps the overall end event rate at 60 FPS, and then the Processor Workload for me is way lower, about 12%, even when connected to Get Object Vertices.
I’m not on M1 processor though yet.

Capture d’écran 2021-10-27 à 11.58.48.png
Capture d’écran 2021-10-27 à 11.58.48.png1350×871 73.5 KB

The mentioned Hold Value node could perhaps be placed somewhere else even higher in the node stream, but was just a test, see joined composition.

Also, using Copy List Item instead of Build List, there is no need for a Hold Value node, see joined composition 2.

Hope this helps already.

Built List.vuo (5.33 KB)

Copy List Items.vuo (4.9 KB)

1 Like
3

Thanks so much, @Bodysoulspirit.

When you say processor workload, are you referring to the CPU tab in Activity Monitor? Does Activity Monitor Memory tab report anything bad? I’m talking starting from 500MB, then like +300MB every few seconds up to memory max in a few minutes.

Good to know that an official node is coming, this one gets used so much. I am using the c version, I’ll try to update in the meantime. Also – I originally discovered the memory gluttony in a larger comp where readout from Get Vertices from 3D Noise was showing tons of nans.

Good tips and thanks for sharing, using the Hold node, etc. I would have never thought it was a good idea to fire events at display refresh rate to hold the built list. And I’m so used to using Build List for everything, good to see the copy list approach. I know you’ve posted examples like that in the past as well.  

4

A Get Mesh Values node to output positions (vertices) and normals will be in Vuo 2.4.0.

@bodysoulspirit, thanks for helping out here. There is some documentation on managing memory in developing node classes, if that might be helpful.

Since this doesn’t seem to be a bug in Vuo’s core code, we’re calling this “Not a bug.” We’d be happy to take another look if further research points in that direction.

5

Awesome, @jmcc! Saw that coming – since @jstrecker’s name is on it, thought it worth reporting. Probably should have just posted it in the node library thread, eh? Not to mention, thanks again to @Bodysoulspirit for the tips…

1 Like
6

In Vuo 2.4.0, we added the Get Mesh Values node that @jmcc mentioned and fixed a small leak related to 3D objects that may have contributed to the reported problem.

2 Likes