I just tried rendering with WIP/RH7. I installed “rhino-render-next” via the package manager first. now there are three renderers “RhinoRender”, “Rhino Render Next” and “Rhino Legacy”. which one is the cycles renderer, “RhinoRender” or “Rhino Render Next”?
“RhinoRender” and “Rhino Render Next” work when I use the “Raytraced” diplaymode, but when I try the _render command (rendering in the render window) nothing happens when I set the current renderer to “Rhino Render Next”, it only works when the current renderer is set to “Rhino Render”. When I set the samples in the render settings, it does not have an effect on the windowed rendering, it only affects the Raytraced viewport. Whatever render sample value I set, in the render window it will alway do 50 samples.
Don’t install Rhino Render Next in WIP/V7. It was really meant only as a stop-gap solution for V6. I don’t make any updates to it.
In WIP/V7 Rhino Render is . In WIP/V7 the sample count (and integrator settings) are governed by the Quality drop-down in the Rendering panel.
Current settings are documented here: https://docs.mcneel.com/rhino/7/help/en-us/index.htm#documentproperties/render.htm (under quality)
ok
how can I uininstall the “Rhino Render Next” package? I don’t see any option in the package manager to remove a package.
the dropdown changes to different sample counts, ok, got it. but how can I set a custom value?
also in the package manager are three different types of materials available:
- raytraced-blend-material
- taytraced-material
- rhino-pbr-material
since cycles was called “raytraced” in V6, is this a similar situation compared to the render package? are some just for V6 and others for V7? or can I use them all in V7 (and V6)? what is the difference? do they all work out of rhino or with GH?
Currently you can’t for _Render. You can use -ViewCaptureTo* for renders that need the settings in Tools > Options > Cycles.
These two should work. I haven’t really tested much with the WIP though. No GH necessary for these.
This one is superseded by the Physically Based Material that already is in WIP/V7. Don’t install it.
currently I can’t set a custom sample size for the render window? I assume this will be enabled later. I tried V7 to see if rendering (in window) finally works for my setup. until the sample size can’t be set I consider it unusable.
the good thing though: the quality dropdown in the render settings sidebar never did anything in V6 AFAIK. good to see that it does now. the settings which are influenced by it seem to make sense. just the sample size should not be controlled by it, imo. also custom presets should be creatable, which would then be available in the dropdown of course.
regarding the rhino-pbr-material package:
did I break anything by installing it with the package manager in V7?
again, no option to remove it.
the package manager should offer some info regarding this. is a package meant for V6 or V7? or maybe in V6 and V7 let the package manager show only those packages that are meant for Rhino verison in use. it is too confusing now.
I don’t know yet, possibly.
There is no uninstall button in Rhino for Plug-ins, but you can go to Tools > Options > Plug-ins. Click on the plug-in you want to remove. You should see somewhere at the bottom I think a way to open the file location of the plug-in. This should open the file explorer. Here you then physically remove the file(s) of the plug-in. Restarting Rhino then should have you have the plug-in removed.
There is no real harm in having those packages installed, they just aren’t as good as what is already in Rhino WIP/V7, so unncessary and irrelevant - they are in the package manager for v6 users who have no access to the WIP for whatever reason.
ok thanks.
I found this. like described over there, I removed the packages from the directory. now they are not shown in the package managers’ list of installed packages anymore. cleaner now 
giving the package manager the ability to only show packages that are relevant for the rhino version it is running on would be a good idea. again: would help to avoide confusion.
looks like v7 isn’t for me at its current state. was curious if my AMD GPUs are finally better supported by cycles but the performance is still bad, so no improvement here jet. it really is a shame that AMD GPUs don’t perform nearly as good as they should.
I wonder if it is the same situation on Rhino for Mac. does rhino-cycles utilize AMD GPUs better on OSX compared to windows?
WIP has still same Cycles codebase as v6. I am working on a rebase on latest Cycles though, so hopefully this or next month you should see improvements over v6.
that sounds great, looking forward to this!
but the cycles code base can’t be blamed for the bad AMD GPU performance. if we were talking about very new GPUs like NAVI based ones, then maybe. but it’s the performance of polaris and vega based cards that is nowhere near where it should be, whereas nvidia cards new and old perform like expected.
example:
RX580 performs muuuch worse than a GTX1060 in rhino cycles. in real cycles / blender cycles they perform about the same (including older blender versions like2.7x). in any other 3d application including games, these two GPUs perform pretty much the identical - just not in rhino-cycles. even a Vega64, which I had in my system for some time, performs worse than a GTX1060 in rhino-cyles. of course a vega64 is a much more capable than a GTX1060 and any benchmark of cycles/blender (regardless if 2.7x or newer 2.8) shows that. just the same in other 3d applications and games. again, it is only rhino cycles where all AMD GPUs underperform massively.
so it can’t be about the cycles code base.
quite some time ago you mentioned that you basically just have to connect some wires to make cycles work in rhino. I guess you did the green wires well but messed up or forgot about some of the red wires 
my hope is that the new rebase is a chance to get all the wiring right this time 
To some extent it can, actually. Just a few weeks ago in upstream Cycles a fix was made for a new feature (Voronoi node new functionality) that improved OpenCL performance by more than halving the render time. Our v6 Cycles codebase is over a year old, a large number of performance fixes have been made to the Cycles kernels on OpenCL. Our version also has quite many features on by default causing the OpenCL to render slower as well. Further using Render command is much slower in v6 using Cycles for various reasons, not just Cycles.
After the rebase OpenCL performance should be much closer to Blender Cycles, also Render command performance should be much better in the render window.
ok, sounds plausible.
even more exited about the rebase now!
though I still feel that there might be something true about my green and red wire analogy
I also remember that drawing the render-result/image on screen and updating it caused some performance problems. for V7 I wish there would be a mode that does the rendering without any visual feedback apart from a progress bar. when I have all my settings right and know what I’m rendering, then I don’t need to have a visual representation of the process. actually I don’t need any viewport/rhino-window at all then. a simplified rhino instance that only lives in the tray or has nothing but the command window. that would be all I need for chewing through a render batch. for working on a file at the same time I can have a second rhino instance open of course.
regarding performance in general and working while rendering:
doing a render batch on my system (2700X and two RX580s) and having a second rhino instance open at the same time to work on another file works perfectly fine. I don’t feel any performance loss, especially when I let the CPU do the cycles rendering. the system is still fully responsive. I remember times when I avoided doing anything with the computer while it was rendering, just looking at it felt to be too much.
oh, and since I mentioned “render batch”:
a render-batch/queue is something I hope will be implemented into V7.
You have this already with -ViewCaptureTo* commands. A bit of a workaround maybe, but you could first set sample count to 1/pause current Raytraced, then start the capture. If a full (re)render is needed by the command it’ll all happen with just the progress bar as update. And only at the end is the final result copied from the low-level Cycles.
yes, true, -ViewCaptureToFile is technically very similar to what described. this combined with macros is my prefered method to make a render batch. but it is a somewhat strange implementation that feels sketchy somehow. it just doesen’t feel right. I’m just refering to the workflow and user interface.
I have something more userfriendly in mind. more integrated and accessible like most other features in rhino, via a panel in the sidebar. it would not have to be exclusively for cycles renderings but could be a place where all sorts of batch processing could be handeled. I think there are many users that aren’t comfortable with coding and don’t write their own scripts.
something like this:
You are right of course. I was just saying there are currently already ways to do so. A nice enduser solution would be best of course.
yes it would be, hope something like this will be considered for V7.
but I’m completely off topic now.
would it be OK to split this suggestion of into a new post?
V7 whish: batch processing tab
9 posts were split to a new topic: OpenCL support for Cycles