While using Rhino.Inside.Revit, is there a way to fully close Rhino and release the cloud zoo license?
The use case is: someone is working primarily in Revit and opens up Rhino.Inside.Revit to use Rhino/Grasshopper, which uses a cloud zoo license, after they are done and close Rhino/GH, the Rhino 7 license is still in use until that person closes Revit. I don’t’ currently see a way to exit or quit RIR.
This becomes problematic for us since we share many licenses across the company and want to keep as many available for others while not in use.
Rhino release the license when is unloaded, but since Rhino.Inside Revit is an Addin for Revit and there is no nice way to unload an Addin, once is loaded, we can not release the license until the whole Revit closes.
So, unfortunately, in this case the only way to release the license is closing Revit completly.
Rhino.inside.Revit is turning out to be fantastic for us, but managing licenses as we scale is becoming a big concern.
To elaborate on the scenario that concerns us…
Project team uses Rhino.inside.Revit
They finish with any efforts requiring Rhino, but keep working in Revit.
Those licenses are not available for staff wanting to use Rhino (standalone or in Revit) until they close Revit.
Given it can take some time to get up and running in Revit, especially with larger collections of models, staff often leave Revit running for the entire day. This is especially true with work-from-home.
In this case this also means they have grabbed a Rhino license for the entire day, despite not using it any more.
And, worst-case-scenario, they leave for the day and leave Revit running. That doesn’t happen all the time, but we have had actual instances of that in the past week (including one right now) preventing a team member from getting into Rhino.
We ran into this with only 5 Rhino 7 licenses running with a pilot project using Rhino.inside.Revit. I am concerned once we roll this out globally to our 15 studios with our 150 licenses. This problem will scale significantly.
Proposals in order of preference:
Auto-kill the Rhino license when you see Rhino.inside features are no longer in use (or after 5 minutes of that)
A button to actively release the license (less likely to be used, but helpful)
A prompt to remind staff they still have an active Rhino 7 license and should close Revit to release it.
I’m glad to hear your pilot went well, and that you’re interested in making Rhino.Inside Revit available to more people on your teams.
We want to find some kind of reasonable balance here. I’m not sure what that looks like. For a very long time, we’ve priced Rhino for very occasional use. And we introduced floating licenses that make it easy to share those licenses in a team.
If Rhino is valuable enough in your workflows to have a license for each person that uses it each day, whether inside Revit, or not, then our preference would be that you buy enough licenses to meet the needs of your company.
Technically, it’s a ton of work for us to make it so that Rhino stops using a license when it’s not in use - especially when it’s running inside Revit. It’s even pretty hard for us to say “you haven’t called into Rhino for 10 minutes - we think you should close Revit.”
We don’t want to rip anybody off. We also don’t want to give too much away. Thus the seeking of a reasonable balance. We’re hoping RiR sells some more licenses into companies that need to augment their Revit workflows.
I am 100% supportive of buying enough licenses for each person that uses it (provided it remains in a floating license manner provided by Zoo). We actively promote and support Rhino in the organization, and I am always happy to increase our licenses since that increase means more staff have access to a amazing design application to deliver their work.
The key thing is paying for / buying licenses that represents actual use of the tool. The best approach to this is a consumption-based approach (I am not suggesting you do that!), followed next by floating licenses. I am definitively not a fan of named users licensing, at least for a large company. Zoo works great for us.
My concern is that the current license model with Rhino.inside.Revit does not represent actual use of Rhino licenses because the release of a license does not happen once they stop using the Rhino.inside.Revit functionality. It only happens when you close the “host” application, Revit.
A parallel example with rendering engines: V-Ray releasing the license when not using the V-Ray interface or rendering.
My concern is not about increasing licenses based on an increase in actual use, but instead on the cost of increasing licenses based on the peculiarities of how licenses are managed.
I’ll note that even if Rhino.inside released its licenses when you stopped using the features, we are absolutely going to need to increase Rhino licenses because the interoperability opportunities are huge for us. I’ll happily pay for that.
All that being said, the paradigm of Rhino.inside is different. With Rhino.inside we have access to an entirely different modeling and visual scripting environment INSIDE a different application (it still blows my mind). I am not sure what is the right licensing paradigm to parallel this.
Thank you for all the details. What you’re saying makes sense to me. It’s also really quite difficult for a number of reasons, not the least of which is that we can’t unload Rhino from the Revit process. (It might be possible for some Revit add-ons to do this, but because of the depth of integration between Revit and Rhino.Inside, it’s not possible for us to do). If that were possible, we could recommend that you just have users unload Rhino.Inside when they’re done with it.
Secondarily, being able to dynamically consume and release licenses from within Rhino, and also protect the core computational code in Rhino from being called, and also not crash Revit proves quite complex. (Remember, with RiR, you can write a python script in Dynamo that accesses every function in core Rhino. We would have to touch every single one of those functions and figure out what the “right thing” to do is when there’s no license. Doing just the wrong thing (like raising an exception) is likely to crash Revit if the script writer isn’t very careful.) So, in the likely event that the license was released, and the user subsequently tries to do something with RiR but can’t get a license, they’d probably crash Revit.
Even your third option to tell the user to quit Revit requires the same level of updating every function in Rhino to know whether it has been called in (x) amount of time. Barring that, the reminder might be annoyingly wrong, reminding users to close Revit when, in fact, they were just using an RiR feature. This kind of reminder becomes a frequent irritant that is patently ignored by users.
That’s a long-winded way of saying that I don’t think that we’re going to be able to actually fulfill your request.
I’d like to bump this topic.
We have encountered similar problem with Rhino inside Tekla.
With current solution as is.
Currently we are developing solutions where Rhino/GH is launched independently, we have scripts, that automatize workflow for the whole model. 15 licenses are enough to cover ~20-30 engineers, that need to use these scripts once a month for 10minutes.
Rhino inside Tekla opens large possibilities to develop things in a new way.
Instead of 15-30 “once a month” users, we could develop things for all detailers - possibly 100-150 users.
But still, most use cases for these users possibly will be ~10minutes a day for specific things.
Restarting Tekla is not an option. (For very large detailed models, it can take 30-40minutes to open).
With current approach, we would have to evaluate before developing a new workflow tool - how many users will use it per project. If it’s single user. It could possibly be developed for the project’s “dedicated” Rhino inside Tekla user.
If it’s more than 1 person, it would most likely be better then to develop the workflow with more time consuming C# api plugin/application approach.
The technical capabilities of Grasshopper for engineers are amazing. However current approach makes it hard to switch to even better abilities with Rhino inside Tekla.
I understand business reasons. We have steadily acquired additional licenses basically only for Grasshopper functionality - to develop automated workflows, occasionally use them once/few times per project.
But with current approach, developing and using a little 10-20mins rhino inside Tekla each day for each user would require too steep mountain in license increases.
I hope, there will be some changes in future.
P.S. Would like to mention again, that Grasshopper is such an amazing tool, I’m not saying it enough. Good job guys!
If we project out say 3 years of costs and productivity, in relation to Rhino’s permanent license (even with an upgrade) and the other software’s (Revit, Tekla, Catia) yearly subscription fee’s it’s looking like an exceptional value. The 10-20 minutes of Rhino use per user would certainly become more efficient as tools are refined and users are more aware of the potential.
In our case, we have an alternative of developing c# api plugins to save time over years e.t.c.
Regarding functionality, C# plugins/apps have no limitations, but take longer time to develop.
Teklas custom components (similar to revit families) have limitations, but they are very quick to develop.
Rhino inside Tekla is somewhere in the middle regarding both development speed and limitations, however there is a problem with licenses.
(And there is still the old way, of simply only using large scale GH scripts to modify the model using live links, and not bother with small local detailing with Rhino inside Tekla).
So it’s not as clear cut as that regarding the benefits.
These are tough decisions, especially with the history of BIM Software development and the costs companies have incurred with overall productivity in the industry barely registering gains. The longer timeframe view seemingly favors hiring a couple dedicated developers if the firm is big enough.
– a bit of background on my perspective.
I worked for a firm that invested millions in Catia, with the result being less than ideal and barely used. The monies spent on the licenses, training and consultants could have staffed and equipped a substantial rhino workforce that would be multitudes more productive – sunk cost fallacy was in effect.
This may be challenging but other add-in applications have solved this problem. This is a real issue. If supporting floating license is McNeels objective then the floating license which personally I think it should be then the licenses should behave as a floating license. If this is a true roadblock then a different licensing model should be provided for the RiR application