h tubes are redundant so surfaces overlap instead of interpenetrate, so it is not a good system.
Cocoon is the best answer these days unless you can get Exowire/Exoskelton to work. If you want more control over shape, feed your uncapped tubes into Cocoon as meta-surfaces and delete any and all of the inner meshes to just keep the outer single closed one, but this is just duplicate-culled lines used as meta-lines:
Turn down the CS input to 0.005 for this result, from 0.02 used for faster preview. In fact bake the lines and only test Cocoon on a few of them in order to get the result you want before doing the whole thing.
Whole thing at 0.005 cell size takes 5 minutes for Cocoon and 2 minutes for refinement to a smooth and even mesh.
Actually, seems like 0.005 is way too fine, giving a 600MB STL file.
So, 0.01 cell size at less than a minute total:
159MB STL which is still a bit too big for places like Shapeways. Wow. OK then 0.02 cell size, but I have to increase diameter or my two smoothing steps in refine collapse things too much, an in fact I set it to no smoothing, getting more volume and a reasonable 46MB STL file:
Alas, now it's more frail and overly organic rather than mechanical. Increasing diameter just merges it into perforated plates too much. File size is simply an issue with this complexity level, so different 3D printing services will have different file size limits.
Exowire/Exoskeleton would work but your original mesh hasn't been MeshMachine remeshed to be regular, so short segments ruin it. Here is just a corner:
I think that's why more wires fails, at least. Pretty temperamental component.
Switching to MeshMachine is needed, I guess, instead of Cocoon refine, to remesh away so many small triangles along the boring tubes. Crucial for good remeshing was to set Flip to 0 or I failed to get a rough enough mesh.
It's an adaptive mesh so I can retain good detail while roughing out the tubes.
MeshMachine is terribly slow for this whole thing, like 6 minutes, and blows up for this overly rough setting, 20 steps, so less rough, ugh, I'm out of time. I think free Autocad Meshmixer is the way to make a better smaller mesh, after a refined output from Cocoon. MeshMachine is just too slow to tweak and when it blows up, creating massive triangles jutting out, it hangs too when you change settings.
Starting with a Cocoon refined mesh certainly helped Meshmixer. Using triangle budget lets me have full control. Here is 150K triangles instead of 200K:
STL file size down to 40MB. I think Shapeways is 70 or 100MB limit? So it can be even finer. Here is the Cocoon output versus the Meshmixer reduction:
To use Meshmixer, turn on View > Show Wireframe, Command-S to select all and use Edit > Reduce from the palette that appears.
Cocoon can end up making a few inner meshes where things get weird in your uneven original mesh with small holes so fish out the main mesh by adding a List Item node.
The best strategy for Cocoon is indeed to make an overly fine STL so you avoid any need to tweak forever in Grasshopper, but then you can achieve a smaller mesh file size while preserving shape instead of things turning all smearly organic in Grasshopper.…
.
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
…
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
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
peuvent se diviser une surface avec ne importe quel motif imaginable. 3. Ici, je fournir un moyen de le faire via Lunchbox ... cela fonctionne mais il est fixe et donc nous avons besoin de jouer avec des arbres de données afin de créer le motif approprié par cas. 4. L'autre composante est un joint C # qui fait beaucoup de choses autres que de diviser ne importe quelle collection de points avec de nombreux modèles (voir le modèle ANDRE que je ai fait pour vous). 5. Vous devez décomposer une polysurface en morceaux afin de travailler sur les subdivisions. 6. Je donne une autre définition ainsi que pourrait agir comme un tutoriel sur la façon de traiter des ensembles de points via des composants de GH standards et des méthodes classiques.
Avertissez si tous ceux-ci apparaissent floue pour vous: Si oui, je pourrais écrire une définition utilisant des composants de GH classiques - mais vous perdrez les variations de motifs de division.
mieux, Peter
…
olves some changes to the Rhino SDK, so it's likely that there will be problems running 0.8.0008 under Rhino5 until the next Rhino5 WIP goes out.
Changes since 0.8.0007:
● Added a Mesh|Mesh intersection component.
● Added a Mesh|Curve intersection component.
● Added a Replace List component (Sets.List dropdown)
● Added Integer Division component (Math.Operator dropdown)
● Added ToRadians component (Math.Trig dropdown)
● Added ToDegrees component (Math.Trig dropdown)
● Added Cube component (Math.Polynomials dropdown)
● Added CubeRoot component (Math.Polynomials dropdown)
● Added Round component which exposes Round, Ceiling and Floor functions (Math.Util dropdown)
● Added Negative component (Math.Operators dropdown)
● Added Absolute component (Math.Operators dropdown)
● Added 'One over X' component (Math.Polynomials dropdown)
● Updated to Quantum Whale code editor version 1.62
● Added String Sort component (Sets.Strings dropdown)
● Added Create Set component (Sets.Sets panel)
● Added Set Union component (Sets.Sets panel)
● Added Set Difference component (Sets.Sets panel)
● Added Set Symmetric Difference component (Sets.Sets dropdown)
● Added Set Intersection component (Sets.Sets panel)
● Added Set Carthesian Product component (Sets.Sets panel)
● Added SubSet test component (Sets.Sets panel)
● Added Disjoint Set test component (Sets.Sets dropdown)
● Added Set Majority component (Sets.Sets dropdown)
● Added Set Member Index component (Sets.Sets dropdown)
● Added Set Replace Member component (Sets.Sets dropdown)
● Added Set Remove Consecutive Identical Members component (Sets.Sets dropdown)
● Added Mass Multiplication component (Math.Operators dropdown)
● Simplify Tree component now by default collapses *all* coincident path elements.
● Casting error messages are now vaguely less geeky.
● Added polygon center component (Curve.Analysis dropdown).
● Font Defaults are now copied from the OS Fonts.
● Slider Initialization codes can now be used to specify decimal places.
● Profiler widget now displays long time spans in seconds, minutes and hours.
● Added an IsoVist component (Intersect.Mathematical panel)
● Added an IsoVist Ray component (Intersect.Mathematical panel)
● MRU missing file checks are now threaded to prevent UI delays when files are located on slow media.
● Expression Editor has been redesigned.
● Slider Component popup has been redesigned.
● Slider Components now have customizable grip-styles (accessible via popup only)
● Slider Components are now 20 pixels wider by default than before.
● Slider Controls now draw focus rectangle to indicate caret capture.
● Slider Control text input is now automatically activated by a keypress when the slider has focus.
● Slider Controls that are locked are now rendered greyed out.
● Tumbler Controls now draw themselves in 3D style when they are focused.
● Tumbler Control text input is now automatically activated by a keypress when the slider has focus.
● Tumbler Controls that are locked are now rendered greyed out.
● Generic Data parameters now allow setting multiple items via the menu.
● Text display has been rewritten for Text Panels and Param Viewers, making it faster.
● Null items in Text Panels are now drawn transparently.
● Empty strings in Text Panels are now drawn transparently as "<empty>".
● Path mapping operations that do not involve List Indices are faster.
○ Point Parameters could not be baked from the toolbar, this is fixed.
○ Negative slider initialization codes would result in erroneous limits, this is fixed.
○ Fixed a bug with the normal vector output of the Spherical Cloud component.
○ ASCII control code characters in strings prevented ghx serialization, this is fixed.
○ Fixed several bugs with ReadFile component custom parser scripts.
○ Fixed a bug (without introducing other ones I hope) with screwed up output data trees in case of partial path overlaps.
○ Empty branches would get skipped by the PathMapper, this is fixed.
○ Transform multiplication was the wrong way 'round, this is fixed.
○ There was (at least one) bug in the Curve Offset direction code, it got fixed.
○ Fixed a bug with the Convex Hull algorithm (while inebriated on Tokaj no less).
Important notes:
The zero-length-slider-ultra-crash may or may not still happen. I've fixed a bug in slider code that may or may not explain why it happened to begin with (though probably it doesn't) and also some safety code. Please let me know if this is still a problem.
All the Set components operate on simple data types only (Booleans, Integers, Numbers, Complex Numbers, Strings, Intervals, Vectors & Points). They will not work correctly on more complex types such as Curves, Meshes or Breps. I do not know if they ever will.
I've tried making the sliders and tumblers (the controls, not the canvas objects) easier to use. Basically it should now be obvious based on the display whether a slider or tumbler has focus. Slider have a dotted rectangle drawn in them when focused, tumblers are drawn as 3D objects instead of flat objects). When a slider or tumbler has focus, just typing should automatically bring up the text input override. Please test that this works as advertised and is not 'weird'.
Note to GHA developers: The Internal_Icon_24x24 property on Components and Custom object is now Obsolete. It still exists for the time being, but you are advised to use the Icon property instead.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…