I’m having trouble getting grasshopper to preview while in the “rendered” setting. It works as expected in wireframe & shaded, however nothing is shown if I’m in a rendered viewport. If I bake selected geometry it appears as expected. The rendered options are all set to defaults.
This isn’t a critical problem (workarounds are easy) but it’s still mildly annoying.
Rhino Work In Progress
(6.0.17157.8191, 06/06/2017)
Thanks, I see that too… filed as https://mcneel.myjetbrains.com/youtrack/issue/RH-39816
This is not a bug. Rendered viewport mode is supposed to show a preview of what the rendering looks like. Since GH previews are not included in the rendering, they do not show up in Rendered. If you want to see stuff in Rendered (and indeed in Raytraced and in the _Render output), then you’ll need to use a [Custom Display] component and feed it your geometry + material.
I recalled being able to see previews a few weeks ago in Rendered… this stuff must have been in flux maybe. It was nice that it just did it but maybe I’m remembering incorrectly how the def was set up.
True, this is a fairly new change, but it is deliberate. You may have seen some stuff about this on the meeting notes a few weeks back.
Ya I agree Brian, I had several templates setup with GH routines previewing
in the rendered viewport. It was nice because I had material definitions
for different layers, and unfortunately those materials don’t show up in
any of the viewport modes that support GH previews. It’d be really nice if
we could bring that functionality back 
How did you use those layer materials with GH previews?
The different material definitions were for Rhino objects only. For
example, I used grasshopper to project curves onto the different colored
Rhino surfaces, editing the curves with number sliders and various
equations before baking when I was happy with the outcome.
I see. If the display mode uses object rendering materials (or a rendering material override) then Grasshopper will not draw previews. For Rendered this setting cannot be altered. However it sounds like what you were doing before is no longer possible, i.e. use Render Materials for Rhino objects while having GH previews at the same time. These are now mutually exclusive.
I admit it’s not really as ideal/flexible as I’d like, but this approach did allow us to experiment with such behaviour within the existing display settings. We briefly discussed adding another checkbox to each display mode specifically for Grasshopper previews, but in the end decided to stick with the current design.
This is something we’ll be looking into again come GH2 and Rhino7, to see if we can’t come up with a better generic approach to this sort of thing.
Oh god! This is awful! Please do something about it. It completely ruins my workflow. Why not just let the user decide to keep smthing that some ppl got completely used to?
Well, a number of reasons for, some against. For example I’m worried about option-bloat. The more options you expose the harder it becomes to support people when problems arise. It also makes the software unfriendly to new or casual users.
Another reason is consistency. We want GH to be able to push geometry and materials to the render engines (Rhino Render, Cycles, Vray, all of them). The Rendered Viewport is basically a preview of what happens if you were to actually render the scene, or it can be thought of as a render engine in its own right. Anything that works for Cycles and Rhino Render but doesn’t work for Rendered is counter to the whole idea behind rendered viewports.
Most importantly however is that if you add a new feature but immediately give people the option to disable it, you’ll never figure out how to improve upon it. Any feedback you may have got is now gone because anybody with feedback to give doesn’t use the feature.
So let’s work out how to improve upon this. What is it about Rendered that makes it a superior working mode for you than Shaded?
Thanks for the answer. First of all, I completely understand your reasons. But. Displaying rendered materials in view port is a must in order to fix mappings plus it is also extremely useful when designing. This plus being able to see all grasshoppers elements in the same view port (while designing) was a pretty strong combo.Now its either one or the other. Cant really find a way to see both textured geometry (don’t care bout shading quality, etc) and grasshopper curves, points, etc in the same view port. Maybe I’m missing something but if i ain’t it means that we just lost a mega strong design tool…What do u think?
Yep, if you need to develop your Grasshopper and texture mapping/material in tandem, then there’s no way to really see them at the same time right now, short of overriding the display mode of individual objects and setting them all to ‘rendered’ via the _SetObjectDisplayMode command.
A lot of McNeel devs are meeting up in London next week for the Shape2Fabrication event, and everyone who is potentially involved in this stuff will be there so we’ll discuss how to expose this functionality to make it more flexible without becoming unintelligible.
I don’t think forcing people to give up what they had is the best way to offer new features. Much better to entice and persuade that a new option is better than to demand of customers that they suffer the consequences and take the time to convince McNeel that their pain is real.
A related thread (how many does it take? how long must we wait?):
We weren’t sure how many people wanted or needed to use Grasshopper in Arctic and Rendered viewport modes. It could have been a very low number, it is probably a reasonably low number, but it may have been much more common than we expected.
We didn’t know how many people would like to send geometry+materials directly from Grasshopper into the render pipeline, and there was no way of knowing it because it wasn’t possible before.
It isn’t really about the number of people, but about the severity of the cases. It takes time for a concise picture to emerge from user complaints. Are people unhappy because something changed? Are they unhappy because something was changed for the worse? Are they unhappy because a workaround they used to rely on no longer works? All these cases require different solutions, and it does take time to both compile and analyse the list.
Various alternative ways to implement this were discussed internally before the behaviour was changed, and in the end we decided to go with the one which didn’t require more UI. Which relied on existing design-choices to make it consistent with the way we imagine Rhino is used. Of course people are under no obligation to use Rhino the way we intended, but it’s good anyway to know when they don’t.
We’ll discuss this again next week when a lot of us meet up in London, and then the time-frame will depend on which solution we pick. Will we add an option to Grasshopper Preferences? To the GH document settings? To the Rhino viewmode options? To the Custom Preview component? Pick a different option-less approach? I don’t know yet.
This is the kind of question that is best answered by usability testing before forcing everyone to cope with changes. Developers discussing ideas and options among themselves is only a preliminary to providing solutions that will please customers instead of annoy them.
I also believe it is a mistake to assume that this forum accurately represents your entire user base. It’s not for everyone. Several people I know have Rhino as just one of their CAD tools and they will never show up here to provide any feedback. In general (for all products, all companies), I too am inclined to find answers and workarounds on my own and to avoid relying on customer support at all costs. Coping, not hoping.
========= P.S. Edited to move this paragraph and its resolution - it’s a tangent =========
One example of an old frustrating design decision, that I wasn’t even aware of until I began evaluating R6 on a new laptop, is that my Rhino files are not portable!? Unrelated to R6, ‘PictureFrame’ images, material texture images associated with imported geometry (a marine stove, for example) and images associated with user-defined ‘Environments’ are all lost when the files are moved or the folder name is changed. I haven’t found any way to fix this yet. In essence, the files are corrupted. Data has been lost by simply moving the files. (*)
Later - For future reference (not that anyone will ever find it here), I just stmbled onto the fix for my missing files:
Now I just have to fix each one… every image in every file, one at a time. It may sound like whining over a trivial point (and it is), but the cumulative impact of so many obstacles in the R5 to R6 migration is mind numbing.
We put this feature in a Beta release so people would test it. Not regular users, only people who go out of their way to test the beta. Very few complaints came in at first (though there was plenty of confusion), and people weren’t particularly devastated. Based on this -what can only be described as- “usability testing” the feature eventually just became part of the official Rhino6 release.
Now it has to be changed in an official product, which makes it a lot more dangerous.
I don’t know what this is about, sounds like some of the Rhino tech support needs to be told.
Sure, we know that, but we don’t really have another way to get in touch with the rest.
I made the same reply on another thread,
https://discourse.mcneel.com/t/how-to-show-curves-and-points-in-rendered-and-or-arctic-mode/56227/9
but I thought others might find this workaround helpful,
I know this topic is old, but I just ran into the same issue of rendering curves from GH as an animation (this makes it impossible for me to bake and set a layer material for every frame. the Human plugin has a custom line weight setting which converts lines into meshes so that they can be seen in the rendered viewport. https://www.food4rhino.com/app/human
