here but maybe it helps you... So you have an array of arrays of ordered vertex indices. How about recursively traversing the original face-vertex data structure using the edges (i.e. pairs of vertex indices) to find adjacent faces. Starting with any face, mark it as done and take each pair of vertex indices in turn and search for this consecutive pair across the rest of the ragged array to find the adjacent face, if one exists. For each pair, search initially for the pair in reverse order (i.e. given indices 5 and 8, search for 8 and 5). If you find a face on the first pass, mark it as done and move onto the next consecutive index-pair of the original face. If not, you should search for the index-pair in order and if you find the associated face (making sure it's not the one you're search from!) you need to to flip it (i.e. reverse the order of its vertex indices) and mark it as done. The trick, I think, is in writing this as a self-contained function so that it can be called recursively – each time you mark a face as done you should call the function on that face, searching for adjacent faces and flipping them where necessary.
This won't be super fast because you're layering O(n) searches on top of one another, but I think it'll get the job done. I'm assuming no degenerate faces and no disjoint meshes, although the latter can be dealt with easily (kind of, but that's another matter!).…
e second example.
The first screenshot has an item that is coming from the List of strings that CANNOT be cast into numbers. The second screenshot has an item that comes from a List of strings with the same structure as the first example, except these numbers can all be cast into numbers without any errors...
Is it possible that there is an EOL or '\n' character lurking somewhere in the background? And if so...why don't Panels display these characters? Is there some better component available within GH that can display more information about text files? GH in the past hasn't displayed '\t' characters either. Perhaps this type of functionality is already available and I am unaware of it? Or maybe it is a setting within the already existing panel components (e.g. right-click --> display hidden character information)? Or...maybe it is something that should be added to GH 2. Just musing aloud. Either way, any comments are welcomed!…
and 201 in Y. So 40401 points.
A species concentration is set to 1 on all the grid
B species concentration represent the feet of the gueridon. Black mean 0 and white mean 1.
A diffusion is set to 1.
B diffusion is set to 0.4 multiplied by the value of brightness (here 0.65 to 1) so B diffusion from 0.26 to 0.4. A lower value of B diffusion mean smaller size of pattern
Feed values are set to 0 (no B species in theses places) to 0.056.
Kill value is constant 0.0649.
N steps of jumps is the number of slices (minus 2) of the 3d model so here there are 201x201x202 = 8160002 provided to isosurface. Each slice is separated by jump*dt (18 here).
The script provided generate in less than 2 minutes the gueridon, with a mesh of 1,200,000 faces.
The mesh must be flipped in rhino. I also use CageEdit to deform the mesh for my rendering.
…
thus is the more "safe" approach. For instance Imagine branches with unequal N of items etc etc.
Plan B: Is the way that PM works ... but obviously {A;B} > {B\something} assumes that branches are equally populated: a recipe for Armageddon in other cases.
Plan C: Is equally "shallow" since getting a List out of a Tree and then doing the Skip/Take thingy assumes that ... see Plan B . Of course using FromList.ToList().GetRange(startIndex, nOfItems);
is the same kind of rabbit hole.
Native: See Plan C.
PS: Something/OtherSomething IS NOT the same animal with Something\OtherSomething not to mention that {A;B\Something} gives 2 dimensional (wrong) results.
PS: Some of your Lofted stuff is "weird"/twisted (check this, this and that he he).
PS: Notify if you want a pack of 66.66 "easy" C# examples about how to get a tree and make chaos or order or whatever comes first.
Moral: cold of warm Guinness? that's the 1M question.
best, The Lord of Darkness…
Added by peter fotiadis at 12:16am on September 27, 2015
th regard your specific case: (a) Create the suitable "grid" (the C# grid requires a few lines more to do what you want) (b) Create suitable parametric profiles (at WorldXY) and define "on-the-fly" an instance definition (nested or "flat") containing the extruded "solids" (c) place the instances using classic plane to plane transformation (kinda like the Orient component). Steps b,c require code ... but is 10000 times faster VS orienting a "seed" solid (or more) in N planes - meaning actually "copy,transform and paste" (and that's especially true when the "solids" are complex).
I could rather easily provide a demo on all these ... but using solely code and that MAY not be an ideal solution for you.…
s)
•Half of daytime (as it is symmetrical towards N-S axis)
•1 sun vector per hour (6 in total)
•On September 21st/ March 21st (as it is the average of the summer and winter solstice and it occurs twice a year)
•Average vector of panel’s normal vectors is oriented in between two adjacent sun vectors (e.g. average normal vector between 7am-8am)
There's a screenshot and the .gh file below. The file takes quite a long time to load though and you will have to zoom out quite a bit as well.
What can the fly do that could make it easier? I'm not familiar with it.
How would you have approached it with native GH components?
…
ee. That said these things (masterminded by a certain David R) are not bad at all ... but if you write code that is "supposedly" transferable (kinda) to other CAD apps ... well ... I would strongly recommend the other classic nested C# collections.
2. The HLP method is one out of many: for instance for a better approximation of the required fitted plane we can use the divide Curve method etc etc.
3. GH components use (in most of cases) methods exposed in Rhino SDK > get the thingy and start digging into the rabbit hole. Of course David did some other components as well that use "less" classic SDK methods (if at all).
4. HLP is a classic approach to count the beans in nurbs curves. Of course I could use PolyCurves and recursive explosion blah, blah ... but here we are not after segments (at least at present time). On the other hand if that was a Faceted Dome (planar Polylines) ... well getting the nodes that way it could be an overkill (this means business for V2).
5. Mastermind some plane orientation policies in order to finish(?) the @$%@$ thing. For instance: Given Plane plane, define a Plane.WorldXY at plane.Origin and section these 2 > then get the cross product (sectionVector, plane.ZAxis) for the new orientedPlane Y axis etc etc (this presupposes that any plane Z axis points "outwards": use Dot Product and a center point as apex etc etc).…
f the polygon's segments (effectively the Alt Hsu Snoeyink paper "Computing the largest inscribed isothetic rectangle"), although I don't assume its as fast as their O(log n) algorithm.
The problem is constructed as a nonlinear optimization with linear constraints, using a nonlinear (in this case Interior Point method) solver: define the variables as (x,y) origin of the rectangle, the objective as its width*height, and then the constraints are the polygon segments' Cartesian line inequations.
Thankfully the C# FuncLib library (https://funclib.codeplex.com/) provides nice representation of objectives & constraints to the IPOPT library (https://projects.coin-or.org/Ipopt) by handling all the matrix operations & determinants etc. The compiled binaries from the codeplex site are x86 only, but you can compile them to x64 using the '3.9.2' binaries at http://www.coin-or.org/download/binary/Ipopt/
I've attached the GH + C# script and x64 FuncLib DLLs. Make sure to unblock & reference the assemblies etc
Hope this helps!
…
liarize yourself with [Trim Tree] instead of using [Split Tree], and [Flip Matrix] instead of [Path Mapper]. Also Simplify gets rid of superfluous 0's which can trip up some of these components.And I don't think you understand how [List Item] works here (they currently do nothing)Quick primer:It's helpful to think of Data Trees as a list of lists (simplifying things here)[List Item] only interacts with the smallest list, of which there is only {n=1} items in your example so nothing happens.[Trim Tree] eradicates the smallest tree and groups stuff up so you can handle them more easily[Flip Matrix] switches say 3 groups of 5 items in to 5 groups of 3 items, but can't handle say 2 groups of 3 groups of 4 items.Also, messing around with [Explode Tree]'s output parameters can help to understand what each (or just one) branch of a tree contains if you get confused.And just in case you aren't aware, some components [Explode Tree] and [List Item] specifically, have variable output parameters if you zoom in.Hope this helps.(also, may have messed around with sliders while trying to figure stuff out, not sure if that matters)…
ble" as is the complex code for Plan B ... but... well... as the greatest ever said: less is more.
Given the opportunity ... let's go straight to the pain department:
This is the easy life: distorted stuff + N different ways to skin the cat (NOTE: instead of "vault" topology (slightly pathetic and/or why bother) go for some aggressive big overhangs)):
This is the pain and the agony: by what means can you assure that there's no clash issues around? And if they are by what means can you correct things? What things exactly? By what means can you talk to some proper BIM AEC app (obligatory in several countries already, like UK) in order to do the thingy in real-life? - spot that only the W layer consists from 10K "items" (and that without the sleeves).
Moral: long is the path (and hilly).
Staying on the easy aspect of things ... I'll post some other stuff later on.
…