Grasshopper

algorithmic modeling for Rhino

Hi all, 

       I am a python user(beginner) trying to understand meshes and meshing algorithms like Marching cubes, Ball Pivot and Marching tetrahedra. I saw basic example provided with rhinoscriptsyntax, It was hard to imagine how hard it was to make mesh faces assigned from points. One way i could think of not Reinventing the wheel was to call mesh from points commands in python . I needs some direction to head towards creating meshes in rhino

      I was suggested Libraries but i not smart enough to figure out how to or where to use them exactly. 

Views: 8027

Replies to This Discussion

Update: Now the mesh is joined into one within Python, and I also added a toggle for both resolution and also quite (8X) slower normals calculation that gives a nice preview instead of a checkerboard:

# GRASSHOPPER PYTHON OUTPUT

MESH = Rhino.Geometry.Mesh()
for m in MESH_FACES_CONTAINER:
  MESH.Append(m)
  if SLOWLY_FIX_NORMALS == True:
    MESH.Normals.ComputeNormals() # Gives nice mesh preview but makes the script take 8X longer.

Attachments:

woah...!!! so did u make points sortable ?? i.e in order of 3 so that mesh faces can be created ..and does this work on random point cloud ??? 

Sorry, no, the STL file format created by the original Python script follows how marching tetrahedra itself works, to specify each face via three vertices, one full single face at a time, and Rhino is happy to append each one to an originally empty mesh container, automatically removing redundant vertices as it goes, so it will not work on a point cloud that lacks such connectivity info built into the process. I think the whole point of marching cubes or tetrahedra is to order the surface rationally, to indeed give a coherent almost regular mesh connectivity.
Oh wait, here I confused myself. since I was working on reading fixed STL files too into Grasshopper, in another thread, but in this marching tetrahedra script I'm generating my own STL is all, from a mathematical equation that indeed may just spit out points. So my answer is that I don't know how it will handle arbitrary point clouds yet. I'll have to take another look when I have time. The mesh generation routine does not necessarily limit it the way I thought, anyway. The "point cloud" I referred to is quite separate from any point cloud or equation that defines the original form, and I shouldn't even call the mesh generation vertices noted think of them as a point cloud since they come in as defined faces from the marching routine.

Hey it may work on a point cloud since the math routine I posted above merely generates points to represent the trigonometric equation. But I wonder what it might do if the cloud doesn't actually form a surface well or is really a volumetric array?

Looking again, despite the somewhat odd coding format used by the original coder (defining a throwaway function using the obscure Python lambda command, inside the def line of another function, then later calling an allied function using no arguments in a way I'm not yet familiar with), no, there is no internal point cloud being generated to sample the mathematical function, only a cubical box array of space sampling points, which also looks like much more work is being done than needed for a slightly offset bounding box, so fixing that may make it much faster:

Marching cubes is supposed to handle surfacing a point cloud, but here I don't know yet how to define that as the necessary implicit equation of f(x,y,z) = 0.

The line needed to output these points is this put in where i,j,k are being used in a loop:

POINTS.append( Rhino.Geometry.Point3d (i,j,k) )

I have a point clouds surfacer working here, though it offsets outwards a bit too:

http://www.grasshopper3d.com/forum/topics/bulge-free-metaballs-and-...

It's faster now that I stopped being dumb about first collecting faces then separately feeding them into a final mesh object, so now I just build the mesh. I removed the optional normal fixing, so it just does that now.

Attachments:

Keyshot renderer fun:

Some info on general point cloud "skinning" geometry theory, which actually uses a Python script for a Blender software plugin:

http://hanspg.web.fc2.com/Pages/csv_scripts/algo_t15.html

Yet here is a video that indicates that triangulating a point cloud as vertices is silly, but there's a way to do it uniformly, independent of the local density of points:

Publication:

http://www.sci.utah.edu/~shachar/Publications/MLSMesh.pdf

We have to realize that our subconscious brains are *very* powerful, almost down to having quantum computer advantage based on molecules forming billion year trained neural networks being taken full advantage of that makes some of this stuff seem so "easy" but our conscious mathematical ability is quite limited in comparison, especially having to use linear code. It seems graphics card won't even do this. They rely on low poly models plus surface mapping of details based on 2D images.

More background of surfacing point clouds, including an IBM patent:

http://doc.cgal.org/latest/Surface_reconstruction_points_3/

http://stackoverflow.com/questions/838761/robust-algorithm-for-surf...

More Keyshot renderer fun, with refraction too, instead of just reflection:

The IBM "Ball Pivoting" point cloud surfacing algorithm, which sound more smart than "marching cubes":

https://www.google.com/patents/US6968299?dq=6,968,299&hl=en&...

Alas, "...not suitable for pointclouds with varying point density."

And a 132 page Ph.D. thesis (mine was 500 pages but lots of NMR spectra were included) called "Surface reconstruction from unorganized points":

http://research.microsoft.com/en-us/um/people/hoppe/proj/thesis/

But screw it: "One perceived weakness of this work is that it requires oriented normals at the input points."

That's not perceived weakness; it's death.

Great info here . Thanks Nik .

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service