Please Further Optimise Rhino's Rendering/Cycles for Larger Projects

Rhino Rhino for Windows
1

I find it very fustrating to work on larger projects because of:

  • Unpatched OpenGL rendering errors
  • Lack of accurate textured preview and consistency
  • Cycles Latency

Faster viewports were supposed to be one of V6’s features; I find the performance gain disappointing.

I cannot understand, who would have thought that that we would want to see a solid color instead of a diffuse texture if we add a bumpmap to a Material. If we add a bumpmap to a material, we cannot see it in the viewport in any mode but Ratraced, which is also too slow to work with when aligning materials/maps.

Sigh.

2

V6 absolutely is in fact massively faster on giant models–on cleaning up five-figure-part-count imported models for rendering it was the difference between “tedious” and “almost impossible”–but you need decent enough hardware to see it. The cost of making more use of the video card is…you’re making more use of the video card!

3

Working on what I am is nearly impossible with my lowly quadcore, and GTX 1080. Rhino is easily crashed at one extra mouseclick.

Cycles makes some nice final renders, but a dozen seconds for a single distinct material change is unpleasant. The material change is only going on a flat surface. I know it has to go over the bus and onto the video card, but…

In OpenGL view, the mapping is bugged, still, after months, so it’s not like I can keep switching.

4

Rhino needs a massive update in display working speed for large projects.
Copying an object costs 5 seconds.

I will be upgrading my laptop, but still, I wish they would better test Rhino with large projects, or better yet, do some large projects, or even some extra medium ones : )

5

As you well know, software development is always a work in progress. Big gains were made for V6 and we are working on additional improvements for V7 including in Cycles.
It will be better.
Will you be able to bring it to it’s knees?
I’m guessing yes.

6

IF your files have lots and/or big textutes then Rhino has an issue with copying any objects to memory as all textutes are also copied… not only the relevant ones. (As I have understood it) thus the long copy and paste times.

Is that your case?

7

In the WIP lots of improvements have already been made. These should get out to the public in the next WIP probably in two weeks time. Especially with respect to texture handling for complex objects, and large textures. Some random list with changes:

  • progressive baking of textures: first low resolution version of texture is pushed to Raytraced, then in the background the real version is baked and put into the changes queue. If there are more textures in a scene these essentialyl get bunched up. Update should happen when user tumbles view for instance (or makes another change in the scene).
  • improved texture handling in the entire pipeline (direct texture access bypassing a few managed/unmanaged jumping hoops)
  • better texture access for several cases (normal map detection for instance)

etc.

Further, I have the Cycles update working on my Windows machine. I’ll be cleaning up the changes in the coming week and make it also work on the Mac. That should give some additional performance gains as well.

edit: copy/paste isn’t addressed here, that is a different todopile.

8

Perhaps if MIPs were kept, it they could speed things with fillrate. They could could still overwritten and clamped.

I tried to recommend an imposter system for blocks.

A Rendered/OpenGL texture mapping bug persists.

There also seems to be a Rendered bug whereas the using a bumpmap casts a colored shade over the applied material–making Rendered mode doubly useless for aligning materials.

It’s upsetting when Rhino is unstable to use.

9

For V7, a “Pause Rendering” button would be helpful because it would not be as necessary to keep changing away from Raytraced mode, and going through its initialization.

Currently, if you want to click move a slider, click on a arrow button, or even type a number, Cycles will rip the UI from the user, and start updating/rendering–driving the user experience into the ground.

10

This is part of the improvements Andy and DavidE have been working on to improve.

11

Hi Holo. Yes, I have some 4096s.

I noticed two things:

1.) Copying even untextured objects takes a long time–seconds on my machine, when plenty other exists.

2.) While working on the same project, the Alt-Gumball Drag to copy function barely pauses Rhino at all…as in–What?!

Yes, my undo settings seem reasonable.

12

The two are different operations. 1) does create essentially a temporary file with what’s needed (and much more), 2) is just a duplicate without creating a temporary file. 1) does that because that’s needed for transport of data between two Rhino instances, 2) can’t do that.

13

Temporary files? Why on earth would Rhino want to create a file on the SSD/HD for a copy operation?

I cannot see that as being helpful-unless the user is almost completely out of memory. When they paste, they are going to be out, anyway.

And I have found from my own personal experience that the user will run out of speed to the point where it becomes as stable as a one-legged barstool with a wheel on the bottom–long before the memory is used up.

Even a mighty Samsung 970 nvme bus-driven SSD has a peak bandwidth of only 3.5GB/s verses the 47.68 GB/s for say a $299 AMD 3700x. So, it would see that copy/cut/paste operations are 10 times slower than they need to be.

Hmm. Perhaps there should be a shallow copy key combination, equivalent to a drag in place, or a special key combination for pasting from between instances of Rhino.

If I have the memory, should I start looking for some kind of old-fashioned RAM-Disk emulator? : )

14

The temporary file also enables copy/paste between different versions of Rhino.

15

If need to copy via a file for going between instances of Rhino, okay, but could it be changed for everything else?

If Adobe used a file for cut-and-past with Photoshop, people would be amassing at Adobe’s twin towers with pitchforks.

16

Rhino crashed 3 times today.

17

Five crashes, today.

And for medium-large Projects, Cycles just won’t run stable on the GPU.

18

Brenda

Could you be more specific about these bugs please. I can’t fix 'em if I don’t know what they are.

Andy

19

I don’t think it’s worthwhile speculating on what the problem might be. It is almost never what you think. If we can repeat this issue - with a file, for example, we can probably fix it.

Andy

20

Hi Andrew Le Bihan,

1.) In Version V6, I don’t feel that Cycles is presently responsive enough for previewing mid*/large projects. Understandably, the emphasis was placed on total rendering time. I wish it were checked with more larger projects. I understand that there is a tradeoff between total rendering time–and responsiveness.

At any time, it’s really easy to crash Rhino with a 3.4Ghz quadcore/GTX 1080/ 16B GB RAM/ SSD/ PCI3 Bus. Rhino will usually go white on you in warning. If you add one more event onto the heap, it’s likely going to come crashing down.

2.) As Holo (and Nathan) pointed out, textures such as 4096’s, add to the slowness. I use these only where necessary, where I need texture over distances. There are 2 of 4906’s with bumps, 3 of 4096x2048, 1 of 2048, and about a dozen small textures. I feel that this is a texture load that is much smaller than many modern video games, which often have complicated shaders, which do such things as billboarding, additive lighting, and waveform luminance animations.

3.) Cycles will crash on GPU, where the CPU rendering will succeed–even under the checked/observed memory of the video card. This kind of Rhino crash will not reliably produce a Rhino crash dump.

4.) There are texture mapping inconsistencies in non-Cycles modes, such as this problem with the Brick Materials. AFAIK, Cycles gets this right; Rendered Mode does not. As I remember it, a non-cycles raytrace of this will not show this mapping.

(Note: In this screenshot, a material swapped with an grid material for scaling and aligning materials with unclear biases. Oddly, the ability to do that could be a feature.)

Grid
Grid1333×750 147 KB

5.) While V6 view speeds may be improved over V5, IMO, the non-Cycles display speeds should be a lot faster for what is being done. I have experienced how the non-Cycles display speed will present an issue for working on the kind of projects that 64-Bit and Grasshopper’s power and promise offers.

( I am not sure why Rendered mode shows bumpmaps as a blue haze over the diffusemaps; it doesn’t really help.)

*I don’t think a small diner with a low-polygon interior is a large project.

I have parts in the living room to refit my computer with 3.9GHz 12-core, 32GB goodness, but a 70-100% increase in single-core computational power will only go so far.