been covered since 0051 (correct me if I'm wrong):
1) Shoot for the moon first -- "Control Panel Mode" which allows for advanced interface design. See Max/MSP for example of modal function. I spent a lot of time laying out control panels so they are nice for clients and team members to look at. I spend a lot of time disabling wire display and dragging sliders and panels and graphs around into nice little clusters. Could be something as simple as a mode that disables the view of all component handles, cleans up graph objects, sliders, etc. I know the Remote Control Panel has been requested over and over again since it disappeared, but honestly it wouldn't be much use to me unless it was a full blown customizable interface. In the meantime I'll stick to my own "Canvas Control Panel" methods. (See below...)
2) More control over graph objects. Right now the bar graph for instance automatically sets the lowest and highest value displayed. Would be nice to be able to set extents manually so that you can compare apples to apples on two different lists that have different extents. Also would love to force the bar graph to show all values along x axis, not just first and last. Same goes for showing the numbers of instances for each value. Now it only shows instance numbers in oddball cases. Would like to force them to show for statistical purposes. Love percentages, but usually I also want accurate tallies. I tend to use a member index sets to generate my own lists.
3) Color input for Vectors -- there are fakey fake workarounds but none that are as versatile as simply having a color input.
4) COLOR INPUT FOR TEXT TAGS -- sorry to yell... this one really frustrates me. I often build interactive feedback systems that involve a lot of different types of data, and it is difficult to convey that input when all text is red (or green when selected).
5) Ability to justify text tags using paragraph controls -- currently default is left-justified. Would like to be able to center text horizontally and vertically, among other things.
6) Ability for text tags to handle multi-line text. Not sure the best way to implement this, but often I find myself wanting to attach 3 items of information to a particular object, and I have to string it all together in one line. Would be great if I could insert a "^M" character that stands for carriage return and have that display as multiline text (used in conjunction with above justification controls).
7) More control over Text panels. Thank you for including justification options... but sadly now it begs the question for margin and header control. Text slammed up against the left edge is pretty unsightly. Moreover, if you have labeled a text box, the drop shadow from the title bar tends to overshadow the first line of text if you have Path display turned off. Would like to add some header space to fix the problem and create a cleaner look.
8) Easier access to text font size. Buried in a Special Font... menu. I want to be able to up up down down (left right left right select start) if you know what I mean.
I guess that's it for now... just the things on the top of my head in this category. Looking forward to installing the new release, have to wait until this major project is over though.
Cheers,
Marc
…
e's a ton of things that can be done with GH. If the desire to do 1000 different things is there, then its hard to not have that be expressed as 1000 different components. I think this is part of the learning process of GH.
On the other hand, I believe that there are opportunities for component consolidation. For instance, there's a curve frame component that takes a curve parameter, and a curve frame component that takes an integer for multiple curve frames. There doesn't need to be two different components for this, but their are. The trade off is that if you want to do multiple curve frames with the single curve frame component you have to add a few more components to get it done. So its the question of the extra real estate of an icon versus a few more components on the canvas and a few extra steps to get the same thing done. For beginners, I think having the extra icon is more useful, and although I expect advanced users could deal with it either way, having a definition that's less crowded and cluttered would be considered a positive.
The other opportunity for component consolidation (because I doubt any components will just be tossed) would be to make certain operations, such as creating a circle, articulate itself as one component which can change its format as opposed to individual components of the several operations that can create that object. So keeping with the circle example, the standard circle component, circle 3 pt, cen nrml rad, and possibly the InCircle component would all be one uber circle component, and you'd have to select the type or method of circle creation within the component, probably by right-clicking. I'm not sure this is a good thing for new users either as it hides functionality just as much, if not more, than having an icon for each operation. Yes, it would save screen space, but at what cost.
So as I see it, its a push as to whether saving the screen space of the icons is actually worth it. There are opportunities for saving space, but at a cost that may not be worth price being paid. A lot may hinge on the changes made to the interface.…
Added by Damien Alomar at 7:48am on December 30, 2009
ode, I get the start points and end points of lines, in the output list there are duplicates of points and I don't know why. For example if I input 3 lines, instead of 6 points as the output, it gives me 17 points. How can I solve this problem?
Protected Overrides Sub RegisterInputParams(ByVal pManager As GH_Component.GH_InputParamManager)
pManager.Register_LineParam("Line", "L", "my lines")
End Sub
-----------------------
Protected Overrides Sub RegisterOutputParams(ByVal pManager As GH_Component.GH_OutputParamManager) pManager.Register_PointParam("point", "sp", "my points")
End Sub
----------------------
Protected Overrides Sub SolveInstance(ByVal DA As IGH_DataAccess)
Dim Edge As Rhino.Geometry.Line = Rhino.Geometry.Line.Unset If (Not DA.GetData(0, Edge)) Then Return
StartPointList.Add(Edge.From)
EndPointList.Add(Edge.To)
DA.SetDataList(0, StartPointList)
DA.SetDataList(0, EndPointList)
End Sub
-------------------------
In this case to pass a list I used DA.SetDatalist and also I tried this :
For i = 0 To StartPointList.Count - 1
DA.SetData(0, StartPointList.Item(i))
Next i
For i = 0 To EndPointList.Count - 1
DA.SetData(0, EndPointList.Item(i))
Next i
in this case, it gives me just End points!!! of course without any duplication of points.
I really appreciate your help!
Nick…
hich are integers between 0 and 255 each) to XYZ which could be any floating point values, is as follows:
Dim factor As Double = 1.0 / 127.5 x = (colour.R * factor) - 1.0 y = (colour.G * factor) - 1.0 z = (colour.B * factor) - 1.0
So if a colour channel has the lowest value of 0, the corresponding coordinate will be -1.0. If the channel has the highest value of 255, the coordinate will be +1.0. In the case of [255,161,161] it does:
Dim factor As Double = 1.0 / 127.5x = (255 * factor) - 1.0 which equals 1.0y = (161 * factor) - 1.0 which equals 0.262745 (rounded to 6 decimal places)z = (161 * factor) - 1.0 which equals 0.262745
So the length of the vector with these xyz coordinates is:
SquareRoot of (1.0² + 0.262745² + 0.262745²) which equals 1.066803 (rounded again)
It also follows the largest possible length of a vector created this way is the Square root of 3, which roughly equals 1.732050
This conversion works both ways incidentally, so as long as you convert unitized vectors into colours you'll always get a non-clipped result.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
…
o tutorial.
¿Por qué esta diferencia entre el componente "meshgraph desenróllese", y el mismo que puedo ver en el tutorial en VIMEO?
La misma diferencia que encuentro con otros componentes.
Es que una versión antigua de hiedra, .... o hay otro?, Que se utiliza en los tutoriales? Gracias
Hace falta que el plugin comprar?…
Added by Cfeldman to Ivy at 10:04am on September 17, 2017
Vertices.Count * 3]; int[] facesizes = new int[m.Ngons.Count]; List<int> faces = new List<int>();
int j = 0; for (int i = 0; i < m.Vertices.Count; ++i) { verts[j] = m.Vertices[i].X; ++j; verts[j] = m.Vertices[i].Y; ++j; verts[j] = m.Vertices[i].Z; ++j; } for (int i = 0; i < m.Ngons.Count; ++i) { MeshNgon mngon = m.Ngons.GetNgon(i); facesizes[i] = mngon.BoundaryVertexCount; for (int j = 0; j < mngon.BoundaryVertexCount; ++j) { faces.Add(mngon[j]); } }
CarveSharp.CarveMesh cm = new CarveSharp.CarveMesh(); cm.Vertices = verts; cm.FaceIndices = faces.ToArray(); cm.FaceSizes = facesizes;
return cm; }
Going the other way should be similar, though I don't know if you need to define Mesh faces and then N-gons, or if you can just define N-gons right away and it'll take care of the Faces list for you... Haven't tried the Rhino 6 API... Not sure if you can just use the index operator on MeshNgon directly or you have to go mngon.Item[i] or whatever.
And then instead of
Rhino.Geometry.Mesh res = CarveRC.CarveOps.PerformCSG(...)
do
CarveSharp.CarveMesh res = CarveSharp.PerformCSG(CarveMeshA, CarveMeshB, CarveSharp.CSGOperations.Union);
Mesh m = res.ToRhinoMesh();
or your own CarveMesh-to-RhinoMesh function which preserves N-gons.
…
Added by Tom Svilans at 8:45am on September 25, 2017
ncluding an error) but the method did not lend itself to many similar shapes, especially those that are not surfaces of revolution.
Here is a technique using Anemone that finds a solution by climbing up a path determined by a teensy-weensy semi-cone. These are the steps:
1) Define a small semi-cone having the desired slope.(base radius/height) The smaller the better but it does begin eating up computing power.
2) Place the cone at the start point and find the intersection with the surface. Since the cone is small, the curve of intersection is almost linear and at nearly the same slope as the cone. Move the cone to the end of the intersection curve, reorient it based on the surface normal at that point, rinse and repeat.
3) Continue until the intersection event gives a null. The loop outputs the end points of each little intersection curve, so at the end, the list is flattened and they are interpolated into a spiral.
In the code I included a calculation for the percentage difference between the min and max slopes calculated, using a neat technique by David Rutten and the results go from a few hundredths of a percent for a pretty smooth surface to 4 to 6 percent for something more topographical. YMMV.
Assuming your machine is as slow as mine, it's cool to watch the path climb up and around the surface - if it's not, you don't know what you're missing! but to speed things up, check ''Output After Last' in the Anemone End Loop.
…
, 2013)
The most popular year was 2008 (5 responses)
Note: According to Wikipedia: "The first version of Grasshopper, called Explicit History at the time, was originally publicly released in September 2007." Interesting coincidence.
The response to question #2 by those that began before 2007 (How long did it take for you to feel comfortable with designing computationally?):
- Years
- Don't remember, but it felt like a natural way to relate to cad.
- After a few projects
- A month.
Compared to some of the responses of those that began since 2007:
- A month
- A few months
- After 6 weeks
- About 8 weeks
- Within my second design project with GH
- five to six months
- after 1 years of self learning + over 2 years of multiple projects and continuous self learning = Computation skill is comfortable but Computational Design can not be comfortable, Crazy learning curve.
There is much diversity, but some patterns begin to emerge.
Looking forward to more responses!…
o it would cause troubles with unfolding and fabricating... that's why I used Extrude point component- it will give you similar result, but all surfaces are planar.. you can control extrusion direction with a tip point in rhino...
2)I changed tagging so every tube has 8 points form list A and 8 points from list B... first number of tag is a number of point within one tube... last number of the tag is order of tubes (I draw a little picture in GH, hope you'll understand)...I think original way of tagging wasn't really usefull.. but you can change tagging by yourself...
3) the definition is really messy, sorry about that, but it's just quite complicated task...
4)if you find some incorrect order of tagging, use the slider that controls Shift List component ... it will shift tagging..
5) if you won't be using this definition or find some better way, pleeeease don't tell me - I'll jump out the window :D ... it took me whole day to make it work :D
6)I can't guarantee you anything- I hope it works, but if not - at least I tried... so check everything (especially order of tags and points) twice before you fabricate it.. or print few tubes and make them paper first..
7)there is a part of original definition, that is not useful anymore.. I left it there, but you can delete it (I called it "UNUSED PARTS OF ORIGINAL FILE")
..good luck
Dimitri…
On the other hand ... well ... we can pretend that this could be some sort of add-on dedicated for broken pieces, (and nerves if loops = a big number) he he.
Anyway:
1. If you enable the history (the yellow things) you can watch the recursion working: get a donor box and "slice" it in 2 (either via an "orthogonal" plane [the fast boxes] or a random one [the slow breps]). Then get each one and repeat until the desired "depth" of "slices" is achieved (the loops, that is). Pure recursion in terms of programming (a function does something, yields results and then calls itself to further process each result).
Double click on the C# to see the code (but don't change anything). For the record this is the function that does the main job (spot the fact that if it's not terminated it calls itself [last line]):
2. The x, xy, xyz options restrict the random plane (actually in the boxes case there's another technique used (Intervals) but never mind). For instance (case random breps) the slicing plane is defined at the brep center and using a random direction:
Vector3d dir = new Vector3d(rand.NextDouble(-1,1), rand.NextDouble(-1,1), rand.NextDouble(-1,1));
If the 3rd value is 0 then the plane's YAxis is parallel to Plane.WorldXY.ZAxis.
3. Now if the "slicing" thing was a random polyline at a random plane the pieces could be far more "elaborated" (and/or "naturally looking") ... but the thing with programming is to know(?) where/when to stop.
4. This approach could use any donor Brep (a blob for instance) or a Brep List. Notify if you want to add such an option.
5. Added some lines more for an option that allows to sample the pieces (due to the last loop) in an automated flat "layout" (it's a bit more complex than it appears on first sight).
6. The x,y restriction mode now affects the random slices as well. See what I mean:
and the same restriction using boxes:
Truth is that all that freaky stuff could be helpful for you if you had serious plans to learn C# (not something achievable without pain and tears aplenty).
best…