High memory usage rendering Golaem crowds

[mitchell_architecural]

I'm trying to troubleshoot whether its V-Ray or Golaem that's causing high memory usage rendering crowds in a scene. The size of the crowd is approx. 15,000 people. All shaders/textures have been stripped out, as well as character animation, and just basic environment geo included, with one HDRI dome light w/ BF+BF GI. A 2k single frame render eventually crashes as memory usage grows past 60GB on a 64GB machine.

Switching over to Renderman, same lighting and geo setup, the render uses ~15.5GB.

Since the shading / texturing variable is basically removed, all that's left is geo. So my first guess is that there's a disconnect between the instancing engine of Golaem and V-Ray, and the whole crowd is being stored as unique geo in memory, instead of it being instanced. Does that sound plausible? Has anyone come up against this using Golaem?

Is this a V-Ray issue, a Golaem issue, or both?

(for those that might ask, please note that I don't have permission to post or send in any part of this scene or assets, unfortunately)

[Mihail.Djurev]

If it's unique geometry coming from Golaem, there isn't much we can do. We'll do some tests on our side to see if there's something we can do, but you should probably contact Golaem about this.

[mitchell_architecural]

Thank you Mihail. Sorry for the delay. We also contacted Golaem support. They said to talk to Chaosgroup support . They also said the base code for their plugin is similar for both engines, and the disparity between memory usage amounts comes down to differences in render engines. Here's the link to the thread on the Golaem support forum where our sims TD posted:

http://golaem.com/content/doc/golaem...2FYR__9fwpAwAJ

I also created a test scene that I can share using a stock Golaem character (roman soldier). The character has a similar poly count to ours. 10,000 soldiers in the sim, no animation. 1080HD render would crash at over 50GB RAM usage, but 720HD would complete @ 48GB RAM. The Renderman version used ~10GB RAM @ 720HD.

We've been testing Vray in our pipeline to see if it can replace Renderman for most, preferably all, scenarios. Memory usage keeps popping up, though. I'd like to better understand the differences in scene description and memory management with Vray, and if there is a more optimized scene assembly method or render setting we can use to bring memory usage down without dropping quality or adding an unreasonable amount of extra work (we're a small team). Or if we need to reduce our Vray usage to certain scene types.

I understand memory usage naturally varies by renderer. But 5x the amount seems odd. And the Golaem team is saying that's just the way Vray works. Any info you can provide would be helpful.

[yolov]

Just shooting in the dark here - but it somewhat sounds like excessive subdivision. To test my theory - you can go to render settings > Settings > Default displacement and subdivision and lower the max subdivs to 4. See if that helps.

[mitchell_architecural]

I believe the sample scene I uploaded had no subdivision on the characters.

[GOLAEM]

Hi,
Nicolas from Golaem
Finally was granted access to this thread so chiming in

Our code is the same for all our implementation of procedural rendering within a rendering engine and V-Ray is the only one taking so much memory (been tested againt Arnold, Renderman, Redshift) and the difference is really huge
We'd be happy to work on this if there's anything we can do on our side
Will be happy to share our DSO code (Vray specific part of the plugin) if you'd like to check if there are things we're not doing correctly

Anyway would be happy to help in any manner to reduce memory footprint in our plugin
Best,

[mitchell_architecural]

Thank you for following up over here. I really hope some improvement will come from more communication between Golaem and Chaosgroup. To both, If there's anything else I can test or assist in, please let me know. Until then we'll likely continue our Renderman pipeline for crowds. Appreciate you reaching out on this forum.

John

[yolov]

I'll start a separate developer conversation to see how we can resolve this issue.