Raytraced mode slowness


#1

Hi @nathanletwory

I don’t know if this is new or has been there for a while since I have not been testing or using Cycles (Raytraced view mode) too much. But tried recently and with the latest V6 RC3 installed, noticed 2 things that make it super slow and tough to even try to use:

  1. When rotating the view and auto-switching to Rendered mode for speed, the performance of the temp-rendered mode is MUCH slower than if I actually switch to Rendered mode, so it’s not that much of a speedup for vport navigation in Raytraced mode

  2. interference with compiled script commands: using many in-house tools that are compiled RhinoScripts - it seems that unlike regular Rhino commands, the compiled script command-line actions have to “wait” for each Raytraced step to move forward, making these commands super slow and unusable in Raytraced mode (for example MultiviewCapture script we use to automate capturing many named views at once) - navigating the command line options in raytraced mode takes forever. I hope there is a way to make the script runtime independent of Raytrace refresh speed.

thanks,

–jarek


(Nathan 'jesterKing' Letwory) #2

Hmm, I don’t think I have seen that yet - but this could be related to skylight shadows. Perhaps the downgraded rendered mode isn’t properly going into dynamic mode? @DavidEranen or @andy - any idea about this?

Not sure about this, I haven’t really used these scripts. Does your multiview capture script really many views at the same time, or still sequentially? As a work around until I better understand what is going on you could set sample count for viewports to 2 or 3. That will ensure Raytraced is not running when you don’t really need it. The nicest would be to have scripting access to the pause button on realtime render integrations, but that is still an open YT item: RH-42000. I’ll add this discussion URL to the issue so this gets notified if and when the item gets successfully resolved.

/Nathan


#3

I tried with no skylight or shadows (it affects the temp-rendered mode) - makes no difference, still stays very slow.

You can try this one:

  • the command is MultiViewCapture, but it represents general behavior of commands that come from compiled scripts - they all perform much slower in CommandLine refresh and interactivity than native Rhino commands while Cycles is running heavier scene.

Yes, it runs sequentially. If I set the sample count to 2 or 3, wouldn’t viewcaptured images only do the same ?

I may need to work on preparing some better samples for you to look at. Thanks!

–jarek


(Nathan 'jesterKing' Letwory) #4

When scripting the -ViewCaptureFile command you can set the NumberOfPasses option to what you need. If you use a count that is larger than what the active viewport is currently at a new, offscreen render is started for the Raytraced view


#5

Oh good to know - I may need to update the script!

It still would be good if Raytraced did not slow down scripts SO much… Hope it can be achieved eventually.

thanks


(Nathan 'jesterKing' Letwory) #6

I think for scripts the best would be to have that API/Commands that allow to script the pausing of it.


#7

Agree, pausing or/and enabling-disabling the temp rendered mode display you have kicking-in while rotating the viewport. Could that be added to the wish pile please ?


(Nathan 'jesterKing' Letwory) #8

What would you expect to see while rotating the viewport? I was under the impression that with setting the Dynamic Redraw target frame rate to something higher the display would degrade easier (Options > Views | Dynamic Redraw). @andy, @DavidEranen - I can’t seem to get the ogl version to degrade more when target frame isn’t hit. Is this expected?


#9

I like the idea of switching to Rendered while rotating as-is (as long as it performs as fast as Rendered mode - which is currently not the case over here - I remember it used to in the WIP/Betas). My above wish was to allow controlling this switch also from the script for any scripts that deal with manipulating the viewport or real-time object or camera interactions.


(Nathan 'jesterKing' Letwory) #10

I believe this is how it already is supposed to work, but I don’t know enough yet about the expected display behaviour with scripting. @pascal is this something you can shed some light on?


(Pascal Golay) #11

I have not looked at this at all I’m afraid.

-Pascal


(Nathan 'jesterKing' Letwory) #12

I meant viewport performance in general when scripted - or at least Rendered mode (not Raytraced).


#13

Here the Rendered mode on its own works OK (with interactive scripts) - no major slowdowns.

Let me break down what I am after or trying to report:

  1. currently in Raytraced mode, scripts work very very slow - even command line clicks etc. - seems like the Raytraced mode is affecting the script execution workflow. Any script and its command-line interactions. Was not the case before with Neon.

  2. The temp-Rendered mode that automatically kicks-in with Raytraced on view rotations seems very slow compared to regular Rendered mode (both look the same) - this is not scripting related, but rather general observation.

  3. If the #2 is fixed and usable, it would be good to have a scriptable control to enable/disable the temp-Rendered mode, that currently automatically kicks-in only at view rotations in Raytraced.

Hope it makes sense : )


(Nathan 'jesterKing' Letwory) #14

Raytraced may cause UI slowdown especially if the scene is heavy and the GPU also drives the display. Does entire Windows feel slower when Raytraced is active?

If you are on a machine that also has an integrated GPU, can you try plugging monitor into that - or if you have multiple monitors, make sure it is set as main display adapter? Does it work any better?

There is a Throttle setting in Options > Cycles. It is not the best way (it increases the sleep time between rendered passes), but it might give you a somewhat more responsive UI.


#15

I’d just like to jump on to this topic - I’m working with moderately complex models in Cycles and noticing an absolutely unworkable slowdown when changing layer visibility (surprisingly this seems to be most egregious when turning layers off).

Example behavior is to turn off a layer with ( ~100 < N < ~10000 ] polygons followed by a delay of 5+ minutes with complete UI lockup ( I wrote this post between lockups ).

My system has two x1080 Ti GPUs running in SLI mode (recognized by rhino).

I tried Nathan’s suggestion above (increasing throttling to 25ms) with no improvement in usability.

My next test will be to set the viewport to wireframe and test changing layer visibility between uses.

This problem is a new one, I did not see this issue with Rhino V5.

Hope this is helpful (file attached here)


(Nathan 'jesterKing' Letwory) #16

I’ll investigate this later, but for Cycles you don’t have to use SLI, both devices can be selected together as socalled multidevice.


(Nathan 'jesterKing' Letwory) #17

you uploaded the .rhl file. please upload the 3dm instead :slight_smile: I can’t do much useful with the lock file…


#18

oops! Sorry about that.

This should be the correct file.


(Nathan 'jesterKing' Letwory) #19

I don’t see anything in this model that would cause such exorbitant delays. I have to test tomorrow more though, as currently my machine is set up with the monitor attached to the Intel HD Graphics 630, and Raytraced is running on a headless Radeon Pro WX9100 or Nvidia GTX 1060. I can toggle between the Radeon and the GTX remotely just fine, but I can’t change the monitor cable over VNC :wink:

Perhaps you could try taking out the SLI and using for Raytraced one of the GPUs without any monitor attached to it - Does that give better response?


(Brian Gillespie) #20

RH-42000 is fixed in the latest Service Release Candidate