It has been a while since Cycles (Raytraced mode) does not work on my system.
I have reset all the Cycles options to defaults (not Advanced ones, just the ones in the main Options dialog), and also made sure Raytraced mode also is default. Still nothing - meaning it shows the passes progressing, but never goes beyond the OpenGL preview that should “fade” into the refining raytraced preview…
At some point in the past I might have messed with some Advanced settings per @nathanletwory direction since I was trying to fix the slow viewport performance, but I don’t remember what might have changes. Quite possible it doesn’t work since then.
Is there any way to wipe all the settings clean, or anything specific to look at to make Cycles / Raytraced work again ?
EDIT: the Raytrace actually works, but looks like the Fade from OpenGL to raytraced is taking forever ( like 30 seconds or so) - so it hits ~600 passes before anything shows up.
I did reset all advanced settings too (got rid of the “Bold” font ones that define non-default settings) but the problem is still here… Any ideas ?
Maybe I still need him…
Now after reset the “OpenGL” mode that used to fade to Cycles doesn’t work - is Cycles all the time, even when rotating viewport. Last time I checked (and it was long time ago) it used to switch to OpenGL for view rotations, and Fade back to Cycles once stopped…
Yes, that did the trick. The reason I could not make it work before, even though I tried almost every advanced setting, is that is takes no effect until I switch to some other display mode and then back to Raytraced. Probably the case with all other advanced settings. Any way to have them take effect immediately or this is some design limitation?
While we are at it, a few other notes and questions for Cycles:
The “FastDraw” (OpenGL) mode was very slow over here and it took me a while to figure out why. It turns out it was the combination of Skylight and Shadows that are ON by default. There are two problems with that: a) in Rhino in general, the skylight quality and cast shadows quality use one slider that is unbalanced. Low values look OK for Skylight already, but to get decent Cast Shadows, one needs to go much higher. When both are ON, higher values make Skylight slow down the whole thing a lot. I will bring this up in a separate post one day, but for now my note is, since Shadows panel is greyed out for Cycles (Shadow Quality defaults = 4096), there is no way in UI to control that part of the FastDraw OpenGL preview, therefore cast shadow + skylight combo will be slow by default. It can be changed via scripting or editing the exported .ini file of Raytraced display mode and importing it back, but that is not for average user. I guess all I say above is I would consider having the Shadows panel still enabled for Raytraced…
Which setting controls the amount of time to pass before Cycles start rendering again, after camera move? Is it “Throtle”?
Is there a way to control: Set or Get the status of FastDraw from command line or Scripting? I know you can set it via command, but what about getting its current status? Can this be done via Python?
_TogglePausedActiveRealtimeViewport command - this is another interesting control; Is there a way to Get current status of the “Pause” either via reading command line message or RhinoCommon/Python? So far I don’t see a way…
Thanks again for your help. Hope you can give me some hints when to take a break for your programming studies. I can offer you some RhinoScript tutoring if you want to get really advanced
That has been a deliberate decision on my part to not (yet) do. It could be done automatically, but that could mean potentially locking up Rhino for a longer time especially if a heavy scene is currently being Raytraced. To not get reports of “Rhino hanging after just changing one simple setting” I made it like this. If you can convince me it is absolutely needed because your life depends on it I can reconsider this.
There is no control for that. The throttle is for pause between passes, which also means increase in time to reach maximum samples count - setting it to 1000 would mean one second between each sample pass, meaning 500 seconds extra render time if you have 500 samples set.
I think it could already be done with Python - but I’ll have to check.
Last week I merged code that will go out in 6SR12. It adds options to the command where you can specifiy which state it should go to:
_TogglePausedActiveRealtimeViewport _Enter // same as toggle
_ToggleLockedActiveRealtimeViewport _Enter // same as toggle
That said, you can use Python to query the current status already. Raytraced (and any engine implementing RealtimeDisplayMode) status can be checked with like so:
import scriptcontext as sc
rtdm = sc.doc.Views.ActiveView.RealtimeDisplayMode
rtdm.Paused = not rtdm.Paused # set the state yourself
print("Active view not a realtime display mode")
I don’t think it is critical, especially if they way it is being a safety measure… It just makes is less discoverable since intuitively making changes there seems to have no effect, unless the user knows to switch back-and-forth.Maybe there could be a popup if any of the Cycles adv. settings were changed that they will take no effect until the mode is restarted…I don’t know, doesn’t seem very elegant either. I don’t have a good solution other than writing this somewhere in a help file…
Simplest solution could be to defaulting the ShadowMap quality to 512 or 1024 max, for the Raytraced mode (you can see this in INI file after exporting the display mode), but it is still less flexible for users that need sharp cast shadows and no skylight; so again, enabling shadows settings may be better so people can freely adjust it.
Instead of convincing you for #1, I will try for this one as I actually think having such setting would improve the smoothness of workflow in Cycles with FastDraw ON. Having a defined delay to kick-in the raytracing would allow to play with the camera adjustments, which often consist of a series of micro-movements, until the view is set and one just waits to see it raytraced. Currently with no delay there is a micro-hang between the micro-movements. I feel like having this at 300-500ms by default could help for FastDraw mode, if this is achievable as an additional setting.
I do agree the current state isn’t the easiest to grasp. I don’t find it ideal myself, either. It certainly must be improved upon, but I think that this might go into v7.
The help-file is indeed the best place currently - that reminds me I still have to write documentation for all the commands RhinoCycles provides
It is indeed likely we will just hard-code this to some low, but acceptable setting. I’m not knowledgable enough currently about how I could get any UI fiddling opportunities for the user done, but I’ll learn about it soon enough without doubt.
Very nice idea, but will have to go to v7. If I get my other stuff cleaned up in a timely manner I might push it to some 6 SR, but we won’t be doing those forever either (i.o.w. time is running out). Anyway: RH-49724
No, that is a function an engine has to implement if it wants to signal the usage of fast draw to the pipeline. What you need is the plug-in setting for RhinoCycles for this. Ignore anything that says virtual in the function or property signatures.
I was actually referring to the method that stevebaer showed you for controlling UseTessellationShadersin this thread. To get it to work with Raytraced you need the plug-in ID. Here a snippet:
import Rhino as rh
settings = rh.PlugIns.PlugIn.GetPluginSettings(System.Guid("9bc28e9e-7a6c-4b8f-a0c6-3d05e02d1b97"), True)
cursetting = settings.GetBool("UseFastDraw")
print("Old setting", cursetting)
settings.SetBool("UseFastDraw", not cursetting)
print("New setting", settings.GetBool("UseFastDraw"))
You could make it so that you have a button that runs this, then after toggling you toggle with a macro the viewport mode to say Wireframe and back to Raytraced.
This is indeed the RDID for Raytraced:
It is Guid.Empty for all non-realtime display modes. For instance you’d get an ID other than Guid.Empty for ProRender display mode, and so on for each engine that opts to provide an integrated display mode.
Fingers crossed for V6, considering the time span between official Rhino releases Thanks for considering it. I am trying to have the walkthrough plugin I am working on play nicely with cycles, which this setting would help a lot with; otherwise I am trying to use all the other things you helped me with above to implement the “delay” while on the move.
Thanks for all the other clarifications and samples - I will test it soon but looks like I have all I needed now!
Hi Nathan, the code above works well and changes the setting when the script finishes but seems to have no effect when the script is still running. Is there anything to make the setting change “stick” and update instantly?
reviving this topic as I ran into similar issue trying to control the skylight degradation during the script runtime. I am trying to set the degradation at the beginning of the script, and then set it back to “1” after the script ends. The problem is, any changes made to the advanced options don’t take effect until the script finishes. SavePluginSettings doesn’t seem to help to force the change in settings to be picked up in script runtime. Do you have any suggestions how to make it work instantly?
import rhinoscriptsyntax as rs
settings = Rhino.PlugIns.PlugIn.GetPluginSettings(Rhino.RhinoApp.CurrentRhinoId, False)
s = settings.GetChild("Options").GetChild("OpenGL")
print "setting to 3"
print "setting to 2"
print "setting to 1"