Raytraced mode slowness

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

-Pascal

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

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 : )

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.

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)

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

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

oops! Sorry about that.

This should be the correct file.

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?

RH-42000 is fixed in the latest Service Release Candidate

So what is the actual change/fix to look for here ?

The linked YT item RH-42000 is about giving macro/scripting support to pause and unpause Raytraced. This discourse topic was linked to the YT item.

This release candidate though also has speed improvement for ViewCapture* commands that need to rerender. Instead of updating the final result buffer during the rendering it is now done only at the end. This will give a huge performance boost especially for large resolution captures.

There wasn’t a separate YT item when I made the changes, but you can check it here if you feel nerdily inclined: https://github.com/mcneel/RhinoCycles/commits/rhino-6.6 . the commits from May 18th, 2018.

Guys -
What’s the ACTUAL outlook for making RAYTRACED mode WORKABLE ? SPEEEEED and NOISE remain an issue.
Thanks -
-C.

1 Like

Thanks Nathan, good to know! I will take a closer look at these…

_TogglePausedActiveRealtimeViewport you’ll probably like the best. With it you can ensure the VP isn’t running while you’re doing a capture in the case you have settings that require a rerender for the capture = more compute power for the capture.

Performance improvements and bugfixing are always in progress.

interesting… One problem I see with this method for scripting is that there is no way to tell the current toggle state. Maybe there should be a command-line option (Enabled=Yes) or a report printer in command line to parse and see the currently set state ?

Hmm, good point. If you’re scripting with Python you could already do this with RhinoCommon. The commands are implemented in C# as follows:


	public abstract class BaseToggleActiveViewportStateCommand : Command
	{
		public abstract bool ToggleStateFunction(RealtimeDisplayMode dm);

		protected override Result RunCommand(RhinoDoc doc, RunMode mode)
		{
			var dm = doc.Views.ActiveView.RealtimeDisplayMode;
			if (ToggleStateFunction(dm)) return Result.Success;
			RhinoApp.WriteLine(Localization.LocalizeString("Active view isn't in a realtime display mode", 1726));
			return Result.Nothing;
		}
	}
	public class PauseActiveRealtimeViewport : BaseToggleActiveViewportStateCommand
	{
		public override string EnglishName => "TogglePausedActiveRealtimeViewport";
		public override bool ToggleStateFunction(RealtimeDisplayMode dm)
		{
			if(dm != null)
			{
				dm.Paused = !dm.Paused;
				return true;
			}
			return false;
		}

	}
	public class LockActiveRealtimeViewport : BaseToggleActiveViewportStateCommand
	{
		public override string EnglishName => "ToggleLockedActiveRealtimeViewport";

		public override bool ToggleStateFunction(RealtimeDisplayMode dm)
		{
			if(dm != null)
			{
				dm.Locked = !dm.Locked;
				return true;
			}
			return false;
		}
	}

In short you can query the properties RealtimeDisplayMode.Paused and RealtimeDisplayMode.Locked.

Does that work for you?

I’m not doing much in Python yet, and RhinoCommon part of it is way above my head. Doing pretty advanced stuff with RhinoScript though, that includes a lot of view manipulations and visual stuff.
I will look into the above. Need to learn that at some point, too.
But in general, toggle commands are more useful for macros and scripts if the user can tell the current state or the one that its being switched to…

–jarek

Of course: RH-46490. I meant the code bits as a way to do this already before you get a SR or RC with the necessary changes :slight_smile:

1 Like