The difference between Rhino 8.0 release and 8.5 has been really night and day, and the engine is so much better to use now.
I’m not sure, but I have some thoughts as a casual Rhino user about what I feel are my most missed features. These are not always bugs, but more items that I think really do need to be there in a mature RGB-only engine.
I know there are many advanced features in the Blender implementation of Cycles, and I don’t expect these to be all in there, as this would be very unreasonable.
I only created this thread, as I personally think the UI/UX problems are very dominant, and I am sometimes missing clarity on what I think is a really important part of Rhino 8. It seems a shame that such a good implementation and feedback gets lost in the noise of the UX/UI problems, or Mac vs Windows… debate.
Positives
-
Speed - Really, very fast even on the CPU, and my 13700K has been producing really good results, and I can often stop the integration early. The way the noise is resolved is really nice, and sometimes I retain some of it to maintain a particular aesthetic.
-
Ease of use - Again, most of the materials seem really easy to use, and I am glad that some materials have simple choices that make selecting easier.
-
CUDA/OptiX carryover is immensely fast, and I am glad this was ported into Rhino Cycles.
Actual problems
-
There seems to be a random occurrence when what I can only assume is the ChangeQueue is updating… or doesn’t at all. Sometimes numeric entry in the sliders doesn’t update, but sliding it does. It’s really annoying to flick between modes to force Raytraced to update, when you change arbitrary parameters in the materials.
-
Lockups unfortunately linked to whatever as-yet-unknown activities Rhino is doing. This isn’t so much the renderer, but seems to be the generic “locking” issue that occurs, and of course affects the viewport render as well.
Niggles
- While I generally would agree that Nvidia has the upper hand on GPUs, and I cannot see that changing anytime soon, it would be great if the even feature set of Blender Cycles 3.6 could make its way into Rhino Cycles.
My argument for this is that it often seems the case that users are steered towards Nvidia GPUs, and I am not entirely sure that I agree with this as a longer term solution.
We are now seeing the age of generalised APUs in both Ryzen 8000G series and Intel Meteor Lake. Specifically, both have implementations in Blender Cycles for complete hardware accelerated raytracing. I think it may be only a matter of time until waves of users are arriving in later 2024 with new AMD/Intel GPU architectures that do not have complete CUDA/OptiX-like rendering implementations for Rhino.
For me, it doesn’t matter, as I have an Nvidia card for now. But I reckon new users may end up mistaking that while many features are carried directly, that some are either just not there, or are currently non-operational.
I’d like to add that this question came up earlier this year, and I had responses from two individuals who were very helpful and understanding, but I imagine that my very minor need was well down the pecking order. All I am raising is that this may not remain the case for much longer.
Not only this, but I wonder if it would be a massive strong point for Rhino, as not even many renderers or other 3D applications support multiple complete sets of GPU types with hardware acceleration, and Rhino is so very close it seems. I am selfishly sustaining this argument despite me buying my way out generally, as I plan to setup a smaller m-ITX rig for everyday modelling, which will use my Intel Arc I still have. I will also run bleeding edge Rhino 8 on there too, and keep my main PC at stable releases.
Materials
-
I am hoping this is me being stupid, but I don’t understand why certain types of noise-like maps are locked to fixed sizes. “XL, XXXXS, S”… what? I would love for this to be erased in favour of a scale-free parameter. Having these makes no sense, as Cycles improvements give much better dynamic range, and sometimes you want a setting in-between or a setting that is too small for the scene. Anything noise-like should always be scale-free, as that always feels like one of the mathematical niceties of noise.
-
I think it is a little strange to not have any version of volumetric available. Even simple box-like fixed-density, fixed-anisotropy volumetrics have not been carried into Rhino Cycles. Sometimes it is bothersome, as it would really make renders stand out.
-
Paint. I really really dislike this material. I cannot understand what this is for. Can we please have something helpful like a car paint shader, and a pearl shader? We now have debates aplenty about certain unspeakable classes of surfacing, automotive design threads… but no car paint!
Anyway, this is not meant to be a proper complaint thread. It is more a set of observations based on my experience so far with Rhino 8 Cycles implementation, and I hope other users have more inputs.
On that note, thanks to anyone who has helped fix the early problems in Rhino 8 Cycles. It’s getting much better.
