Hi guys, @nathanletwory @fraguada
testing out Lands Design. Made a 20x20 meter terrain and populated with topiary (Buxus sempervirens):
It looks OK in rendered mode:
But in Raytraced it does not look OK:
And if I hit Render it takes a long time to precalculate, both the very detailed plants + vaiting for the render UI to pop up, and for it to upload the model before it starts rendering.
This is what the viewport looks like after detail plants calculation, but still it hasn’ opened the render gui:
And then it says handle 3 mesh, and then it uploads 4… But I only have one mesh that is populated with one species…
Is this something you are familiar with?
Once all slow steps are completed it renders quite fast:
Yes, the white textures in raytraced mode is a known limitation. We don’t have a satisfactory solution yet.
Regarding the long pre-render time, Lands is reevaluating your groundcover, creating a much more detailed version. It does the same with plants but this process is specially painful with large groundcovers, as the one in your screenshots. You can disable this behavior from the Render tab in the Lands Document properties:
Thanks for the quality render tip, that solved the long wait…
Wow, that seriously needs to be fixed. @nathan do you know why it renders white? Both textures and alpha data seems to be ignored in the raytracing display mode, but it renders fine.
I am doing some simple tests here, but run into all kinds of trouble.
Shal I make a topic for every one? It seems you struggle a lot with mesh splitting.
SplitAndFill Bug 01.3dm (394.5 KB)
Yeah, mesh booleans in terrrains… this is another known limitation. They used to fail often in Lands for Rhino 6 and the problem got worst in Lands for Rhino 7. We are currently working on maximize the success ratio.
I suggest you to avoid the mesh boolean operations by enabling the gridded surface. You must also keep the “Use the grid to model holes and cut and fills” option checked to ensure no booleans ops will be involved in the terrain generation:
OK, I didn’t turn anything off, so it sounds like this should be turned ON by default in Lands.
Is that a sticky setting?
Oh… but now the terrain is a huge rectangle…
And I can only move the points of the cut and fill rectangle ON the rectangles plane, not up in Z direction.
When you insert a new terrain, the values are stored and remembered the next time you insert a new terrain (not so when you modify an existing one).
By default (first terrain ever) the gridded surface is OFF and the “Use grid to model holes and cut and fills” is ON. It was so in your 3dm when I opened it. You just need to enable the gridded surface and adjust the cell size to your needs.
To move the grip points along the Z axis you can hold CTRL, or use the Rhino Gumball.
Well, that’s the thing, I have tried it all, it moves it in the preview, but once I let it go it jumps down to the original curve plane… Are you able to modify it on the file I sent? Say move the entire rectangle up 1 meter?
There is a special grip point that let you move the whole cut and fill curve:
Yeah, that worked on the entire rectangle, but not on only one or two points. (Project is not on, but Gumball should ignore that none the less)
Adding a “road” works fine, there I can Z-modify individual points.
Lands aborts single grip points elevation because the cut and fill curve becomes non-planar.
If you want an inclined cut and fill, you should incline the curve prior to create the cut and fill. Since then on, the curve plane will govern the grip points edit
That’s true. Road curves don’t need to be planar because they just set the axis of the cut&fill. Lands is calculating the boundary and making it planar at each curve param.
I think we can improve the cut and fill by allowing the case where after moving two or more points you still get a planar curve.