Lands and Cycles uses a lot of RAM

Hi @fsalla or @albert and @nathanletwory.

It’s been a few years now and I see that Lands doesn’t render very efficiently yet.
The plant library is extensive, but it is of little use if it is going to be so heavy on the system unless we are to only use it for miniature gardens.

Take a look at this: I put in two plants and a topiary around a cylinder and nothing else, and Rhino uses over 5GB of RAM for a simple render!

And it is slow to generate the data, and it doesn’t work in Raytraced mode.

Also the graphics isn’t very complex, nothing more than we expect from any game engine.
We use TwinMotion as our main render engine for complex scenes, turning on raytracing there is instant and the vegetations looks great, is instant to insert etc.

Can you please see if there is anyting that can be done? It would be nice to be able to use Rhino + Lands for rendering too, but then we need to be able to adjust lighting in realtime in Raytraced.

This is what Raytraced looks like: (totally useless)

Is there anyting I do wrong? (And if so, can you tweak some settings so it works by default?)

The GPU’s Vram use jumps from 3.1 to 5.6 GB too (I render on the RTX)

I see that putting in more of the trees doesn’t affect the system much, but if I delete the topiary then the RAM use only jumps up to 1.5 GB (from 700KB when not rendering). So something wonky goes on there.
It’s still a lot of memory use for a tree though!

And I did a test now, deleted everything and cleared undo and Rhino still uses 1.1 GB of RAM… why is that, the file is now technically empty.
I see that if I now make a new document Rhino uses 800MB of RAM, but if I close it and opens Rhino again it uses around 300MB of RAM. And if I start Lands it ads about nothing to that use.
Then if I add a tree in 2D mode it ads about 10MB of RAM use.
Switching to 3D and it jumps up another 20MB.

So what are those 500MB of RAM used when I started a new documet after that heavy file (ironic :wink: ) of two trees and a topiary?

Hi Holo,
have you selected the “Generate very detailed plants for the render” option in the document properties, under the Render tab:

image

I guess that when you delete verything, you are also calling the purge command, right?

What’s the species of the inserted plant? It may be using a plant definition too much complicated.

Unfortunately, Lands objects can’t work with Raytraced mode, we don’t have a solution yet.

For version 5.7, coming soon, we are focused on improving performance: display speed, plant generation speed, file open speed, avoiding hangs, and avoid having too complex geometry in the document. This should lead to less RAM usage.

I used the Juniperus Communis and Hedra Helix.
Purge I didn’t do, but still… 800MB for 3 plants??

I know, and I think it is about time you try to fix this, Lands needs to support basic Rhino functionality and it’s been years now. Rendered mode works fine, so if OpenGL can read it I can not understand why Raytraced can’t, also when Cycles (Rendering) can. @nathanletwory do you know?

Back to the main topix: Why does a file that uses 500MB RAM jump up to using 2.2GB when rendering, and then after it uses 640MB, and after another rendering it uses 726MB? What is causing that? There is no undo stack to fill up, or shouldn’t be, as renderings can’t be undone (no other changes were made)

Something isn’t right, and I guess it’s very fair to say it’s far from optimized. Please take a look, it’s easy to replicate.

Regarding setting the “Render plants as seen in the drawing” lowers the RAM use, so that’s good. IMO that should be default :slight_smile:
(is “viewport” or “file” better to use? since “drawing” refers to 2D?)

Regarding “as seen in drawing” vs “very detailed”:
Somehting happes that makes the image darker too, and the Hedra becomes “stacked” and not natural:

Here’s a file to play with (geometry made with own scripts)
Lands RAM.3dm (8.6 MB)

Thanks Holo! I’ll take a look.

We don’t expect to solve the problem with raytraced mode until Lands Design for Rhino 8 is released. Solving it requires some changes in Rhino.

(is “viewport” or “file” better to use? since “drawing” refers to 2D?)
Yes! It’s a bad name. It comes from AutoCAD, where documents are called drawings. Lands was developed to work on AutoCAD before porting it to Rhino. Viewport would be much better.

2 Likes