eir vertex order if their direction around the shared edge is wrong. In the image below:
So in this example, if 0 is your start face, you'd want to guarantee that for face 1, its vertices on the shared edge go in the order D-E and not E-D. In the example above you'd want to flip the vertex order on face 2 because the vector at the shared edge is parallel to the one in face 0 rather than anti-parallel.
Assuming your mesh doesn't pull any nasty mobius strip topology tricks, I think this is sufficient to guarantee that your face vertex lists are all clockwise (or all counter-clockwise), which is in turn sufficient for the calculation of the face normal according to newell's method. (the cross product of two adjacent edge vectors).
Also note (I learned this the hard way) if you can't guarantee that the polygons are convex, you need to calculate the cross product for EVERY pair of edges rather than just two, and then take the sum of all the cross products.
So to sum up, in my best attempt at a pseudocode version of the above (I will most certainly butcher BFS but clearly you have an idea how it works):
breadth-first search across the faces of the polymesh
for each face check the vector of the adjacent edge against the vector of the same edge in the previous face
if they are parallel flip the order of the vertices in the polygon
calculate the normal using newell's method
next
I make no guarantees that this will even work! But I hope maybe it spurs your thinking a bit :) It's a pretty interesting problem, so please share what solution ends up working - I am eager to learn for myself!…
). So far I wrote the disfonctional code below thanks to this and this discussion as well as this tutorial (all within Giulio's VS wizzard).
I get the following errors on the third line:
Error 1 'myComponent.LoadSettings' does not implement inherited abstract member 'Grasshopper.Kernel.GH_Component.SolveInstance(Grasshopper.Kernel.IGH_DataAccess)'
and
Error 2 'myComponent.LoadSettings' does not implement inherited abstract member 'Grasshopper.Kernel.GH_Component.RegisterOutputParams(Grasshopper.Kernel.GH_Component.GH_OutputParamManager)'
I hope someone can help me solve this. My component still doesn't show up when I debug the code. Many thanks!
namespace myComponent { public class LoadSettings : GH_Component { public LoadSettings() : base("LoadSettings", "LS", "Loading .ini", "Extra","") { } public override void CreateAttributes() { m_attributes = new HelperAttributes(this); } class HelperAttributes : GH_ComponentAttributes { LoadSettings a; public HelperAttributes(LoadSettings _a) : base(_a) { a = _a; } public override GH_ObjectResponse RespondToMouseDoubleClick(GH_Canvas sender, GH_CanvasMouseEvent e) { System.Windows.Forms.OpenFileDialog ofd = new System.Windows.Forms.OpenFileDialog(); ofd.Multiselect = true; ofd.Filter = "Data Sources (*.ini)|*.ini*|All Files|*.*"; if (ofd.ShowDialog() == DialogResult.OK) { string[] filePath = ofd.FileNames; string[] safeFilePath = ofd.SafeFileNames; } return base.RespondToMouseDoubleClick(sender, e); } } public override Guid ComponentGuid { get { return new Guid("{02d35086-fddb-472d-8ce3-646cdfacf036}"); } } }}
…
imum height of built volume which would not violate the solar access for defined surroundings given filtered sun vectors.
Solar Collection - A complementary 3D envelope which defines the lowest heights from which a new built volume would receive solar access, given a built context and filtered sun vectors.
The new component harnesses ladybug's SunPath tool to determine relevant sun positions based on input from an .epw file. The simulation also takes into account surrounding buildings if provided or a self envelope if omitted, with the goal of adding control and flexibility in conjunction with a more accurate simulation.
A video tutorial is available here - https://www.youtube.com/watch?v=hRtsxgJCVEw
An example file is both attached and accessible through here - https://www.dropbox.com/s/ao11882no95io9x/solarEnvelopeAdvanced_example_file.gh?dl=0
The component takes as an input a filtered list of sun vectors, a base surface which represents the site border and a list of curves, representing the surrounding context
and outputs a point cloud and a polysurface -
which in turn can be closed and further evaluated (On the left - solar collection, on the right - solar rights) -
By Boris Plotnikov and with the assistance and guidance of Prof. Guedi Capeluto, based on SustArc model. The component could not have be alive without the invaluable help of the awesome Chris Mackey and Mostapha Sadeghipour Roudsari in development and integration, also a big thanks is due to Abraham Yezioro for testing and advising on usability.
For further reading it might be worth taking a look at Ralph Knowles's work, e.g -http://www.fau.usp.br/aut5823/Acesso_ao_Sol/Knowles_2003_Solar_Envelope.pdf and G. Capeluto and E. Shaviv's, e.g - http://www.ibpsa.org/proceedings/BS1999/BS99_C-22.pdf the component relies to a great extend on the concepts described there.
Thanks for reading and enjoy!…
eble strings?
If these two numbers are primary inputs to defining a fanned fret guitar(?), then we need to organize the code accordingly. Likewise for this statement you made:
there is one input parameter that's still missing for the multiscale frets to be fully parametric, it's the angle of the nut [and/or bridge?] or which fret should be straight
These are really key reference points that determine the usability of the model and the point of view from which we solve the geometry. Given bass and treble string lengths and which fret is "straight" (square to the neck), the angles of the nut and bridge are results, not input parameters!
The reason I'm using "virtual" Nut and Bridge lines ('vNut', 'vBridge') and rotating them around the point where they intersect the treble curve is two-fold:
I don't want nut/bridge angles to affect string spacing or have to change their lengths manually to compensate for the angles. So when they are rotated, they now get longer as necessary to preserve the neck/string geometry defined by 'vNut' and 'vBridge'.
I don't want the treble string length to change as they rotate. As a primary input parameter, this needs to remain fixed.
At present, treble string length is set indirectly as the hypotenuse of a triangle; the other two sides are set by 1) the 'midLen' slider (distance along centerline between 'vNut' and 'vBridge') and 2) the difference in lengths between 'vNut' and 'vBridge'. It doesn't need to be this way. Instead, the treble string length could be an input and the 'midLen' distance could be computed. Which method do you prefer?
As to "which fret should be straight?", this is a cool way to look at the problem and not that difficult to implement. If "fret 0" (the nut), then the nut remains square and the bridge angle is determined by the bass string length and the neck taper angle, which in turn has been defined by 'vNut' and 'vBridge'. If any other fret is specified, the bass string and all of its "fret points" can be moved to the right, along the bass string line, to align them accordingly. Then nut and bridge angles and lengths are resolved by simply connecting the ends of bass and treble strings.
This all might be a little simpler and clearer if we ignore the edge spacing and assume that 'vNut' and 'vBridge' end points define the outer edges of the bass and treble strings, then add edge spacing back later. Just a hunch.
Does this make any sense? Can you please supply a bass string length to match one of the treble string lengths you mentioned? (24.75" or 25.5")
To be continued, as spare time allows.…
calculated the height with 60cm because I take the first 50 cm of shell like support, as mesh refine is 50cm. (Pic 1)
However when I tried it with beam elements the output was different. Why? Because when I make the beam I use segments with height constant, then I have a first segment near support with 50 cm. In this situation I only modify the weight, because the support height will be just 50 cm.
In conclusion I think that it is directly related with the segment refine and the material stiffness in the support.
PS: I am working with nature structures, so I had to create a Shell Var.
Thanks and I hope you understand my explanation
Best
Patricio…
render del anillo.
Veo que posiblemente GrassHopper tiene esa capacidad de automatizar el render. Ya lo tratamos de hacer con Vray, pero no encontramos los comandos del sdk que permitan avanzar en el script.
El render que le envio es construido con V Ray de Matrix 3D que trabaja bajo Rhino. Lo que me gustaría tener es una base de como aplicar materiales usando grasshopper y asi poder seguir aprendiendo e investigando hasta lograr un buen render.
Por su ayuda y colaboración muchas gracias
Atentamente
Jorge Sanchez…
render del anillo.
Veo que posiblemente GrassHopper tiene esa capacidad de automatizar el render. Ya lo tratamos de hacer con Vray, pero no encontramos los comandos del sdk que permitan avanzar en el script.
El render que le envio es construido con V Ray de Matrix 3D que trabaja bajo Rhino. Lo que me gustaría tener es una base de como aplicar materiales usando grasshopper y asi poder seguir aprendiendo e investigando hasta lograr un buen render.
Por su ayuda y colaboración muchas gracias
Atentamente
Jorge Sanchez…
as you saw in the file; unfortunately, I cannot use the ladybug component, as I am currently working in Italy and Germany.
I also thank you very much for the new ground temperature component, it does exactly what I was looking for :)
About the additional_Strings component, I am not sure I understand its functioning, so I will try to explain how I think it should work.
1) Does it overwrite everything that is defined with Honeybee?
2) Some of the schedules I want to add are nested inside the internal gains (for example, in People gains, I would like to add the Clothing insulation). Therefore, I should use the additional_Strings to substitute the whole internal gains component from Honeybee with the E+ object, am I right? However, as I don't want lose all the advantage of a parametric software like grasshopper and the optimization of Galapagos, I would like to define all my schedules with the csv schedule component of honeybee and call them afterwards with the additional_Strings as external files.... this way everything should work, right?
Next week I will give it a try and let you know if it worked.
thank you again
Letizia…
bution. This switch did get all of the severe E+ errors to disappear. Also, it initially got the glazing surface results to read. Then I ran the simulation a second time and the results disappeared again. Any idea why the surface results disappear the second go round?
2. As for the surface normals, the normals of the surfaces coming out of the "Glazing Based on Ratio" component do seem to be oriented both in the correct direction, both oriented outward. See the image below. I've also tested it using the Child Surface method with the "addHBglz" component, and all of those surfaces are also correctly oriented outward. When I rerun both simulations, the surface data still does not read surface results for the glazing (it does read the surface results from opaque portion of the wall).
3. 3.Lastly, any suggests for getting an off the shelf mech system hooked up so the results will read as End Use Energy Consumption, rather than the Ideal Air Loads? Any suggestions would be great!
Thanks for your help.…
ent GH file.
This is quite irritating, as some of the scribbles are annotation of the workflow.
May I ask if there is a solution for this problem?
Thanks!
E,g:
1. this is the overall image of all the components on canvas:
2. this is the scribble object shown in the area indicated by the arrow shown above
3. However, after I copy and past all the selected components on the canvas to a new GH file, the scribble object is gone ...
…
Added by Grasshope at 1:18am on September 21, 2016