RhinoBanana is a Rhino plugin that lets you send viewport images together with additional context from Rhino directly to Nano Banana and Nano Banana Pro (more AI models coming soon).
Key features
Viewport capture
Send shaded and rendered views and/or depth map images as visual input.
Layer → color mapping
RhinoBanana can map layer names to the colors used in the shaded preview and add this information to the prompt, helping guide the AI model.
Material guidance
Alternatively, you can send a rendered preview to guide materials and overall appearance.
Prompt generation and storage
Automatically generate prompts based on selected keywords and save them for later reuse.
Installation & compatibility
Install via Rhino Package Manager, search for RhinoBanana
Works on Rhino 7 and Rhino 8, macOS and Windows
Type RhinoBanana after install
Feedback & support
Please feel free to post issues, feature requests, or bug reports in this thread.
All feedback is welcome and helps shape future versions.
RhinoBanana 0.1.6 has just been published to the package manager.
This release focuses on making prompts easier to understand and refine, while fixing several issues.
What’s new
Improved Summary panel
See included previews (Shaded / Rendered / Depth) and the full prompt split into clear sections for quick review before rendering. You can now also override the predefined prompts for Shaded and Rendered images. A new system prompt has been introduced where general guidelines can be described.
Inline prompt editing
Jump straight from the summary into focused editors for system prompts, preview prompts, and override layer hints.
Layer hint overrides
Redefine what a layer represents in the prompt—without renaming it in Rhino—and save those overrides with the document. This allows you to override the layer name and thereby change how a color or layer is described in the prompt.
New “Report an issue” tool
Automatically collects Rhino, plugin, and platform information and provides a direct link for reporting issues.
Stability improvements
Fixes around display-mode overrides of Shaded and Rendered.
Resolves an issue where the generated prompt could return “invalid JSON”.
I use Rhino with a Grasshopper sketch running GHGL (Grasshopper OpenGL) display geometry in my Shaded views. My workspace looks like this. Viewports can be saved, printed, act in terms of display as normal geometry.
It would be interesting to be able to see the results of sending these directly to the nanobanana renderer via your plugin. However this geometry is invisible to the plugin and only a gray box is rendered.
Possible without having to bake the geometry and assign materials?
I think the issue is that RhinoBanana uses its own preview settings (Shaded and Rendered) to ensure that any custom settings don’t conflict with the way colours are used to represent materials, for instance. Because of this, it would require the ability to use a custom display style as the input, which isn’t a feature that exists right now.
That said, I think it’s a really good idea, and it could be generally useful.
What do the images look like under “Render Summary” in the Render tab? Those are the images that are being sent to the model.
Grazie per aver condiviso. Ok, è una rappresentazione molto precisa della geometria — è interessante. Avevo pensato a RhinoBanana principalmente come uno strumento rivolto agli architetti, ma sembra che possa essere rilevante anche per i designer di prodotto.
Hi Johan, thank you for developing this great plugin. For some reason, I can never receive the confirmation email for my account. Would you mind checking this one for me? Thank you
The bialetti can and the cup are on a table in a cafe house scene.
In the cup there shall be an espresso with some crema.
The environment shall be a stylish cafe in Manhattan, some people in the background.
The weather is a sunny morning.
The material of the bialetti can is aluminium with a used appearance.
From the espresso in the cup comes a little bit of steam.
Add a glass of drinking water to the scene.
You can see an overview of what is sent to the model by clicking “Show Prompt” in the Render tab. It might be that there is something in the that explains this more clearly.
What I would suggest is the following:
Make sure you use distinct preview colours for each material, and name the layers accordingly (for example: red – aluminium). You can also overwrite this in the “prompt summery”
You can add contextual geometry. For example, add a simple ground surface in the scene, name the layer “cafe”, and sketch some rough geometry of the kop and name the layer “hot espresso”.
I hope this maks sense.
Would you mind to share what you see in the “prompt summery” with me?
Good morning. I really enjoy the plugin but I have a few issues:
Sometimes it seems to ignore the selected view as a starting point and generates an image from the prompt with just some cues from the viewport, despite keeping the default system prompt.
I get previews of two views in the viewport, one shaded and one rendered (see below). It’s not clear which one is the starting point for the render, and they generate different results.
Is it possible to render previews in lower resolution and then use a seed number to increase the resolution?
Rendering in 4K results in error message: “Failed to fetch”, so my render (and credit) is lost.
Thank you for reporting this, and I’m glad that you enjoyed the plugin despite the issues. I’ll try to answer your questions in the same order as they were posed:
The function that relays the request should fail if no image is sent from the plugin, so I think it’s unlikely that the images did not reach the Nano Banana API. Rather, I think this points to a deeper issue, which is that these models are something of a black box, and it can be difficult to understand what makes them perform well. I expect this will improve over time as the models get better and as we gain more insight. At the moment, the default prompts are my best attempt to provide a good starting point, but this is definitely something that needs improvement as I gain more experience.
Maybe there should be a community thread here on the Rhino forum where people can post tips and tricks for getting good results?
I believe that the images being provided have equal influence on the output image. However, if you want, you could explicitly state that “image 1” should have more influence than “image 2”. (You would need to verify that these are indeed the names being used in the Prompt Summary.)
This is a really good question. I don’t think it’s possible to provide a seed for Nano Banana. The way I’m currently trying to address this issue is through upscaling, which I’m in the process of implementing. The idea is that you render a smaller image (e.g. 1K), and once you’re happy with the result, you upscale it to 4K or similar. The hope is that this can reduce the credit cost of using the plugin. Unfortunately, I’m not entirely satisfied with what seams to be state-of-the-art image upscaling at the moment. Right now, I’m looking at https://claid.ai for upscaling. If anyone has experience with better upscaling technology, I’d be very interested to hear about it.
This is a serious issue, and I need to investigate it further. Currently, credits are consumed right before the image is relayed back to the plugin — as late as possible — to prevent this from happening. There was an issue where the relay function ran out of memory; this has now been resolved. The last occurrence was about five days ago. Have you experienced this issue at any point between then and now?
I’ve added 20 credits to your account, and I hope this will cover the cost. Please let me know if that’s not the case.
I need to experiment more, but it seems like adding more information about the surroundings in the prompt can make the render deviate a lot from the viewport. Also, since the prompts are not saved in the 3DM file itself, it’s easy to accidentally have the wrong one selected.
Yes, I read that this has to do with the material mapping, but I don’t understand exactly how. As I’ve understood “color-by-layer” (shaded preview) uses layer names to guide the color of the materials, where as “render preview” uses the rendered viewport to guide the appearance of materials?
This sounds like an interesting idea. It would be handy since the output can be a little bit unpredictable, and with this feature I could generate 10 previews and choose the best one.
Actually it only happened once this morning. I tried it again and it worked now! Thanks a lot for the credits.
