Grasshopper Display Messed-up

I just uninstalled rhino6, didn`t work.

If anything, it should work better in RH6.
Can you post the internalized results from your definition in a reduced gh file?

Here it is.
Thanks. (58.0 KB)

Yes. This is a typical point in the model. {3.8383e+7, 3.8443e+6, 33.3}

I don’t follow the logic of subtracting one point from another and treating the result as a vector (or I wouldn’t do it that way), but the model basically looks OK in R6. Except for ‘Rendered’, ‘Arctic’ and ‘Raytraced’ modes which all show blank screens. :frowning:

Thanks Oster and Wim,

It`s the problem far from origin point.
Thank you all for the help!


Except for ‘Rendered’, ‘Arctic’ and ‘Raytraced’ modes which all show blank screens.

This is because now the custom preview component has a material input instead of a shader input. You set materials there and they will actually render as those materials as a gh preview when on those display modes.

Note that these materials can be document materials as well.

1 Like

COOL, this is nice.

Putting a name of material as input works. But the shininess still doesn’t work for me. Am I the.only one using this ?

Thanks Michael. I just don’t understand the lack of concern at McNeel for compatibility (and usability!). One of the greatest features of R6 is the dazzling ‘Rendered’ mode but all my old GH models are useless in this mode unless I painstakingly replace all the Custom Preview color inputs with materials - even contours!? Not only is that inconvenient, it makes the modified files incompatible with R5? That’s really uncalled for and rather rude. Why can’t color values in old GH models be treated as the old “default material”? The geeky justifications from McNeel for making life difficult for users is quickly wearing thin.

FYI, you should add custom preview to your R5 GH files that do not use it from the beginning,
but there’s no problem seeing your geometries in R6 Arctic or Render mode without replacing the original Custom Preview’s shader input with material…

I don’t understand this? Please clarify? In R5, I’ve used Custom Preview the only way I know how. I get the same result with my own models as I did with @Lei_Yang1’s model in this thread. No GH preview geometry visible in those three rendering modes.

As @Michael_Pryor said, if you don’t have Custom Preview in your old file, then you have to add it inevitably to see it in R6 Render mode.
But if the old files had a Custom Preview with shader input from the first place, you don’t have to replace it to the material input.

That doesn’t quite match my experience @HS_Kim. My old GH files do have Custom Preview components. Ghosted preview looks like this:

Rendered preview looks like this - missing curves, contours and curvature graphs (and what happened to the blue window frames?). Enable/Disable Preview on Custom Preview components has no effect, the components themselves must be disabled. No matter what the technical reasons are for this behavior, it is a disruption of prior practice - an unpleasant surprise,

By the way, while these images don’t show it, I have a Rhino model that contains additional geometry (hulls, interior accommodation details) that look great in Rendered mode but I can’t show my full GH model with those Rhino parts rendered.

As for Curves or points, yes. This has been discussed…

I’m sure it has. And it will be discussed over and over as each person discovers this disappointing “feature”, until Rhino is modified to support users’ very reasonable expectations.

Out of curiosity. Do you happen to maybe have the display of curves turned off for rendered modes?

Nope. As discussed in the other thread, curves and points cannot be previewed in these render modes.

Hello guys,

It is quite a impassioned discussion here when I woke up.
For me the workflow of using rhino and GH is at the design stage. when you talk about the render model with the ‘custom preview’, I often use it as a color shader to differ parts of building and will not assign materials to it even in R6 because I personally consider it won`t be efficient in a company work flow.
What we do is to transfer the models into our VR system and enrich the scene based on the same model resources and maps.

Another Feature I would say evulationary improvement is the ‘multi-thread’ calculating of the components. However the concept is only used for limited numbers of component. So I was wandering if in the coming future it would be implemeted in majority of the components? or further step, in majority of third part plug-ins?@David

All the best

We had to add the multi-threading to GH1 without breaking the existing SDK, and we were also worried about changing the way things worked even without changing the public SDK, just because it could have been devastating if we got it wrong.

This is not a problem for future versions, because the SDK is completely different already. Thus, implementing multi-threading can happen on a much deeper level, in a way that is completely invisible to component developers. You’d still need to be able to switch it off for specific components (either as an end-user or as a programmer), but it should ‘just work’ most of the time.