I’m aware of (although never really used them) render proxies / instances in other apps that allow vastly more complex scenes without the huge memory overhead of loading many duplicates of the same geometry.
Is there a way to make use of this kind of feature in rhino? I’m thinking specifically for landscaping / vegetation features where you might have 20 instances of the same tree model, or 10000(000) blades of grass.
I’m working on rhino for Mac, so maybe this is something that can be done with windows only plugins or something?
Use block instances to do that. For grass patches I’d use a mesh of a part, then make a _Block out of it that you can duplicate as many times as you like.
Raytraced and Rhino Render will be able to use the instancing part to not have to duplicate geometry in memory.
If you had a surface (perhaps with holes, perhaps irregular shape) do you have any tips about how best to distribute a clump of grass around such that the surface is well covered?
It would be great if there was a tool to fairly evenly spread across a surface. Perhaps this is something for grasshopper.
Also, from my experiments, Rhino still seems to be struggling with drawing all the geometry. I wonder if this is somewhere that proxies help? Could just have a distribution of points or simple objects that only show as the complex geometry at render time?
I don’t have tips at the moment, there are tools like Rhino Nature by @D-W and Lands Design that could be interesting.
I don’t know if Rhino Nature can bake its generated data as block instances somehow, but unfortunately at this moment there is not a good integration for Raytraced yet.
Maybe there are already other scripts/ghdefs/tools out there that can do this, the user community can chip in here.
@nathanletwory Thanks for marking me here! RN primary weapon is baking created ecosystems - it allows to support all engines though is not that sweet in usage as with bridge implemented where user on ecosystem property change can instantly have new setup rendered. Oh and obviously baking can create enormous filesize overhead. You know this data is available for you to pick - it’s just a matter of choice. I know I know you’re a purist on Render.ChangeQueue thing
Umm I don’t know why you think McNeel should do this I know no DCC app natively have an object scattering system. Ok. Blender has particles which are usable for this purposes though even those are far away from being suitable for intense production work - hair etc ok but not hundreds of thousands of objects adapting to the landscape you are designing. That being said … ah Mac … For the initial release no option for Mac later who knows not saying no but I’m not promising anything.
It’s just my opinion. So many people use rhino for architectural design and visualisation it would make a lot of sense to have something integrated or natively supported at least to help with site / landscaping works.
Appreciate you are heavily invested in what you’ve made, but really it’s these kinds of features that I think can and should be natively supported across windows and Mac. And really as a core part of the app.
@robinp just for your consciousness, so you will get better look on things
Those 2 bit different things render proxies are on side of rendering engine where proxy is simplified geometry of linekd file loaded only to render scene/graph on render time. Instances below.
Blocks in Rhino are exact equivalent of such feature.
This is doable without any problems in GH - ok maybe minimal scripting is needed but that’s super basic stuff. Need help just PM
We just can disagree on that everybody have own opinion. For me “sunken” in archiviz industry for many yrs its not CAD/DCC app responsibility to deal with this - I would prefer if McNeel team would find time to revamp whole UV section or (due to blocks) better management of those. This is where app should shine - though still we have to talk about Rhino as a whole and there are many more important places to visit that are crucial for AEC not saying even about ships, jewelry or CAM.
I wouldn’t go as far as to say it is anyone’s responsibility. I’m just saying what I would like as a customer and user of Rhino.
I would say that my responsibility as a user is to communicate what I want.
If each app provided exactly the same features it would be very annoying and boring. The point is that different apps have different strengths and weaknesses.
Rhino is especially well suited to architecture because it is precise and accurate. It is also very poor at handling scenes with lots of meshes, at least if you compare performance with say Maya etc.
But those mesh based apps are very poor for architectural design. Fine for the viz end of things if you can get a workflow for importing geometry successfully. But what I’m after is Rhino becoming a one stop shop.
Raytrace went a long way to making this possible because finally rhino has a half decent rendering engine built in and with v7 seems to be fast and good enough to use. I’d still welcome vray / octane being available. Options are good.
Having support for proxies in rhino render (raytrace) would be excellent. I’ve tried using blocks of grass and even at a density that is far too low to be acceptable the model becomes unusable.
Perhaps we just have to rely on plugins such as yours, and at $100 or whatever would be very good value. But the disconnect between it and rhino render is problematic, especially as alternative render systems are not available yet on the Mac as native plugins.
NURBS objects (doing “unoptimized” meshing underhood) I can agree though meshes I’m not so sure. Do you have any comparison data? I would agree also maybe for v5 but since v6 performance raised hugely - ofc talking about Win versions.
Well rhino have kinda proxy option which are linked blocks - I guess making full proxy option isn’t that far - basically to linked block there would have to be option to add low poly representation and that’s it more or less.
Due to unusability well I still work with baked blocks as my primary engine doesn’t support RN and actually even before writing RN i worked this way and it was sufficient even with highly detailed projects up to 1km square AFAIK guys from Flying Architecture were doing even much bigger projects (set of islands) using the same blocks in exact same way so I doubt its unusable but I can imagine your workflow isn’t optimized. Even Rhino 5 handled up to one million grass clump instances without bigger problems.
That’s on @nathanletwory side I can’t do much about it. If the team will decide to include RN data I’m ready to provide everything needed.
Well this is actually another topic and from my knowledge, not many will even try to port to the Mac platform and I guess they have their own reasons for that.
V7 model here (saved with textures so should be embedded): QUICK_GRASS.3dm (1.7 MB)
NOTE: This clump mesh is still highly unoptimized you can cut its poly count at least 50% or more and yes it takes a while for Cycles to cleanup and its less responsive in comparison to other commercial engines.
@nathanletwory after a while i see i made mistake trying to setup subsurface on open mesh and i was looking for original Transmission input from Principled BSDF but can’t find it anywhere - so question is handled differently or not implemented yet?
Thanks, looking at what you’ve got here, it is much less dense than the clump I’ve been experimenting with. Probably also much lower poly count.
Would be great to have a procedural fur / grass / hair material that could be applied to a surface so you don’t have to manually array and tidy up.
Re your point about renders changing depending on background colour. This is something I’ve struggled with for years. I agree that the background shouldn’t have any effect on the rendered output. It isn’t an environment, but it behaves a bit like one.
So you know where is the issue, above clump is rly unoptimized. For eg. RN library grass clumps are only ~25% (around 10k) of this one and built from individual sprouts. And looks like this:
@nathanletwory knows better what should or not should happen maybe there is another workflow for thin translucency in Cycles that I’m not aware of. Anyway, current behavior seems wrong for eg when you want to make cool paper bag render on a custom background but lit with another studio hdri.
Changing the background from 360° environment to solid color still chsnges the environment. Instead of an image you get essentially 360° black. This works as designed and expected. You see black through your non-opaque leaves.
Set IOR to 1.0, ai think you’ll get better results.
To be honest, I’ve found the lighting of scenes generally varies depending on the background settings. I don’t think this should be the case but it has been for years, even pre-cycles.
