the pipe component .I have one curve ,but Pipe component outputs two pipes .This guide curve have two kinks . Pipe component fails at one of them .
Bug #3
I guess this bug may have been fixed .
Wish #1
I hope adding an "reverse list" option to the right-click menu .I think this would be useful (at least for myself).
Wish #2
I hope the SimplifyTree component would clear the zeros located at the end and middle of branch in condition the branches have same length.For example, I have a tree looks like :
A = {0;1;0} B = {0;1;0;1}
C = {0;1;0;0;1;0;0;0}
After simplify ,I get:
A = {1} B = {1;0;1}
C = {1;0;0;1}
And if the tree structure is something like:
A={0;0;1;0}
B={0;0;1;1}
C={0;0;1;2}
After simplify ,I get:
A={1;0}
B={1;1}
C={1;2}
But If the tree is:
A={0;0;0;0;0;0}
B={0;0;1;0;1;0}
C={0;0;1;0;2;0}
I get:
A={0;0}
B={1;1}
C={1;2}
WIsh #3
I came across conditions that there is no direct way to handle some Datatree matching problems . And now I think I find what's the problem :GH now lack the capability to make cross reference between lists/branches .For example, I have two trees ,the first one have two branches {0}&{1}, the other have three branches{0}&{1}&{2}.Now GH would do:
what I want is :
If this can come true ,I can say it would be very very very useful . I just have a coarse idea on how to do that: Like () wrap items,{} wrap branches, then [] wrap trees .
Say I have a tree [0] ,which have three brabches{0},{1},{2}. So [0]=[{0};{1};{2}] or [0]=[{0},{1},{2}]
If this is ruled, the following fomula is meanningful:
[0]=[{0}] (this means tree[0] just have one branch)
[0]=[{0;0;0};{0;0;1};{0;0;2}]
[0]=[{0;0};{0;1};{0;2}]=[{0;0;0};{0;0;1};{0;1};{0;2}]After that, Maybe we could match [{0};{1}] and [{0};{1};{2}] very easily (Longest List;Shortest List;Cross Reference) ??
I tried to explain the concept of "tree" to my friends ,but I am confuzed somewhere myself .For example ,how could we have a tree including branches {0},{0;0}and{0;0;0} at the same time??{0} should be the biggest tree trunk,and {0;0} is part of {0} .{0;0;0} is just the smallest trunk and store the least data inside .How could the biggert trucks are empty while only the smallest branches contain items ?(David drawed a datatree that tell this,remember??)
But if this idea is acceptable ,then I could make a fairy tale about tree to them :
(Long long ago...)
[0] is a tree ,[1] is a tree.
{0},{1},{0;0}.{0;1;0} are branches.
{0}=(0,1,2,3,4,5) is branch.
[0]= [{0;0;0};{0;0;1};{0;0;2] is a standard tree .
[0]=[{0;0;0};{0;0;2};{0;0;3] is a pruned tree.
[{0};{0;0};{0;0;0}] is an illegal tree .
Gh is lenient enough to allow the existence of illegal tree .
Gh is lenient enough to allow the existence of empty trees& empty branch&null items.
We can use PathMapper to transform an illegal tree into a legal one and vice versa . We can use PathMapper to do any things to tree&branch&item.
Wish #4
wish for Split List component : it would have a wrap option just like many other components.In this way , we can split a list of data at -1 .I think this would be useful .
wish #5
wish for a Preview toggle component .See picture below (it's fake).
this toggle look mostly like the boolean toggle, but it have a input param by which we can control the preview logically and smartly .
When there is no input ,we can control swith the preview with a double click action .This toggle component could control all gh geometry overriding the global setting .The link curve between toggle and target works just like the galapagos.
Wish #6
Wish for adding arc angle output to both Arc 3pt and Arc SED components.This would make things easier sometimes .
Wish #7
Many times I were puzzled that a same gh script would perform perfect if the input is single surface but buggy while the input is more than one surface .After debuging many times ,I just found that if one or two component of the script do things smarter ,this kind of bugs would never happen again !! Simply saying:we need a optional datatree match behavior. Say I have two datatree [{0;0};{0;1}] and [{0;0;0};{0;0;1};{0;0;2};{0;0;3};
{0;1;0};{0;1;1};{0;1;2};{0;1;3}] Normally {0;0} matchs {0;0;0},{0;1} matchs other branches (Longest List behavior).Now I need {0;0} matchs {0;0;0},{0;0;1},{0;0;2},{0;0;3} separately and {0;1} matchs {0;1;0};{0;1;1};{0;1;2};{0;1;3} separately .I cant describe this matching rules accurately but it's very obvious .I hope you can understand the meaning .
I remember David said once that he would not change anything about the datatree matching rules in order to avoid destroy people's production work .And that is my bottomline too .What I want is when I need one component to match the input datatree in this way ,I can switch it (just it ) into this mode (Assuming these is a "xxx mode" option in component's right-click menu ). In this way ,All the exist Gh def would not be destoryed.
PS. I am not carping but I found the DivideKink param input of Divide Curve component is useless except adding a segments output .
…
ar closed curve that is supposed to go to create a flat surface together with the other closed curves present in the same plane.
I don't know how can create this surface!!…
analysis with Honeybee. Here is the tentative outline:
09:00 - 09:30
What is Honeybee, Introduction to daylighting simulation
09:30 - 11:00
Geometry preparation workflows, Radiance materials
11:00 - 11:10
Break
11:10 - 12:30
Sky types, Run your first simulation
12:30 - 13:30
Lunch
13:30 - 15:00
Daylighting analysis types, Result visualization, Getting started with annual daylight
15:00 - 15:15
Break
15:15 - 16:00
Annual daylight analysis and Results interpretation
Check MEBD page for more information including the registration link: http://www.mebd-penndesign.info/Honeybee-MEBD-Workshop-PennDesign
Please feel free to forward this to anyone of interest.
Cheers,
Mostapha
PS: Thank you all for the kind comments and emails for the Ladybug workshop. We recorded the workshop and are in the process of figuring out how to share it with the public. I will send an update once it is uploaded.
…
ng is deciding how and where to store your data. If you're writing textual code using any one of a huge number of programming languages there are a lot of different options, each with its own benefits and drawbacks. Sometimes you just need to store a single data point. At other times you may need a list of exactly one hundred data points. At other times still circumstances may demand a list of a variable number of data points.
In programming jargon, lists and arrays are typically used to store an ordered collection of data points, where each item is directly accessible. Bags and hash sets are examples of unordered data storage. These storage mechanisms do not have a concept of which data comes first and which next, but they are much better at searching the data set for specific values. Stacks and queues are ordered data structures where only the youngest or oldest data points are accessible respectively. These are popular structures for code designed to create and execute schedules. Linked lists are chains of consecutive data points, where each point knows only about its direct neighbours. As a result, it's a lot of work to find the one-millionth point in a linked list, but it's incredibly efficient to insert or remove points from the middle of the chain. Dictionaries store data in the form of key-value pairs, allowing one to index complicated data points using simple lookup codes.
The above is a just a small sampling of popular data storage mechanisms, there are many, many others. From multidimensional arrays to SQL databases. From readonly collections to concurrent k-dTrees. It takes a fair amount of knowledge and practice to be able to navigate this bewildering sea of options and pick the best suited storage mechanism for any particular problem. We did not wish to confront our users with this plethora of programmatic principles, and instead decided to offer only a single data storage mechanism.*
Data storage in Grasshopper
In order to see what mechanism would be optimal for Grasshopper, it is necessary to first list the different possible ways in which components may wish to access and store data, and also how families of data points flow through a Grasshopper network, often acquiring more complexity over time.
A lot of components operate on individual values and also output individual values as results. This is the simplest category, let's call it 1:1 (pronounced as "one to one", indicating a mapping from single inputs to single outputs). Two examples of 1:1 components are Subtraction and Construct Point. Subtraction takes two arguments on the left (A and B), and outputs the difference (A-B) to the right. Even when the component is called upon to calculate the difference between two collections of 12 million values each, at any one time it only cares about three values; A, B and the difference between the two. Similarly, Construct Point takes three separate numbers as input arguments and combines them to form a single xyz point.
Another common category of components create lists of data from single input values. We'll refer to these components as 1:N. Range and Divide Curve are oft used examples in this category. Range takes a single numeric domain and a single integer, but it outputs a list of numbers that divide the domain into the specified number of steps. Similarly, Divide Curve requires a single curve and a division count, but it outputs several lists of data, where the length of each list is a function of the division count.
The opposite behaviour also occurs. Common N:1 components are Polyline and Loft, both of which consume a list of points and curves respectively, yet output only a single curve or surface.
Lastly (in the list category), N:N components are also available. A fair number of components operate on lists of data and also output lists of data. Sort and Reverse List are examples of N:N components you will almost certainly encounter when using Grasshopper. It is true that N:N components mostly fall into the data management category, in the sense that they are mostly employed to change the way data is stored, rather than to create entirely new data, but they are common and important nonetheless.
A rare few components are even more complex than 1:N, N:1, or N:N, in that they are not content to operate on or output single lists of data points. The Divide Surface and Square Grid components want to output not just lists of points, but several lists of points, each of which represents a single row or column in a grid. We can refer to these components as 1:N' or N':1 or N:N' or ... depending on how the inputs and outputs are defined.
The above listing of data mapping categories encapsulate all components that ship with Grasshopper, though they do not necessarily minister to all imaginable mappings. However in the spirit of getting on with the software it was decided that a data structure that could handle individual values, lists of values, and lists of lists of values would solve at least 99% of the then existing problems and was thus considered to be a 'good thing'.
Data storage as the outcome of a process
If the problems of 1:N' mappings only occurred in those few components to do with grids, it would probably not warrant support for lists-of-lists in the core data structure. However, 1:N' or N:N' mappings can be the result of the concatenation of two or more 1:N components. Consider the following case: A collection of three polysurfaces (a box, a capped cylinder, and a triangular prism) is imported from Rhino into Grasshopper. The shapes are all exploded into their separate faces, resulting in 6 faces for the box, 3 for the cylinder, and 5 for the prism. Across each face, a collection of isocurves is drawn, resembling a hatching. Ultimately, each isocurve is divided into equally spaced points.
This is not an unreasonably elaborate case, but it already shows how shockingly quickly layers of complexity are introduced into the data as it flows from the left to the right side of the network.
It's no good ending up with a single huge list containing all the points. The data structure we use must be detailed enough to allow us to select from it any logical subset. This means that the ultimate data structure must contain a record of all the mappings that were applied from start to finish. It must be possible to select all the points that are associated with the second polysurface, but not the first or third. It must also be possible to select all points that are associated with the first face of each polysurface, but not any subsequent faces. Or a selection which includes only the fourth point of each division and no others.
The only way such selection sets can be defined, is if the data structure contains a record of the "history" of each data point. I.e. for every point we must be able to figure out which original shape it came from (the cube, the cylinder or the prism), which of the exploded faces it is associated with, which isocurve on that face was involved and the index of the point within the curve division family.
A flexible mechanism for variable history records.
The storage constraints mentioned so far (to wit, the requirement of storing individual values, lists of values, and lists of lists of values), combined with the relational constraints (to wit, the ability to measure the relatedness of various lists within the entire collection) lead us to Data Trees. The data structure we chose is certainly not the only imaginable solution to this problem, and due to its terse notation can appear fairly obtuse to the untrained eye. However since data trees only employ non-negative integers to identify both lists and items within lists, the structure is very amenable to simple arithmetic operations, which makes the structure very pliable from an algorithmic point of view.
A data tree is an ordered collection of lists. Each list is associated with a path, which serves as the identifier of that list. This means that two lists in the same tree cannot have the same path. A path is a collection of one or more non-negative integers. Path notation employs curly brackets and semi-colons as separators. The simplest path contains only the number zero and is written as: {0}. More complicated paths containing more elements are written as: {2;4;6}. Just as a path identifies a list within the tree, an index identifies a data point within a list. An index is always a single, non-negative integer. Indices are written inside square brackets and appended to path notation, in order to fully identify a single piece of data within an entire data tree: {2,4,6}[10].
Since both path elements and indices are zero-based (we start counting at zero, not one), there is a slight disconnect between the ordinality and the cardinality of numbers within data trees. The first element equals index 0, the second element can be found at index 1, the third element maps to index 2, and so on and so forth. This means that the "Eleventh point of the seventh isocurve of the fifth face of the third polysurface" will be written as {2;4;6}[10]. The first path element corresponds with the oldest mapping that occurred within the file, and each subsequent element represents a more recent operation. In this sense the path elements can be likened to taxonomic identifiers. The species {Animalia;Mammalia;Hominidea;Homo} and {Animalia;Mammalia;Hominidea;Pan} are more closely related to each other than to {Animalia;Mammalia; Cervidea;Rangifer}** because they share more codes at the start of their classification. Similarly, the paths {2;4;4} and {2;4;6} are more closely related to each other than they are to {2;3;5}.
The messy reality of data trees.
Although you may agree with me that in theory the data tree approach is solid, you may still get frustrated at the rate at which data trees grow more complex. Often Grasshopper will choose to add additional elements to the paths in a tree where none in fact is needed, resulting in paths that all share a lot of zeroes in certain places. For example a data tree might contain the paths:
{0;0;0;0;0}
{0;0;0;0;1}
{0;0;0;0;2}
{0;0;0;0;3}
{0;0;1;0;0}
{0;0;1;0;1}
{0;0;1;0;2}
{0;0;1;0;3}
instead of the far more economical:
{0;0}
{0;1}
{0;2}
{0;3}
{1;0}
{1;1}
{1;2}
{1;3}
The reason all these zeroes are added is because we value consistency over economics. It doesn't matter whether a component actually outputs more than one list, if the component belongs to the 1:N, 1:N', or N:N' groups, it will always add an extra integer to all the paths, because some day in the future, when the inputs change, it may need that extra integer to keep its lists untangled. We feel it's bad behaviour for the topology of a data tree to be subject to the topical values in that tree. Any component which relies on a specific topology will no longer work when that topology changes, and that should happen as seldom as possible.
Conclusion
Although data trees can be difficult to work with and probably cause more confusion than any other part of Grasshopper, they seem to work well in the majority of cases and we haven't been able to come up with a better solution. That's not to say we never will, but data trees are here to stay for the foreseeable future.
* This is not something we hit on immediately. The very first versions of Grasshopper only allowed for the storage of a single data point per parameter, making operations like [Loft] or [Divide Curve] impossible. Later versions allowed for a single list per parameter, which was still insufficient for all but the most simple algorithms.
** I'm skipping a lot of taxonometric classifications here to keep it simple.…
Added by David Rutten at 2:22pm on January 20, 2015
.
Things have been working swimmingly in many areas of the plugin, but one particular problem has been tough to solve. I have two components that are trying to read/write to the same memory at the same time, causing Rhino exceptions and crashes.
The conflicts appear to be happening between two components -- one is a "Layer Events Listener" that reports essentially what type of layer event just happened. The other is a "Set Layer Visibility" component that toggles the visibility of a list of layers.
The code:
public class LayerTools_LayerEventsListener : GH_Component { /// <summary> /// Initializes a new instance of the LayerTools_LayerListener class. /// </summary> public LayerTools_LayerEventsListener() : base("Layer Events Listener", "Layer Listener", "Get granular information about the layer events happening in the Rhino document.", "Squirrel", "Layer Tools") { }
/// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to listen to layer events in the Rhino document.", GH_ParamAccess.item, false); pManager.AddTextParameter("Exclusions", "E", "Provide a list of exclusions to stop reading specific events (Added, Deleted, Moved, Renamed, Locked, Visibility, Color, Active).", GH_ParamAccess.list); pManager[1].Optional = true; }
/// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddBooleanParameter("Initialized", "I", "Whether the listener changed from passive to active.", GH_ParamAccess.item); pManager.AddTextParameter("Document Name", "doc", "Name of the Rhino document that is changing.", GH_ParamAccess.item); pManager.AddTextParameter("Layer Path", "path", "Path of the modifed layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Layer Index", "ID", "Index of the modified layer.", GH_ParamAccess.item); pManager.AddIntegerParameter("Sort Index", "SID", "Sort index of the modified layer.", GH_ParamAccess.item); pManager.AddTextParameter("Event Type", "T", "Type of the modification.", GH_ParamAccess.item); pManager.AddBooleanParameter("Added", "A", "If the layer has been added.", GH_ParamAccess.item); pManager.AddBooleanParameter("Deleted", "D", "If the layer has been deleted.", GH_ParamAccess.item); pManager.AddBooleanParameter("Moved", "M", "If the layer has been moved.", GH_ParamAccess.item); pManager.AddBooleanParameter("Renamed", "R", "If the layer has been renamed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Locked", "L", "If the layer locked setting has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Visibility", "V", "If the layer's visibility has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Color", "C", "If the layer's color has changed.", GH_ParamAccess.item); pManager.AddBooleanParameter("Active", "Act", "If the active layer has changed.", GH_ParamAccess.item); }
/// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; List<string> exclusions = new List<string>();
DA.GetData(0, ref active); DA.GetDataList(1, exclusions);
RhinoDoc thisDoc = null;
bool initialize = false;
string dName = null; string activePath = null; int layerIndex = -1; int sortIndex = -1; string eventType = null; bool added = false; bool deleted = false; bool moved = false; bool renamed = false; bool locked = false; bool visibility = false; bool color = false; bool current = false;
if (active) { thisDoc = RhinoDoc.ActiveDoc;
initialize = (!previouslyActive) ? true : false;
RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; RhinoDoc.LayerTableEvent += RhinoDoc_LayerTableEvent; previouslyActive = true;
} else {
RhinoDoc.LayerTableEvent -= RhinoDoc_LayerTableEvent; previouslyActive = false; }
if (ev != null) { dName = ev.Document.Name; layerIndex = ev.LayerIndex; eventType = ev.EventType.ToString();
if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Current") { // active layer has just been changed current = true; }
}
if (!exclusions.Contains("Moved")) { if (ev.EventType.ToString() == "Sorted") { // active layer has just been changed moved = true; }
}
if (!exclusions.Contains("Added")) { if (ev.EventType.ToString() == "Added") { // layer has just been added activePath = ev.NewState.FullPath; added = true; }
}
if (!exclusions.Contains("Active")) { if (ev.EventType.ToString() == "Deleted") { // layer has just been added
deleted = true; } }
if (ev.EventType.ToString() == "Modified") { // layer has been modified activePath = ev.NewState.FullPath;
//skip sortindex eventType = ev.EventType.ToString();
if (ev.OldState != null && ev.NewState != null) { if (!exclusions.Contains("Locked")) { if (ev.OldState.IsLocked != ev.NewState.IsLocked) locked = true;
} if (!exclusions.Contains("Visibility")) { if (ev.OldState.IsVisible != ev.NewState.IsVisible) visibility = true; }
if (!exclusions.Contains("Moved")) { if (ev.OldState.ParentLayerId != ev.NewState.ParentLayerId) moved = true; }
//if (ev.OldState.SortIndex != ev.NewState.SortIndex) moved = true; if (!exclusions.Contains("Renamed")) { if (ev.OldState.Name != ev.NewState.Name) renamed = true; }
if (!exclusions.Contains("Color")) { if (ev.OldState.Color != ev.NewState.Color) color = true; } }
} }
DA.SetData(0, initialize); DA.SetData(1, dName); DA.SetData(2, activePath); DA.SetData(3, layerIndex); DA.SetData(4, sortIndex); DA.SetData(5, eventType); DA.SetData(6, added); DA.SetData(7, deleted); DA.SetData(8, moved); DA.SetData(9, renamed); DA.SetData(10, locked); DA.SetData(11, visibility); DA.SetData(12, color); DA.SetData(13, current);
}
static bool previouslyActive = false; Rhino.DocObjects.Tables.LayerTableEventArgs ev = null;
void RhinoDoc_LayerTableEvent(object sender, Rhino.DocObjects.Tables.LayerTableEventArgs e) { ev = e;this.ExpireSolution(true); }
And for the layer visibility component:
public LayerTools_SetActiveLayer() : base("Set Active Layer", "SetActiveLayer", "Set the active layer in the Rhino document.", "Squirrel", "Layer Tools") { }
/// <summary> /// Registers all the input parameters for this component. /// </summary> protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.AddBooleanParameter("Active", "A", "Set to true to change the active layer in Rhino.", GH_ParamAccess.item, false); pManager.AddTextParameter("Path", "P", "Full path of the layer to be activated.", GH_ParamAccess.item); }
/// <summary> /// Registers all the output parameters for this component. /// </summary> protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.AddIntegerParameter("Layer ID", "ID", "Index of layer that has been activated.", GH_ParamAccess.item); pManager.AddBooleanParameter("Status", "St", "True when the layer has been activated.", GH_ParamAccess.item); }
/// <summary> /// This is the method that actually does the work. /// </summary> /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param> protected override void SolveInstance(IGH_DataAccess DA) { bool active = false; string path = "";
if (!DA.GetData(0, ref active)) return; if (!DA.GetData(1, ref path)) return;
int layer_index = -1; bool status = false;
if (path != null) {
Rhino.RhinoDoc doc = Rhino.RhinoDoc.ActiveDoc; Rhino.DocObjects.Tables.LayerTable layertable = doc.Layers;
layer_index = layertable.FindByFullPath(path, true);
if (layer_index > 0) { // if exists RhinoDoc.ActiveDoc.Layers.SetCurrentLayerIndex(layer_index, true); status = true; } }
DA.SetData(0, layer_index); DA.SetData(1, status); }
Now originally I was getting exceptions when changing multiple layers' visibility properties, which would cause the Event Listener to fire and try to read the Visibility property before the memory has been released by the Set Layer Visibility component. That led me to add an "Exceptions" input, that would allow me to disable the reading of Visibility events at the source in the Layer Events listener. That helped me manage about 95% of the crashes I was getting, but I still get strange crashes in other event properties, even when that property shouldn't be affected. For instance, I am getting a crash here on the Name property in the event from the delegate function, even though I am only changing Visibility at any one time:
I have a few ideas but they all seem pretty hacky. One is to try to set a flag that is readable by any component in the plugin -- so that the event listener can see if a "set" component is currently running and abort before causing an exception. The other is creating a delay in the event listener, somthing like 200ms, to allow any set components to finish what they are doing before reading the event. Neither seems super ideal.
Any ideas?
Thanks,
Marc
…
he time to work with it.
the project is about facade strips which turns along height. the top angle is
parallel to the facade and the bottom is max. 90 degrees twisted, but the strips
should turn diffrently to achieve more dinamic look.
first i have tried to achieve this by calculating distance between the rotation angle from points of the grid and a single point.
then i have tried to ad some more effecting points and used the distance to the divided surface (the circles are just to control the area of effection):
i manually lofted it.
the result is a bit annoying becouse the points that effect the angle are always visible:
i have triend to solve this by drawing a line and divided it to recieve points along the bottom of the geometry. the result is not working properly:
Anyway,
there must be a better/smoother way to achieve this. i would like to effect the twist of the surfaces by distance to a spline, but im just lost. can you help me please?
the problems im encountering:
0- distance spline to grid to effect the angle
1- list of x/y coordinates and angle of rotation for each point of the grid
2- export points to excel
3- lofting lines in one direction only (x1, x2, x3...)
4- reduce the list data to 2 decimal (0,00)
5- maybe angle from radian to degrees
thx…
each face of the mesh, but apparentely rhinoscriptsyntax.MeshVertexColors doesn't give me an output I can read and use , and same goes when I try to use rhinoscriptsyntax.ColorHLSToRGB command
look:
import rhinoscriptsyntax as rs
rs.Command("_selmesh")
rs.Command("unweld 0")
rs.UnselectAllObjects
rs.AddLayer("MainMesh")#'pick Mesh which is unwelded at 0strObject = rs.GetObject("Select mesh", 32)#'store mesh in base layerrs.ObjectLayer(strObject,"MainMesh")#' get the face vertices of the mesharrFaces = rs.MeshFaces(strObject, True)#'get the vertex colors of the meshcolor = rs.MeshVertexColors(strObject)
i = 0
arrFace = []arrHLS = []arrFaceVertices2 = []
while i <= len(arrFaces)-1:''''''arrFace.append(arrFaces[i]) ''''''arrFace.append(arrFaces[i+1]) ''''''arrFace.append(arrFaces[i+2]) ''''''arrFace.append(arrFaces[i+3]) ''''''arrHLS.append(rs.ColorRGBToHLS(color[i])) ''''''print(color[i]) ''''''print arrHLS
'''''' i = i + 4
''''''arrFace = [] ''''''arrHLS = [] ''''''arrFaceVertices2 = []
############
The result I get is :
Color [A=255, R=55, G=55, B=55][<Rhino.Display.ColorHSL object at 0x00000000000001F7 [Rhino.Display.ColorHSL]>]Color [A=255, R=55, G=55, B=55][<Rhino.Display.ColorHSL object at 0x00000000000001F8 [Rhino.Display.ColorHSL]>]Color [A=255, R=55, G=55, B=55][<Rhino.Display.ColorHSL object at 0x00000000000001F9 [Rhino.Display.ColorHSL]>]Color [A=255, R=59, G=59, B=59][<Rhino.Display.ColorHSL object at 0x00000000000001FA [Rhino.Display.ColorHSL]>]Color [A=255, R=55, G=55, B=55][<Rhino.Display.ColorHSL object at 0x00000000000001FB [Rhino.Display.ColorHSL]>]
But if I try to get color[i][0] I get an error, how can I access to the numbers RGB or the HLS one as numbers?
Thanks a lot!
V.…
n be moved to the appropriate place. The files are sensitive, but I can email them directly to you if you like.
1/ Contouring (and also Brep/Plane Intersection) generates non-closed curves from a closed brep (the screenshot actually shows a surface instead of a brep, but the same thing happens):
2/ Contour generates non-planar curves (one is also open, see below). This is very disturbing because it cannot be used to create a 'boundary surface'.
3/ Offset doesn't return all results. This seems like more of a rhinocommon problem. It always returns a valid result, but often not the one I want. Better would be to return all results and let me choose what I want.
4/ Fillet issues. See image below, the fillet component works fine up to a certain radius and then the one on the right disappears completely (presumably the radius is too large so it gives up). However, if I use the FilletAtParameter component, the fillet works at each of these points but it won't do all of the fillets at once (regardless of how I arrange the data tree). My work around at this point is to get it to fillet each of the sharp bits separately and then RegionUnion all the curves together, which is incredibly slow.
5/ There is no ExtrudeTapered component, so I wrote a quick VB.Net component to expose this functionality. Firstly: I cannot for the life of me figure out what the "Base Point" input does. This seems to have no impact on the result and the documentation is missing. Secondly: giving it a non-unitized vector does very strange things to the result.
Thank you for your help!
Steven
…
or Ladybug and Honeybee:
1. Our recent presentation at IBPSA-NYC is now available online. We do an overview of what Ladybug and Honeybee capabilities with a short live demo:
part 1: https://vimeo.com/107501953 - part 2: https://vimeo.com/107502226
2. Chris recorded a great set of tutorials together for "Getting Started with Ladybug" that walks you through several components in Ladybug: (https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDXNep1O)
3. He (Chris) also recorded another great set of videos for comfort tools that he is currently developing for Ladybug and Honeybee: (https://www.youtube.com/playlist?list=PLruLh1AdY-Sho45_D4BV1HKcIz7oVmZ8v)
4. With the help of Mohammad, we finally uploaded the videos from the workshop that I led at Penn few months ago which covers Daylighting with Honeybee: (https://www.youtube.com/playlist?list=PLkjfDmSc5OryXkWSt57ltJFU4qXD5ss1v)
5. Finally, Chris also started a series of videos on Energy Modeling with Honeybee that you can watch here: (https://www.youtube.com/playlist?list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_)
There are couple of stuff which are coming next, soon:
1. So Young is modifying the videos for the Ladybug workshop and once they are ready, we will upload them.
2. I will be capturing a number of videos for developers soon. We are so excited to see all the new developers joining the team and we understand the need to support you to get started. I hope these videos can help you to understand the development logic and get you started with the development.
OK. Now if you have access to Internet, which I supposed you do as you are reading this online, you have no excuse not to learn Ladybug and Honeybee. :)
Let us know your comments and suggestions.
Cheers, Mostapha…