Reference Brep render meshes?

Grasshopper
1

I’m trying to find a way to speed up volume and centroid calculations on large sets of referenced Breps.
The calculations seem to be faster on meshes, but if I could retrieve Rhino’s render meshes instead of re-meshing the Breps in Grasshopper, that would be a plus since the generation of those meshes is also quite time consuming.

So is there a way to reference those render meshes ?

2

Run ExtractRenderMesh command in rhino.

3

Hi person with a cute avatar,

I know about ExtractRenderMesh.
I don’t want to instantiate these meshes in Rhino ; just reference them in Grasshopper to perform faster volume calculations.

Moreover, if I do as you suggest, how can I link each mesh to it’s original Brep ?

4

Hi guy with “un je ne sais quoi” avatar.
You can use that and you’ll have to join the mesh in order to compute the volume. It seems to work.
Make a small C# script.

private void RunScript(Guid guid, ref object A)
  {

    var rhobj = doc.Objects.Find(guid);


    if (rhobj is Rhino.DocObjects.RhinoObject )
      A = rhobj.GetMeshes(MeshType.Render);


  }
5

Ah ben mince alors ! Elle est passée où ma photo qui date d’il y a 20 ans et que j’utilise aussi pour draguer sur Meetic ?
Le “Je ne sais quoi”, c’est mon profil Google, photo prise sur un char à cerf-volant…

6

Olivier
here the complete script.
volume for object with guid.gh (45.9 KB)

 private void RunScript(Guid guid, ref object volume)
  {
    var rhobj = doc.Objects.Find(guid);
    
    if (rhobj is Rhino.DocObjects.RhinoObject )
    {
      Mesh mesh = new Mesh();
      mesh.Append(rhobj.GetMeshes(MeshType.Render));
      if (mesh.IsClosed)
      {
        volume = mesh.Volume();
      }
      else
      {
        volume = 0.0;
      }
    }
  }
2 Likes
7

To gain more speed in the execution, wouldn’t it make sense to create a compiled GH component based on this code ?

8

I could make a multi-threaded code to see if it go more fast but I will not do a compiled component. it is a bit more work and need some experience to cure if there are failure.

9

Anyhow, I realized that the bottleneck in my definition was the “Split tree” component…
Not sure how I can get out of that one except learning how to develop a C# plugin for Rhino.

11

It is much faster than the “Volume” component indeed !
Much faster indeed

Nom, I’m trying to do the same for the calculation of area, but I can’t seem to find the proper mesh method for this.
There seems to be a complete encyclopedia of exotic mesh methods, but no vanilla “Area” method…

12

You can use that
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_AreaMassProperties_Compute_6.htm
use it like that

AreaMassProperties amp= AreaMassProperties.Compute(mesh);

area = amp.Area;

13

Thanks !

But don’t you find it odd that there are such methods as “Mesh.ExtendSelectionByEdgeRidge” or “Mesh.GetNgonAndFacesEnumerable” and not a silly old “Area” method ?

14

…except it’s completely unreliable :frowning:

Render mesh volumes meh
Render mesh volumes meh895×579 99.1 KB

I’m actually referencing objects in block DEFINITIONS.
I don’t know if Rhino uses “instances” of the render mesh of the block definition for the render meshes of the block instances (that would make sense).
Many of the solids for which the C# component gives a “0” volume have in fact valid, closed render meshes, so I don’t know what’s going on here.

I guess I’ll stick with the slow Nurbs volume calculations.