windows. I manage to have proper HBZones with RADMaterials and EPConstructions (I've run Daylight calculation on them successfully), but when I plug the zones to GrizzlyBear this error appears:
Solution exception:'EPZone' object has no attribute 'getCurrentLoads'
In addition, something similar happens when I plug these HBZones to the newest decomposeByType component, althought it works properly when plugged to the previous version of it. This is what the error says:
Solution exception:'hb_EPZoneSurface' object has no attribute 'BC'
Same thing with SetEPZoneConstruction:
Solution exception:'hb_EPZoneSurface' object has no attribute 'BCObject'
Any thought?
Ander…
the bubble diagram. This algorithm works by a set of attractive and repulsive forces (as in Equation 9) acting recursively on graph vertices, seeks a ‘relax’ situation for a graph, and reaches to a graph drawing. This tool is quite intuitive and shows in real-time bubble diagrams neatly according to the specified areas and the connectivity graph.
Equation 9
Attraction: 〖AF〗_ij=ka ∆x_ij for all linked (i,j)
Repulsion: 〖RF〗_ij=kr /x_ij for all (i,j)
The attraction/repulsion strength inputs are denoted as ka and kr
in the above equations. If some configuration is very messy, you need to have a high repulsion first to untangle it. I have not tried Angel's method but it is very similar to the method we have scripted for this component.
I hope this helps.
Best regards,
Pirouz…
like to use a single VRay material as a template for creating multiple identical materials with different colors within the GH environment (instead of creating manually in the document).
I have gotten as far as creating the materials. Now I need to add them to the document material table so that they can be used with Giulio's rendering component (which looks for either Rhino.Display.DisplayMaterial or a String that references a document object). I'm not going to learn C# to modify his script, so I am catering to its demands.
Private Sub RunScript(ByVal M As Object, ByVal C As Color, ByRef Mat As Object)
Dim mTemp As Rhino.DocObjects.Material mTemp = CType(M, Rhino.DocObjects.Material) If mTemp.Name.Length > 0 Then mTemp.DiffuseColor = C Dim nTemp As String = mTemp.Name & "_" & C.R & "_" & C.G & "_" & C.B mTemp.Name = nTemp End If
Rhino.DocObjects.Tables.MaterialTable.Add(mTemp) Mat = mTemp
End Sub
The code throws the error: Reference to a non-shared member requires an object reference. (line 96)
Do I understand that the material has to be assigned to a particular object in order to enter the Material Table? Can I assign it to a Layer instead? Any ideas? A better way to do this?
Thanks,
Marc
…
cannot be cast to [B]CustomClassXY. Type A originates from 'CustomLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadNeither' in a byte array. Type B originates from 'CustomLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' in the context 'LoadFrom' at location 'C:\Users\T\AppData\Roaming\Grasshopper\Libraries\CustomLib.gha'. (line: 96)This is how I do the casting:List<CustomLib.SomeClass.CustomClassXY> AllINPUTs = new List<CustomLib.SomeClass.CustomClassXY>();
for (int i = 0 ; i < INPUT.Count; i++)// { AllINPUTs.Add((CustomLib.SomeClass.CustomClassXY) INPUT[i]); }
The GHA is compiled with two namespaces, one for the component one for the library.
Thanks a lot in advance,
Tim…
st for the quality of the mesh.
Actually, convergence is much more than simply having low residuals. You can have a wrong solution with very low residuals. Usually, it is a combined process of both run time information on residuals and having an idea or expectation of what the simulation results should be. Another way of assessing convergence is if the residual values have been stable (within a very small limit, e.g. 1E-5) for more than a certain number of iterations (e.g. 1000). We are planning to provide run-time residual plots in Butterfly, hopefully soon. These plots can help keeping an eye on the solution.
You could try as a test if you want to switch to a blend of first and second order (by swapping upwind with linearUpwind in the fvSchemes)
.
Concerning mesh quality there are a number of ways, some of which are a bit advanced for this post and for BF's current capabilities. The best way to start is by refining the background mesh (i.e. the blockMesh). You can do that by assigning more cells to the x, y and z directions in the blockMesh component. However, make sure you increase the max global cells. I would suggest you monitor the output of the blockMesh in order to know the total number of cells there. Your max global cells has to be higher than that for SHM to even work. I'd suggest 2x to start with. Ofc all that requires a bit of trial and error depending on the case at hand.
Hope this helps!
Kind regards,
Theodore.…
e some questions.
I want to loop with a foreach loop trough a list of points do i have to make a list before or is it possible to use them coming in from a noed i set the access to list?
Also i dont understand why no plane is created. How do i need to feed the points in?
And why is c# expecting open parens in line 88 and 86?
Hope its not to much at once, probably i should try a few less steps to get the problems solved one by one, just hoped it would be easier and sometimes just a parentesis is missing or some format stuff, so maybe it is not so much i really cant say.
If anybody has the time and feels he wants to help it would be nice on the other hand i understand cause of the amount of chaotic questions.
Regards!…
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
n make it possible to Motivation generate
a variety of interesting objects, from abstract fractals to plant-like
branching structures, their modeling power is quite limited. A major
problem can be traced to the reduction of all lines to integer multiples
of the unit segment. As a result, even such a simple figure as an
isosceles right-angled triangle cannot be traced exactly, since the ratio
of its hypotenuse length to the length of a side is expressed by the irrational
number √2. Rational approximation of line length provides only
a limited solution, because the unit step must be the smallest common
1
1
√2
denominator of all line lengths in the modeled structure. Consequently,
the representation of a simple plant module, such as an internode, may
require a large number of symbols. The same argument applies to angles.
Problems become even more pronounced while simulating changes
to the modeled structure over time, since some growth functions cannot
be expressed conveniently using L-systems. Generally, it is difficult
1.10. Parametric L-systems 41
to capture continuous phenomena, since the obvious technique of discretizing
continuous values may require a large number of quantization
levels, yielding L-systems with hundreds of symbols and productions.
Consequently, model specification becomes difficult, and the mathematical
beauty of L-systems is lost.
In order to solve similar problems, Lindenmayer proposed that numerical
parameters be associated with L-system symbols [83]. He illustrated
this idea by referring to the continuous development of branching
structures and diffusion of chemical compounds in a nonbranching filament
of Anabaena catenula.
The following is an example of its application:
starting string: A
p1: A F(1)[+A][-A]
P2: F(s) F(s*R)
which I think is basically trying to say
F(s) = move forwar a step of length s > 0.
Thanks again,
Mateo…
ther math and logic. i can usually conceptualise what i want to do and cobble some semi working thing together but don't know which components to use and how to patch it. so i'm super happy to have someone who knows what he's doing to find this interesting.
and i'm glad you mention the fanned frets again, there is one input parameter that's still missing for the multiscale frets to be fully parametric, it's the angle of the nut or which fret should be straight. it depends a bit on personal preferences and playing posture what is more comfortable. so being able to adjust this easily would be cool. again i have no idea how the maths for that work or if you can just rotate each fret the same amount around it's middle point. The input either as fret number (for the straight fret) or as a simple slider from bridge to nut should do as input setting.
Here are the two extremes and the middle ground:
i've been thinkin today while analysing your patches and cleaning up my mess what exactly the monster should do.
Here are the input parameters needed, i think it's the complete list
scale length low E string
scale length high e string
fret angle/straight fret
string width at nut
string width at bridge
number of frets
fretboard overhang at nut (distance from string to fretboard bounds)
fretboard overhang at last fret
string gauges
string tensions
fretboard radius at nut (for compound radius fretboard radius at bridge is calculated with the stewmac formula)
fretwire crown width
fretwire crown height
action height at nut (distance between bottom of string and fretwire crown top)
action height at last fret
pickup 1 neck position
pickup 2 middle position
pickup 3 bridge position
nut width
the pickup positions should be used to draw circles for the magnet poles on each string so they are perfectly aligned and can be used for the pickup flatwork construction. ideally they would need a rotation control aligning the center line of the pickup so it's somewher between the last fret angle and bridge angle. personally i do this visually depending on the design i'm looking for, some people have huge theories on pickup positioning but personally i don't believe in it.
that should result in everything needed to quickly generate all the necessary construction curves or geometry for nut/fingerboard/frets/pickups. this is the core of what makes a guitar work, the more precise this dynamic system is the better the guitar plays and sounds.
i posted another thread trying to understand how i could use datasets form spreadsheets,databse, csv to organize the input parameters. What would make sense for the strings for example is hook into a spreadsheet with the different string sets, i attached one for the d'Addario NYXL string line which basically covers all combos that make sense.
The string tension is an interesting one, and implmenting it would sure be overkill albeit super interesting to try. it should be possible to extrapolate from the scale length of each string what the tension for a given string gauge of that string would be so that you could say 'i want a fully balanced set' or 'heavy top light bottom) and it would calculate which SKU from d'addario would best match the required tension. All the strings listed in the spreadsheet are available as single strings to buy.
i'm trying to reorganize everything which helps me understand it. i just discovered the 'hidden wires' feature which is great since once i understood what a certain block does or have finished one of my own, i can get the wires out of the way to carry on undistracted. a bit risky to hide so many wires but it makes it so much easier not to get completely lost :-)
btw, the 'fanned fret' term is trademarked, some guy tried to patent it in the 80's which is a bit silly since it has been done for centuries. there is a level of sophistication above this as well, check out http://www.truetemperament.com/ and that really is something else. it really is astounding how superior the tuning is on those wigglefrets, the problem is that it's rather awkward for string bending and also you can't easily recrown or level the frets when they are used. …
e matching with a dedicated component which creates combinations of items. You can find the [Cross Reference] component in the Sets.List panel.
When Grasshopper iterates over lists of items, it will match the first item in list A with the first item in list B. Then the second item in list A with the second item in list B and so on and so forth. Sometimes however you want all items in list A to combine with all items in list B, the [Cross Reference] component allows you to do this.
Here we have two input lists {A,B,C} and {X,Y,Z}. Normally Grasshopper would iterate over these lists and only consider the combinations {A,X}, {B,Y} and {C,Z}. There are however six more combinations that are not typically considered, to wit: {A,Y}, {A,Z}, {B,X}, {B,Z}, {C,X} and {C,Y}. As you can see the output of the [Cross Reference] component is such that all nine permutations are indeed present.
We can denote the behaviour of data cross referencing using a table. The rows represent the first list of items, the columns the second. If we create all possible permutations, the table will have a dot in every single cell, as every cell represents a unique combination of two source list indices:
Sometimes however you don't want all possible permutations. Sometimes you wish to exclude certain areas because they would result in meaningless or invalid computations. A common exclusion principle is to ignore all cells that are on the diagonal of the table. The image above shows a 'holistic' matching, whereas the 'diagonal' option (available from the [Cross Reference] component menu) has gaps for {0,0}, {1,1}, {2,2} and {3,3}:
If we apply this to our {A,B,C}, {X,Y,Z} example, we should expect to not see the combinations for {A,X}, {B,Y} and {C,Z}:
The rule that is applied to 'diagonal' matching is: "Skip all permutations where all items have the same list index". 'Coincident' matching is the same as 'diagonal' matching in the case of two input lists which is why I won't show an example of it here (since we are only dealing with 2-list examples), but the rule is subtly different: "Skip all permutations where any two items have the same list index".
The four remaining matching algorithms are all variations on the same theme. 'Lower triangle' matching applies the rule: "Skip all permutations where the index of an item is less than the index of the item in the next list", resulting in an empty triangle but with items on the diagonal.
'Lower triangle (strict)' matching goes one step further and also eliminates the items on the diagonal:
'Upper Triangle' and 'Upper Triangle (strict)' are mirror images of the previous two algorithms, resulting in empty triangles on the other side of the diagonal line:
…