What is it?Bumblebee is a set of user objects which connect Microsoft Excel and Grasshopper.
The current component set allows for not just the transfer of data back and forth between GH and XL but giv
rsistant data , as the inputs and outputs of the component should be build by the data stored in the object.
thanxs in advance
Michael
here is the code of the object....
public class Proxy { public List<string> _name_in; public List<string> _name_out; public List<SerializableType> _type_in; public List<SerializableType> _type_out; public List<GH_ParamAccess> _access_in; public string _path; public string _script; public bool _internalized; public bool _working; public Proxy(List<string> name_in, List<string> name_out, List<SerializableType> type_in, List<SerializableType> type_out, List<GH_ParamAccess> access_in, string path, string script, bool internalized) { _name_in = name_in; _name_out = name_out; _type_in = type_in; _type_out = type_out; _access_in = access_in; _path = path; _script = script; _internalized = internalized; _working = true; } public Proxy() { _name_in = new List<string>(); _name_out = new List<string>(); _type_in = new List<SerializableType>(); _type_out = new List<SerializableType>(); _access_in = new List<GH_ParamAccess>(); _path = get_path_of_plugin(); _script = ""; _internalized = false; _working = false; } public static string get_path_of_plugin() { string temp_cut; string string_path = System.Reflection.Assembly.GetExecutingAssembly().Location; string string_name = System.Reflection.Assembly.GetExecutingAssembly().GetName().Name; int temp_name_int = string_name.Length + 5; int temp_path_int = string_path.Length; temp_cut = string_path.Remove(temp_path_int - temp_name_int); return temp_cut; } public static T ObjectDeserializer<T>(string XmlInput) { System.Xml.XmlDocument XmlDoc = new System.Xml.XmlDocument(); XmlDoc.Load(new System.IO.StringReader(XmlInput)); System.Xml.Serialization.XmlSerializer ser = new System.Xml.Serialization.XmlSerializer(typeof(T)); T out_ob = (T)ser.Deserialize(new System.IO.StringReader(XmlInput)); return out_ob; } public static string ObjectSerializer<T>(T SerializedObject) { System.Xml.Serialization.XmlSerializer ser = new System.Xml.Serialization.XmlSerializer(typeof(T)); System.Text.StringBuilder builder = new System.Text.StringBuilder(); XmlWriter xmllol = XmlWriter.Create(builder); ser.Serialize(xmllol, SerializedObject); return builder.ToString(); } } public class SerializableType { private Type type; // when serializing, store as a string // [DataMember] public string TypeString { get { if (type == null) return null; return type.FullName; } set { if (value == null) type = null; else { type = Type.GetType(value); } } } public Type return_Type() { return type; } // constructors public SerializableType() { type = null; } public SerializableType(Type t) { type = t; } // allow SerializableType to implicitly be converted to and from System.Type static public implicit operator Type(SerializableType stype) { return stype.type; } static public implicit operator SerializableType(Type t) { return new SerializableType(t); } // overload the == and != operators public static bool operator ==(SerializableType a, SerializableType b) { // If both are null, or both are same instance, return true. if (System.Object.ReferenceEquals(a, b)) { return true; } // If one is null, but not both, return false. if (((object)a == null) || ((object)b == null)) { return false; } // Return true if the fields match: return a.type == b.type; } public static bool operator !=(SerializableType a, SerializableType b) { return !(a == b); } // we don't need to overload operators between SerializableType and System.Type because we already enabled them to implicitly convert public override int GetHashCode() { return type.GetHashCode(); } // overload the .Equals method public override bool Equals(System.Object obj) { // If parameter is null return false. if (obj == null) { return false; } // If parameter cannot be cast to SerializableType return false. SerializableType p = obj as SerializableType; if ((System.Object)p == null) { return false; } // Return true if the fields match: return (type == p.type); } public bool Equals(SerializableType p) { // If parameter is null return false: if ((object)p == null) { return false; } // Return true if the fields match: return (type == p.type); } } public class GH_Proxy : Grasshopper.Kernel.Types.GH_Goo<Proxy> { public override Grasshopper.Kernel.Types.IGH_Goo Duplicate() { return this; } public override bool IsValid { get { return true; } } public override string ToString() { return Proxy.ObjectSerializer<Proxy>(this.Value); } public override string TypeDescription { get { return "his is a proxy"; } } public override string TypeName { get { return "his is a proxy"; } } }…
ome work to create a ZScript macro for custom routines, but you can record those in ZBrush and then merely need to edit them into my script, inline, as bulk multiple-lines you just paste in, no problem as long as you strip the ZBrush button definition at the beginning.
ZBrush has a very high initial learning curve because of its non-standard interface. However, it has the world's most powerful quad remeshing and now mesh Booleans too. I needed a replacement for slow and especially non-robust marching cubes (Cocoon/Monolith/Dodo/Aether etc. on Grasshopper) that tended to bog down or blow up. IntraLattice was a step in a good direction but it can't merge fattened lines that merely cross each other with no breaks or that physically overlap on purpose to have many curve on in to a hub. But with $800 ZBrush 4R8, the latest version, that I can create English language ZScripts for, I suddenly have, often in the blink of an eye, or at worst a few seconds, right back into Rhino Grasshopper, a perfectly joined, airtight and smoothed mesh blending of upwards of thousands of input mesh pieces that overlap in ways Rhino will never Boolean union.
There is no complicated installation of anything since it's all done in Python.
The ZBrush program itself pops up while it works, and is then automatically backgrounded to bring you back to Grasshopper. It keeps running though, for fast iterations with no program startup time.
This is a general toolkit to expose myriad very advanced features of ZBrush into being just another Grasshopper plug-in like the rest.
It works by accepting a Grasshopper mesh and writing it to disk as an OBJ file, then incorporates ZBrush settings for a given command into a text format ZScript file, also written to disk from Python based on Grasshopper inputs, then ZBrush is told to run the script via Windows command line, and the exported OBJ output is read back from disk back into a Rhino Grasshopper mesh, in about a hundred lines of code.
Despite a change in mesh definition in Rhinocommon from version 5 to 6, I made it work on both versions.
So far this is only one command, the newly improved mesh Boolean union. It gives quad meshes, but they still look healthy when quickly triangulated in Rhino (as seen on top, above).
The ZBrush ZRemesher is utterly astounding in ability to transform any mesh into a direction following, error free quad mesh that can be converted to NURBS actually, via T-Splines smooth mode. That will be the next port to Grasshopper. I hope architects pick up on this more orderly manner of patterning surfaces than the alien slime of random point Voronoi.
Commercial software has the best code, not open source stuff, so far, so this is serious work to bring world class tools into Grasshopper where we can rapidly prototype computational strategies.
Here is a thread with several examples of ZBrush Boolean union remeshing applied to 3D trusses, compared to both IntraLattice and marching cubes:
http://www.grasshopper3d.com/forum/topics/custom-unit-cell-bug-in-intralattice-plug-in?commentId=2985220%3AComment%3A1828609
The same strategy of generating script files I used to port OpenFlipper, here, for triangle remeshing, which can now be combined with ZBrush Boolean unions of arbitrary assemblies of mesh units:
http://www.grasshopper3d.com/forum/topics/best-uniform-remesher-for-patterning-organic-suraces
UPDATE: I revamped the workflow so now components feed raw ZScript into a sequencer. Then only a single ZScript is assembled and sent to ZBrush so Python never gets ahead of ZBrush (!):
It is easy to DIY roll your own now:
…
Added by Nik Willmore at 6:48am on October 12, 2017
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
ere I'm using a GH_ObjectWrapper type. This may not be the best way about doing this, but it does work.
localSettings of type EM_Settings is the data that gets wrapped and then added to the Parameter.
Whilst everything works fine first time around, when I re-open the GH file the persistent data is lost. I need to serialize the data in some way in order to write it to a GH file and I'm not entirely sure how to do this.... I've tried for quite a while now, looking through the forum & SDK which offer clues but no joy... so I'm admitting defeat and running here!!!
Here are some of the CS bits:
public class MyComponent : GH_Component { ......... private EM_SettingsParam myParam;
private EM_Settings localSettings;
private EM_Settings mySettings;
protected override void RegisterInputParams(GH_Component.GH_InputParamManager pm) {
... myParam = new EM_SettingsParam(); EM_Settings localSettings = new EM_Settings(); myParam.PersistentData.Append(new GH_ObjectWrapper(localSettings)); pm.AddParameter(myParam, "Settings", "Se", "MySettings", GH_ParamAccess.item); }
protected override void SolveInstance(IGH_DataAccess DA) { GH_ObjectWrapper temp = new GH_ObjectWrapper(); if (!DA.GetData(5, ref temp)){ return; } mySettings = (EM_Settings)temp.Value;
...
} } public class EM_SettingsParam : GH_PersistentParam<GH_ObjectWrapper> { public EM_SettingsParam(): base(new GH_InstanceDescription("Settings", "Settings", "Represents a collection of Settings", "Params", "Primitive")) { } ...blah singular blah plural blah exposure.hidden blah... } public class EM_Settings { public bool Preview {get; set;} // (more parameters here) public EM_Settings() { Preview = true; }
}
Any help much appreciated $:)
John.…
URBS cup surface, and boy oh boy did it ever work more uniformly than using 3D orb cutters on a 3D cup. Different sized spheres return the *same* hex grid only less and less raised up as the spheres get very large.
My first question is whether these are different in character or just in Z scaling, so if I rescale them all to the same Z thickness, after extracting only the relief structure via Boolean union and splitting...and they are only *slightly* different in character, which means mere Z re-scaling of a single moderate ball size relief is an appropriate cheat to avoid slow Boolean union re-making each relief Z scale with different sized balls.
The one on the right is a very shallow relief scaled up to the same Z thickness as the pure sphere one on the left. And really, we will be mostly scaling *down* from a thicker master surface so that will attenuate any weirdness in the curvature. Indeed, I see no difference, so it makes sense to only archive the thickest one so we can control the full range of thicknesses, all the way to nearly flat bulbs. Here is the thickest one, just before the balls lose holes between them, scaled down compared to a shallow one made with huge balls to start with:
Now we just use Rhino Flow Along Surface or the Grasshopper Jackalope plug-in Sporf to morph this flat system onto our lathe form.
With Rhino history for the Flow Along Surface step I can rescale the original in Z and wait twenty seconds to see the update:
There are sad edge artifacts that will require some strategy to retain or later delete a whole row:
Maybe add more geometry to later delete or make a solid to hold stuff together?
So vastly decreasing the cell count and changing grid direction to match your cup:
The edges came out fine on this one, happily. The isocurve count has been increased by the Flow Along Surface command:
It can't be filleted yet since the joint where the cup NURBS surface has a joint now leaves feathery edges, so I went back and duplicated the border of the flat array, offset and lofted to make a protecting surface:
But that gave crazy artifacts:
I'm just going to use symmetry to fill in the joint with good faces that are not having to be joined as two halves. I had to turn my Rhino units tolerance down from a silly 0.0001 to 0.01 units to get a good re-join, but it still won't fillet without leaving holes.
SO LET'S FILLET THE FLAT THING. Same problem but a bit faster, and actually repairable manually. Rhino 5 is buggy as hell with core commands, damn it. This is not world class behavior.
Let's try it in Rhino 6 WIP, our great hope of the future: nope, the same. I had to simply manually copy the missing pieces from where it did work, which at least is easy to do in flatland. Now I get a cup:
This can *all* be done quickly in Rhino without Grasshopper, and Rhino affords you fast cage editing of the original flat array that Grasshopper cannot yet do. You just need to use Analyze Direction to be able to swap UV directions of the source or target and flip the source surface to achieve concave vs. convex patterns.
Grasshopper doesn't even have a fillet (multiple) edges component so there's not a lot of advantage to having some super slow parametric system via Grasshopper. It's not like you'll be able to see the changes fast enough to tweak a design.…
/www.grasshopper3d.com/forum/topics/vb-vs-c-vs-python
http://www.grasshopper3d.com/forum/topics/which-programming-language-should-i-focus-on-vb-or-python
VB.Net and C#
VB.Net and C# both belong to the ".Net" family of languages, and the things you can do with them in Rhino/Grasshopper are nearly 100% equivalent. Grasshopper itself was written in a combination of VB.Net and C#. Some advantages/comments, in no particular order:
Performance - VB.Net and C# scripts tend to execute faster because they are "Just-in-time" compiled as opposed to interpreted.
Autocomplete - both VB.Net and C# have rich autocomplete functionality in their respective script editor components - significantly more so than the python editor. This can be helpful for beginners since you can "hunt" for methods and properties by just typing a "." after an object name and looking at the list of available methods/properties.
Native Component development - If you eventually want to develop GHA assemblies/plug-ins for grasshopper, as of Rhino 5 you will have to use one of these two languages. However, there are plans to introduce python-based plugins in Rhino 6. Even so, the resources around plug-in development are very rich in the C# and VB.Net environments (with c# seeming to be the more popular of the two).
"Strong Typing" - VB.net to some degree, and C# especially, are less "forgiving" languages than python - they require you to know about the data type of the objects you're operating on. This can sometimes result in more verbose code - as you explicitly convert from type to type - but it also promotes good programming practice and helps make errors more understandable.
.Net ecosystem - using a .Net language means you have access to the thousands of libraries publicly available, and the process of referencing these libraries and making use of them is comparatively straightforward relative to python. More on this in the following section.
Resources/Support - At least as of 2012, VB and C# turned up more results on this forum than python, and I think you'll find slightly more expert-level coders in those languages able to help you here.
Which one between the two? C# or VB.Net? - Personally, I greatly prefer C# - I find it to be cleaner and clearer to use. I also have some programming background in C++/Java/Processing so I found the "C family" approach to be more familiar. As David and Damian point out in some of the posts linked above, C# is more popular than either python or VB.net in the rest of the coding world. However, if you are learning without any prior programming experience you may find VB.net to be a bit easier to learn.
Python
Python is, without a doubt, a beautiful and elegant language, which is probably more than can be said for VB.Net/C#. It is very popular with beginner coders, and its syntax is more readily understandable.
Syntax - Python is beautiful to read and write. Its syntax is very clear and free of extraneous punctuation (for example the ";" line endings in c#). It has many very nice language features that make common tasks more concise, like its loop syntax, list comprehensions, list "map" and "filter."
Multiple ways to talk to Rhino/Grasshopper - Python enables two general approaches to interacting with the Rhino/Grasshopper environment: RhinoCommon and RhinoScriptSyntax. If you have prior experience with Rhinoscript, you may find RhinoScriptSyntax to be preferable - it adapts many of the methods you're familiar with to the python language, and simplifies some tasks. A word of caution though - working with Rhinoscriptsyntax can introduce a performance hit relative to RhinoCommon operations. C# and VB.net by contrast can only work with RhinoCommon.
"Goodies" - The Python environment in Grasshopper has some "special features" that the other languages lack. In particular, the "GHPythonLib" library enables the ability to call most Grasshopper components from within your code, and the ability to easily enable parallel processing to improve performance. (A word of caution though - these two features do not seem to "play well" with each other, there may be bugs causing memory leaks that result in increasingly worse performance with each execution).
Cross-Platform - Unlike C#/VB.net, Python can be used natively in Rhino for Windows and Rhino for Mac.
Direct scripting in Rhino - You can also use Python directly in the Rhino environment without the need for Grasshopper if you desire, using the Rhino Python editor.
IronPython / Ecosystem issues - one frustration / potential downside to working with Python for Rhino/GH is that though there is a vast, amazing ecosystem of external libraries for Python, getting these to install/work properly in the Rhino/GH environment can be a real pain - largely because the language is actually "IronPython," a version of python designed to work closely with the .Net ecosystem. Many popular libraries like numpy and scipy are very challenging to get working in Rhino/GH.
Scripting in other programs - Especially in the AEC industry, Python is a popular scripting language for other applications. Tools like Revit, Dynamo, Blender, and ArcGIS all offer their own Python scripting interface - so learning Python in Rhino/GH can give you a leg up in eventually scripting in these other programs.
Python's Stock is Rising - there are currently a number of efforts to improve the "status" of python within the Rhino/GH ecosystem. The python editor in Rhino 6 has a number of improvements, not least of which is the ability to "compile" add-ons for Grasshopper written in python. I'm sure Giulio can speak to other upcoming improvements.
I hope this summary helps you find the right option for you. Ultimately you can't go wrong; concepts from any of the available scripting languages will make it much easier to learn the next one. In my day to day work I use a combination of both C# and python, where appropriate, and I love them both.
I hope others will feel welcome to chime in on this FAQ and add their own thoughts about advantages/disadvantages of these various options! If you have time, read through some of the other posts linked to at the beginning - there's lots of additional great information there. …
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
ou will see a list of potential matches, sorted from most relevant to least relevant:
Some components and objects support initialisation codes, which means you can assign certain values directly from the popup box. You can do this by adding an equals symbol after the name and then the value you wish to assign. For example, the [Curve Offset] component allows you to specify the offset distance via the popup box by typing =5 after the offset command:
However the popup box also supports a set of special formats that allow you to create specific objects without even typing their names. As of 0.9.0077 (which hasn't been released yet at the time of writing) you can use the following shortcuts to create special objects. In the notation below optional parts of a format will be surrounded by square brackets and hashes (#) will be used to indicate numeric values. So #,#[,#] means;
at least two numeric values separated by a comma, with an optional second comma and third number.
A complete list of special formats (not all of these are supported yet in 0.9.0076):
"∙∙∙ If the format starts with a double quote, then the entire contents (minus any other double quotes) will be placed into a Text Panel.
//∙∙∙ If the format starts with two forward slashes, then the entire contents will be placed in a Text Panel.
~∙∙∙ If the format starts with a tilde, then the entire contents will be placed in a Scribble object.
#,#[,#] If the format contains two or three numerics separated by commas, a Point parameter will be created with the specified coordinates.
+[#] If the format starts with a plus symbol followed by a numeric, then an Addition component will be created.
-[#] If the format starts with a minus symbol followed by a numeric, then a Subtraction component will be created.
*[#] If the format starts with an asterisk symbol followed by a numeric, then a Multiplication component will be created.
/[#] If the format starts with a forward slash symbol followed by a numeric, then a Division component will be created.
\[#] If the format starts with a backward slash symbol followed by a numeric, then an Integer Division component will be created.
%[#] If the format starts with a percent symbol followed by a numeric, then a Modulus component will be created.
&[∙∙∙] If the format starts with an ampersand symbol, then a Concatenation component will be created.
=[∙∙∙] If the format starts with an equals symbol, then an Equality component will be created.
<[*] If the format starts with a smaller than symbol, then a Smaller Than component will be created.
>[*] If the format starts with a larger than symbol, then a Larger Than component will be created.
[# *] Pi If the format contains the text "Pi" with an optional multiplication factor, then a Pi component will be created.
# If the format can be evaluated as a single numeric value, then a Slider will be created with the specified initial value and sensible™ lower and upper limits.
#<# If the format contains two numerics separated by a smaller than symbol, a Slider with the specified limits will be created. The initial slider value will be equal to the lower limit.
#<#<# If the format contains three numerics separated by a smaller than symbol, a Slider with the specified limits will be created. The initial slider value will be the value in the middle.
#..# If the format contains two numerics separated by two or more consecutive dots, a Slider with the specified limits will be created. The initial slider value will be equal to the lower limit.
#..#..# If the format contains three numerics separated by two or more consecutive dots, a Slider with the specified limits will be created. The initial slider value will be the value in the middle.
#/#/[#] If the format contains two or three numerics separated by forward slashes, a Calendar object will be created. The order of value is day/month/year. If year is omitted then the current year is used. Note that a second slash is required because #/# is interpreted as a number and thus results in a Slider.
#:#[:#] [am/pm] If the format contains at least two numerics separated by a colon, a Clock object is created. Seconds are optional, as are am/pm suffixes.
f([...[,...[,...]]]) [= *]If the format starts with a lower case f followed by an opening bracket, an Expression component is created. A list of comma separated arguments can be provided as inputs, and anything after the optional equals symbol becomes the expression string.
Note that decimal places will be harvested from formats that indicate sliders. I.e. the format 0..2..10 is not the same as 0..2..10.00, as the former will create an integer slider from zero to ten whereas the latter will create a floating point slider with two decimal places from zero to ten.…
Added by David Rutten at 3:24pm on February 18, 2013
But not just any gum tree. The angophora, no less:
Why? Because I like nature, that's why. Every time I see new designs –especially architectural designs– it worries me that the natural environment is being taken over. Not just that, but even the new materials used in all product designs has to come from nature as well [read: mines].
So. People are forgetting that we still need trees and I believe that if someone sees a beautiful [read: established] tree in their architectural plans, they are going to be much more likely to build around it and not cut it down. That alone would no doubt increase the value of the house.
My thinking is that current tree models suck. They look unnatural and I think I know why. They're not random or organic enough. They're not detailed enough. That's basically my 'rationale' for this project. Just look at how different all of these tree trunks are!
So I am not being paid for this project. It's a personal project of mine. I'm just worried about the trunk shape for now — I'll worry about all the leaves... when I get to that.
I am a grasshopper beginner. Please keep that in mind. I am also fairly hopeless at traditional programming, but I find the visual approach of grasshopper much easier to grasp. So unfortunately I have gotten stuck and need some help, even just a clue, as to how to proceed.
That said, here is my current progress:
About a year ago, I started modelling with straight trunks using pipe sections, to see if I could get a very basic "tree" shape. And to see if I could join the segments together. Yes it works but it looks hopeless as you can imagine. Then I stopped for a long while. Now I'm back at it, hoping to improve a lot more.
I have already made one basic vertical nurbs curve with tangents at either end as the main "trunk".
I tried creating two ellipses at each end of the main trunk/curve and lofting between them but it omitted the main curve/rail. So it ended up being an elliptical trunk with straight sides which of course still didn't look right.
Then I divided the first main curve up into a number of segments. I think that is a better approach.
I have taken the parameters of the curve at each segment (probably the tangent, but I am unsure what the exact parameter is) and used that to form a basic angled plane at each segment/division.
I have been able to draw ellipses at each segment and rotate them onto the plane.
I was going to loft it together later on. A Curved loft with elliptical cross-sections looks much better than straight a pipe does, but still looks too unnatural.
I quickly realised that tree trunks are not elliptical, but rather, shaped more like 'kidneys'.
The next step was to create >3 points on each of those planes (spaced fairly evenly around the ellipse so as not to create a really funky/unwanted shape).
Maybe it would be better to model with a triangle or other polygon instead of an ellipse. I haven't got that far yet... because here is where I am getting stuck.
I managed to find a way of getting three roughly 'triangular' points along each that ellipse.
I also managed to create three nurbs cuves in the Z direction which intersected those three points, a bit like three seams down the side of the tree trunk, but couldn't figure out how to loft it all together.
I think it was the wrong approach anyway... I'd rather try to create a bunch of nurbs curves at each of the XY planes so as to get more control of the shape.
What I am trying to do now is create three roughly triangular-spaced points on a basic ellipse through which I can then draw a simple nurbs curve (think like a cross section of the trunk).
I would then like to add some XY-only randomness to the positions of those points. Not Z randomness, otherwise the trunk is going to get messed/kinked up. That's probably very important.
Then I would like to loft those nurbs curvs at each XY plane together forming the basic tree trunk, which also tapers based on some other variable (a non-linear factor, not simply distance from ground plane, perhaps something else?).
I have attached the GH file.
I am also open to suggestions if you have a better way of solving a problem. I would like to retain control over a lot of factor such as number of branches, spacing, average branch length, etc. My main contrsaints are that the entire thing has to be somewhat random and non-linear.
…