@petermasek Maxwell just integrated part which was available for time inside Maxwell Studio - this is rather fur like thing. Though it have tons of params exposed you will never get real lawn with it - each ground cover system has its own characteristics and is made of several layers - simplest possible ground → dry grass → grass → weeds (usually clumped togeter). By the way are you aware who develops the rhino plugin I would like to contact directly lead dev as the “official” way of contacting almost always fails from my experience…
By the way are you aware who develops the rhino plugin I would like to contact directly lead dev as the “official” way of contacting almost always fails from my experience…
if i’m not totally wrong, @jdhill is the developer of the maxwell plugin for Rhino
Um… As far as I know @jdhill is now in Bella - btw. is it the time to move on with RN <-> Bella bridge ? 
1 Like
Thanks for the reminder, I’ll put it on my list to look into this after we finish our next release.
1 Like
I thought great features are always implemented before the release 
Just kidding 
Drop me a message when you’ll be good to go. Bridge API is straight forward and if you don’t want you even don’t need my dependencies to compile.
2 Likes
Late to the party here but wow this plugin looks like it is going to be fantastic - great work! used Forrest pack for 3ds before and great that there is going to be something similar for rhino.
You may have already answered this somewhere… and apologies if so… but is there going to be a built in library of trees, vegetation stones etc that comes with the plugin?
Yes. Actually this part ate a lot of time to bring in decent 100+ models mostly photo scanned, atlased and optimized. What’s more models are prepared with materials for Cycles,Octane,Thea and Vray out of box (including options for proxies). RN comes with thing called Library Browser (not shown yet here I guess) in which you can pick own or content creators presets and populate scene in 3 clicks.
One of trees:
Other assets like debris, grass, dandelions, clovers, birch - 90% of this scene is made out of RN models.
4 Likes
Any ideas about pricing yet?
awesome - cant wait
1 Like
As mentioned already. I know this topic is long but some Ctrl+F won’t hurt anybody.
Any posibility of zoo solution in the future?
You mean Zoo floating or cloud ?
I was initially thinking of floating… But an answer regarding both would fine as well 
What’s the point of writing such a post here?
It is obvious that grasshopper is a tool capable of solving many problems and no one is surprised.
RN is a tool that does everything you do with your grasshopper definition and much more, but efficiently and without having knowledge of coding or algorithms.
Umm, also don’t grasp the point… No one said it isn’t besides for a long time there is Skatter for GH by @Petras_Vestartas as well as RhinoGrow by @camnewnham all do the same job with less or more manual impact and in a smaller or bigger timeframe. Where RN is different, well you will be able to find out when it will be released… Due to V-Ray support, the Cosmos is only the tip of the iceberg actually.
1 Like
Alright, sorry, then I misread one of the posts above.
Anyways, I am looking forward to RN and the integration with V-Ray. Because one thing you notice is that performance really takes a hit when you hit very large numbers.
FWIW RN was my internal studio tool for a long time (not even called like that then) and it was actually prototyped in GH but … efficiency was faaar from expected, keeping many definitions for various elements was tedious and the final nail in the coffin which you listed in your post - baking blocks/geometry. A Rhino with 50/100k of blocks is a dead rhino. Not even mentioning fluid scene exploring or getting insane filesizes. As long as you have to place few items around no problem but when you have to do something big (below few examples where I personally used RN in production), vanilla Rhino + GH just dies and you can open task manager and just exit the process humming RIP.
5 Likes
Yeah, absolutely, GH just isn’t designed to handle insane amounts of any data. Anywhere above like 10.000 and things start to really get quite slow. Same in Rhino I guess, although I just tried and did an array with 100.000 (simple) cosmos assets and it’s still usable even with full mesh preview. But yeah, I get your point, 100.000 is still not a lot for Grass for example when you have large scenes.
So it will be interesting how you handle it in Rhino Nature. So it sounds like you have a deep integration with V-Ray where you leave all that handling to V-Ray, a bit like how V-Ray fur works!?
Hi @D-W , very happy to see rhino nature progressing. May I ask if it is possible to have a block trimming feature wherein they are exploded and then trimmed to accomodate a filler shape at the edges as in a roof? Railclone has this feature and it would be interesting if it were applied to RN. Also any news with native texture randomization? Last I checked you asked @andy about this. So far , I’ve seen no progress in that area.
Hi! Thanks!
This is interesting feature though it could bring huge RAM consumption overhead i have such thing on a list it was mentioned by one of my betatesters but iirc it was sth like “edge mode”?
Comparing RN to Railclone isn’t appropriate. Closer would be RN to FP. While Railclone is rather more what GH does?
Nope. At least in vanilla Rhino. V-Ray does that - at least I remember random color was tested - using its internal textures and looks cool. There’s still no Cycles integration - worth asking @nathanletwory if something changed?
1 Like