algorithmic modeling for Rhino
Well friends,
A fellow GH user (Nicknamed ... hmm ...User) initiated some puzzles about vector "centroids" (add unitized vectors in plain English) - he calls them "Umbrella sticks".
Read this first:
http://www.grasshopper3d.com/forum/topics/cross-product-of-multiple...
I've got involved since I'm doing "similar" things for tensile membranes, weird/complex trusses and the likes. So this C# code is in fact a "cut and paste" thing from a variety of other cases under development right now.
So, I'm starting a "parallel" similar thread ... because a lot of updates (faster code, more bugs, more divisions by zero == progress) are under way.
PS: test data are internalized (but better safe than sorry: use Rhino file as Plan B).
PS: for User: Display Surface Normals and compare VS "centroids" (sum of triangle unitized Normals).
best, Peter
Tags:
Peter, it sounds great, but I'm still confused for the initial shape... What happen if you start from single panels and not an entire surface? I don't want a regular tessellation, because I've already my panels and they are not regular...
see attached examples
Nothing is impossible ... but let's pin (theoretically) the whole Umbrella thing first:
1. IS THIS OK? (used your test sample posted in the other thread of yours). That said a trimmed surface IS NOT a surface (since that thing doesn't hold trim info, only a Brep can do that) . All data are internalized (but get the Rhino file as Plan B).
2. It's obvious that the cross product for a given pair of vectors (defined as directions of a given pair of triangle edges - pair means that they share a common point) equals the plane normal (defined by the triad of Brep points). In this second C# script I took the short way home (as opposed the method used in the first). Plane normals are used in the main script posted here as well (spot the sampling for computing the sum per U/V "node" and per pattern "mode").
3. It's also obvious that the US (Not the land of free ... the Umbrella Stick, he he) is the sum of the unitized Normals (in the "same sense" that a bisector is the sum of 2 unitized vectors).
PS: In your test data the Breps where "triple" (3 instead of one - per Brep).
PS: I used the evil number 666 as index for the Common point in the sData tree (that number makes all the difference, he he).
best, Peter
Well...
... as regards the xxx10_001.gh thingy:
1. The C# is designed in order to subdivide a surface List in a U/V indexed way (data tree in plain English) AND NOT in a single dimension List (Lunchbox way). Why may you ask? Well ... in order to control what "module" (triangle) is where my dear Watson, that's why.
2. Your data set is wrong in the sense that you provide a single dimension list of already "ready" Breps (triangles) and then instruct the C# ... er ... to subdivide each triangle (that's like dating 123,45 girls at once: not recommended unless you are some Sheik of some sort).
3. There's several solutions to that problem:
3a: The right way is to subdivide a surface AND THEN individually modify any desired module BEFORE the C# continues post processing the modules. Any why this is a bit complex? (although achievable) Well .. the explanation is ... er ... complex, he he (GH is not designed for doing this: GH operates in a fire and forget mode, so to speak, as regards collections of things).
3b: The other way is to mastermind some (rather inefficient) way to influence modules BEFORE the C# continues ... blah blah. In plain English: using the so called attractors and the likes (I dislike that: I'm an engineer and that's not engineering by any means, but is OK for artists).
3c: The other way is to create a Plan B in the C# : don't subdivide > just get these things (as Lists/DataTrees of Breps) and compute things/whatever/US (not the land of free). But ... we need to supply the modules in an U/V indexed way (obviously we can do that automatically with "some" lines of code more - but is a very stupid way to address the issue).
PS: a DataTree IS NOT a List of List of List of ... it's an indexed collection of single dimension Lists.
best, Peter
BTW: is Fate: the one way or the other we arrive in the "how to individually modify things in collections" puzzle. Get this very old (and totally incomplete as regards volatile data management) test case:
Here's a grid of points sampled into a user defined tree structure (kinda the "donor" grid in creating some triangles of yours - according some x mode, like the 3 modes in the initial script).
Goal is to individually (and interactively) modify things (Points) in a given collection. Easy you think? No so ... he he.
Since this archaic/prehistoric/primitive C#, a lot of changes are made: I'll post soon a collection of "ways" in order to do properly the holly grail of engineering (but why people in this Noble Forum are not asking that kind of stuff? it's a mystery to me).
PS: Get another one (metaphorically the "same" sort of issue) as well: change a list and record the changes "interactively".
PS: Can you see why these are tightly related with what you are asking for?
I'm travelling, but I will check everything ASAP!
Er. .. ( > the xxx10_001.gh thing): although I have code to put these triangles of yours in a proper U/V order (and instruct C# to bypass the subdivision phase) ... boy ... this is beyond belief: a well ordered collection (or at least looking like that) is turned into a programming nightmare.
I've just added a safety net:
if(chaos) {Print("I refuse to work with you, Adios Amigos");return;}
for such ... er ... situations, he he.
Hi,
searching panels(f) from given vertices(v) and edges(e) means at first to order the v's, e's & f's. This can help to find the normals for the faces. When you have the normals you can turn them as you need (inside or outside). With the orientated face normals you can calculate/draw the vectors for your edges or the vector for the vertices. I need such things almost every day, so i decided to make my own C# application (stand alone). I think if you need this kind of app just this time, its better to try this with GH with C# components otherwise make it right.
One other solution that i used is to mark the edges and the common vertex. Doing this you can find all edges at your vertex and you will be able to calculate the right vectors for the edge-axis. By adding this edge vectors you can produce a kind of well orientated vertex vector.
Okay guys, it's reeeally hard to follow your discussion and especially peter's definitions are hard to read for me. so pleas forgive me if I am getting this thing wrong.
First of all: is the original surface a mesh? If so, please use the mesh as it provides tons of information like face normals and topology. There are ways to convert your face outlines to a mesh. My take uses one component MeshEdit tools in order to adjust the face normals.
Anyways, once you have mesh info, there are two basic approaches to extract a normal vector at the vertices.
a) average the adjacent edge vertices
b) average the adjacent face vertices
In general, you avoid edge average is bad for nearly planar parts or parts with opposing curvature. Both averages depend on size and the distribution of the faces/edges around the vertex.
My approach is based on research by Alexander Stahr, who proposes to adjust the vertex normal so the standard deviation of the angle between the normal and each edge. One possible solution is to just fit a pane through all the "intersections with the sphere". That will minimize the distances and thus the angle deviation.
Well... the original surface IS NOT A MESH (there's several benefits of this, not to mention the divide modes). If it was I would never get involved (I don't like meshes for engineering purposes).
Other than that, given the opportunity, here's a way to "sort" the panel chaos (the one that our friend User attempted to use as input to the C# on his reply: January 10, 2015 ).
This DataTree it could provide input into a (modified: no divide, just process Breps ) C# in order to calculate the required vectors. But this "by-pass" could yield the lost of the division modes - that make all the difference.
PS: by carefully choosing the order of the division point triad(s) (see inside the main C# script) you can quite effectively handle any potential issues related with vector orientation (anyway if these vector "sticks" are used in order to define some kind of structural members, they should point towards the "same" direction).
Hey Peter,
I'm back! Sorry for the delay, but I was travelling. Honestly I got totally lost following your def
:D
Welcome to
Grasshopper
© 2024 Created by Scott Davidson. Powered by