I am using rhino to depict a large scale landscape of a golf course.
I am wanting to put many different trees/shrubs/grasses. However, I don’t know if this can be done natively within rhino.
The species I’m putting in the rhino model are graphic PNG bitmap surfaces from photoshop like below
I’m guessing this is different than something like Vray or Unreal engine, in that the resolution is not distance dependent? I’m not sure if I understand.
Anyways, is there any way to manage these plants better natively within rhino?
place as many copies as you need of that specimen and select all those instances
run _ExtractRenderMesh
hide selected block instances (or delete if you don’t need them anymore)
select the meshes just extracted
run _Join, you have now one mesh object
a million flowers in a more or less usable way - yes, it makes selection a bit slower, but it is much faster this way than having them be a million separate objects, for instance Raytraced has no problem with this
Having a million separate block instances makes the file very slow and heavy. Selection takes ages for instance and viewport navigation is super sluggish.
That’s exactly what I did. I have created one block for each species, then arrayed them using grasshopper. The file size doesn’t increase much but it’s still really slow.
I believe that some different software packages might deal with it differently, like, they have low resolution versions for far away objects, and high res for closer ones. Perhaps rhino does not work like that?
UE can deal with forests etc, and perhaps Vray too? perhaps their assets work with something more dynamically efficient than PNG bitmaps in rhino?
Arraying will give you a lot of separate objects. This makes things very slow. A million separate objects is just a lot to go over.
That is why I propose to create single meshes per type for improved performance.
The way these objects are handled between UE and Rhino is different, completely different technologies are used in game engines to do all sorts of optimizations. Typically you don’t have to be able to select all separate objects while running a game, so lots can be done to gain performance.
I don’t know about V-Ray, I work on Raytraced and Rhino Render.
Anyway, there could still be room for optimizations, maybe something @jeff , @stevebaer or others could weigh in on.
Oh, it looks like interesting topic for me. Since this is now on table I’d like to ask if there is some extension provided to ChangeQueue in V8 to kick in stuff on it or it’s still only a native wrapper which pulls data into RhinoCommon. Would be a relief for me to see finaly a way to interact with instancing engine VIA simplest possibile aproach InsanceDefId and Transform[].
If I may to put also few words on it according to:
Handling milion objects may be slow but it may prevent you from hitting RAM memory limit on render action, as render engine won’t use instancing in that case. If you don’t care about hitting mem cap youre good to go.
I think @nathanletwory thought about joining meshes of each specie. You joined all elements, while you should join them per material basis, IIRC theres _SelSameMat or this was my internal script, though you can go to Material panel and right click to sel objects of the same mat and then join them per material.
Due to performance it should be slightly better however I wouldn’t expect huge improvement (simple planes can be much faster but more complex objects not really). Your issue exactly shows trouble due to which/why I developed RN, though without access to instancing internals it still cannot be utilized at its full power in render engines - only way is RN bridge which requires third party developers to implement it directly like Nikolay in VRay did for eg.
RN is my scattering plugin, best explanation is probably this one ATM.
Well, instancing is in shortest possible way to explain reusing existing in memory geometry kind of “parent one” creating its “children” / occurrences using simple transform matrices, this way you keep only one “proto object” in memory and render one million of them utilizing only small part of your “available horsepower” of device. Bit awkward and a very flattened explanation but yeah something like that. This tech is used under the hood in almost all engines around, in VRay called proxies, in UE called HISM, while in Rhino those are more or less blocks but handled a bit differently, so RN is a way to do it the lightweight way in Rhino, but RN still cannot expose its data to all engines due to suboptimal Rhino API constructions under hood in that matter. SO I just thought it would be a good occasion to renew the question if anything changed regarding V8.
Well, then I’ll lobby RN bridge still. CRM is not a way to go for me as I cannot evaluate engine render materials, though maybe something changed in that matter. Anyway, thanks for your input on that.
They simplify distant meshes. The same optimization can be done in Rhino manually by dividing very big mesh into two meshes (nearby and distant). Nearby mesh is simple. Distant mesh is complex. ReduceMesh command transforms complex distant mesh into simple distant mesh.
LOD is one of tricks, I was planning LODs for RN though, without access to instancing on my side cant do it, this would be super hard to covince third party devs to put more lines of code in their solutions than its absolutely necessery.
Yes, the same thing they do for RAM when rendering if picked engine support instancing.
The space saving is minimal here because I have only very simple geometry - a plane - in a block. Just the object data might be even larger than just the plane. Blocks start saving space properly when you use it on complex geometry.
But the point is the file should weight almost the same as the single plane. Blocks should be repetitions of the same line of code no?
I ask because it was my understanding that the implementation of blocks in Rhino is quite basic, which means it was actually not meant to save space but just have the convenience of updating instances.
