When the final version will be release?
Hi, theres still no clear ETA. Things are still under development on both sides RN and Rhino to provide best possible way of handling vast amounts of geometry for rendering without affecting Rhino stability. You can track smaller updates on FB page - https://facebook.com/rhinonature
3 Likes
@D-W any more news you can share? What kind of trees and plants do you plan to include?
also Rhino 6 for Mac has launched now officially, do you think you could make it happen to port it?
@Gijs there will be a very basic library of assets but those are carefully built or photo scanned. I can’t say now how big/small the internal library will be. Besides, there are tons of paid libraries out there which will work with RN without any issues, as RN isn’t bound to its library only. You can put there whatever you want toss bolts, grow a lawn or build entire city it’s totally up to you.
@encephalon for sure not for the first release we still work under win to fully support nondestructive workflow with @andy i don’t have an idea if this was even considered for mac at this stage.
Due to the news … I try to provide a really robust full-fledged solution so still refining internal algos for eg. currently refining very fluid and organic procedural clustering of objects:
10 Likes
any news? I would be the first to buy!
best
Andy
Hi @walther !
What news would you expect to see/read? Besides you can always track RN on FB. If you expect ETA can’t tell for sure but i can disclose that next milestone is a release candidate 
3 Likes
Hello everybody,
I write this post since many of you ask in person how things are going. Well … I think you have the right to know since many of you are awaiting RN for longer period of time. First of all, I don’t want to blame anyone I’m just telling how things look. Unfortunately, lately, I was informed that Andy discarded implementations in SDK that have been agreed on both sides (almost year ago - post #25) to allow smooth support for any possible render engine. So as you can imagine this complicates few things and will need separate implementation and support by each renderer to work as expected in a non-destructive workflow, however as I mentioned RN is very near the RC stage and I do what I can to provide expected things for the render engines developers ASAP.
Edited to keep smile on your faces, this is what currently you can do with RN in less than 1 minute without any struggle.
15 Likes
Ja pierdziu…
Hi Przemyslaw, impressive results!
why? was there any technical reason or just low priority to these changes?
Good luck with finishing the plugin, it gets harder the closer to finish you are 
–jarek
Hi Jarek,
Thanks for appreciation 
From my understanding, this was @andy personal initiative to get things working internally not McNeel intention to improve it. Can’t blame Andy goodwill as he had to do it additionally so when schedules became tight he isn’t able to deliver it. The downside of this will be that for eg. decent Cycles won’t work with RN without baking - and as you can imagine baking these amounts of geometry to document will put Rhino in at least Not Responding if not in RIP state, although there is already a looot of trickery done to keep it alive.
2 Likes
this look so extremely cool !!! I am dying to try this myself… just to make sure I get it right : this will work with the octane render engine right ?
good luck !
Andreas
It looks really great , can’t wait to test it.
Hi Andreas,
Yesterday after core optimizing i broke the limit and i had more than one milion generated clustered and randomized objects in v5 with fluid viewport on laptop 
Currently any renderer will render population if it will be baked - this unfortunatelly involves keeping real geo inside doc so it will break any instance of Rhino at some point depending on system. If McNeel wolud help and implement fairly simple thing in SDK any renderer would work without baking otherwise each render engine developer will have to implement custom data exchange protocol to own plugin to support nondestructive rendering. I hope this clarifies your concerns - it will depend on will, policies of companies due to supporting 3rd party libraries.
3 Likes
Yesterday after core optimizing i broke the limit and i had more than one milion generated clustered and randomized objects in v5 with fluid viewport on laptop
Do you mean this plugin is also working in rhino 5 ??
greetings Peter
Yeah, it is.
Yup. As @foreigner said it works with v5, v6 and wip currently.
1 Like
Sounds as the change to the SDK would well deserve it!
Is there anything we could possible do to help? Write to McNeal? Support your effort with $? I really have a hard time hearing that McNeal is not too supportive from what I understand… that is a shame really…
Andreas
Andreas thanks for your interest. RN will happen no matter what however it is obvious that satisfying the needs of developers and companies policies due to integrating something from the outside is hard to do since everyone has a different idea for such communication protocol. I think most of McNeel devs are aware whats cookin’ here and i can’t say that they weren’t supportive when i had API questions. I just let know everybody interested in RN that there is still crucial work to do ahead and unfortunately can take more time than expected. Should we write officially? I don’t think so. I guess if there would be a place in their schedule sb would try to solve this. However, let’s try…
Sorry for poking @pascal, @dale, @stevebaer is there any chance to get a place in API to straight forward share data between plugins within any late v6 sr? I mean not keeping it attached to any rh/geometry object. There is document StringTable since v5 but iirc there wasn’t equivalent of it in C++ SDK and hadn’t raised any event on change. Forgot to mention it should be availible only during runtime / not saved since it would be waste of storage.
4 Likes