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
them can be addressed before winter.
Bugs:
. Vector preview is great, but it doesn't refresh (clear) when you disconnect components. You must delete the component or reconnect to refresh the vector previews.
. When passing values through a note pad, note pad fails to update continuously. Moving the notepad updates the display.
. Cannot pass a notepad integer into an fx1
. Point preview in RH5 appears as large red blocks, not as red crosses. (This is an old bug, may have been fixed with RH5 update in the meantime.)
. After adjusting Graph in dialog box, graph appears to be a solid grey object until moved.
. After copying and pasting, a lot of components are broken, return nulls. Requires reconnect to recompute (haven't had this problem in a while, will see if I can find a file that recreates it)
. BIG ONE: Loading a graph mapper with a file not found creates broken file... graph mapper disappears off canvas and the output wire appears turns orange and appears to be coming from the 0,0 pixel of the canvas. This happens any time you try to port a .ghx file to another system with different drive letters/paths, etc.
Wish list:
Mass addition for vectors
Interactive domain control for Image Sampler (like with Gradient Mapper)
Allow Addition Component to handle String values (A + B = AB)
BIG ONE: Request Override for Icon display for Parameters, Wireless receiver, and script components if you change the name
BIG ONE: Add new behavior for Stream Filter and Stream Gate: Allow multiple index numbers. The Index number picks the value/object in the corresponding index position in the selected list.
For instance:
List 0: A, B, C, D, E
List 1: 1, 2, 3, 4, 5
List 2: .1, .2, .3, .4, .5
Index Stream: 0, 2, 2, 1, 1, 2, 1, 0, 1
Results: A, .2, .3, 4, 5 (This is new behaviour and more useful than Weaving)
I have attached a GHX that includes VB components that do this, but it would be better to have GH components with I/O manager options and data matching behavior, etc.
Thanks,
Marc Syp
Knowlton School of Architecture
The Ohio State University
Columbus, OH…
curves A and B.
For each point pA on curve A,
you need the corresponding tangent vector tA on curve A, and the lists of "cone" vectors pB(j)-pA and tangent vectors tB(j) on curve B. so you have three vectors tA, tB(j) and AB(j)
these three vectors define a parallelogram thas varies along j
3d determinant of the three vectors above gives you the volume of this parallelogram. When 3dDet = 0 then it means it's flat, the vectors are coplanar. Thats what we're looking for.
So you just need to plot the curve 3Ddet = f(pB) , still for each point on A
'pB is the parameter here'
graphically solve these cuves to find the zeros and you feed back the resulting parameter in curve B. draw te line, done.
You can manage double solutions or cusps directly on the plot by using clostest point and >= conditions to kill unwanted results.
I do it twice, from crv A to crrv B and from B to A to make sure I catch start and end generatrices each time.
The videos you posted are interesting. I don't understand how it works with just 2 slider to tune the curves.
…
as passing this extra check and because of that it was running faster. It doesn't mean that the first analysis is totally wrong as it depends on the analysis case and should be checked and optimized before running the final analysis.
You can read more about radiance parameters here (http://radsite.lbl.gov/radiance/refer/Notes/rpict_options.html), and here (http://radiance-online.org/community/workshops/2011-berkeley-ca/pre...). Since you have a light-shelf I suggest you to add to the number of ambient bounces (ab).
Now back to your wish to have the analysis run faster you can comment the line hb_writeRADAUX.checkInputParametersForGridBasedAnalysis() inside Honeybee_runDaylightSimulation and it won't overwrite the initial values but make sure that you run a number of test cases and compare the results between the runs.
Back to your definition, it looks good to me. You could have saved yourself some time by using MassToZone component and then just adding the ceiling separately but there's nothing wrong with your approach.
The main place in the definition that can change is how you're generating the vertical fins. I imagine you can use a single set of components to generate every group of the fins but again your definition will work.
I updated your file to the latest version, which means you also need to update Honeybee and Ladybug in case you're looking to modify the file.
Hope it helps,
Mostapha…
ky.exe did not accept -p parameter and made empty sky.cal file.
----
Edit: solved run problem, Bee did not download OpenStudioMasterTemplate.idf
Get it here: https://github.com/mostaphaRoudsari/Honeybee/issues/119
Now get empty HDR:
C:\ladybug\prox\imageBasedSimulation>rpict -i -t 10 -vtv -vp 245.129 -226.458 20 0.405 -vd -0.549 0.656 -0.518 -vu -0.332 0.397 0.855 -vh 42.862 -vv 26.991 -v l 0 -vs 0 -vl 0 -x 800 -y 600 -af prox_RAD_Perspective.amb -ps 8 -pt 0.15 -pj 0.6 -dj 0 -ds 0.5 -dt 0.5 -dc 0.25 -dr 0 -dp 64 -st 0.85 -ab 2 -ad 1024 -as 175 -ar 150 -aa 0.200 -lr 4 -lw 0.050 -av 0 0 0 prox_RAD.oct 1>prox_RAD_Perspectiv e.unf rpict: 0 rays, 0.00% after 0.0000 hours rpict: skybright`c__ladybug_skylib_cumulativeSkies_SINGAPORE_SGP_SINGAPORE_SGP_1 : undefined variable rpict: 1020 rays, 4.91% after 0.0000 hours
----
Hi friends,
trying to get a cumulative sky image metric to run and encountered an issue with the image-based metrics component. It throws:
Runtime error (KeyNotFoundException): honeybee_materialLib Traceback: line 768, in main, "<string>" line 1442, in script
I guess this is some sort of setup issue on my end, or I messed up the definition? Any help appreciated.
Thanks,
Max
…
ace when I start running Galapagos/Octopus (below is "room orientation optimization" shared at http://hydrashare.github.io/hydra/viewer?owner=mostaphaRoudsari&fork=hydra_1&id=Room_Orientation_Optimization&slide=0&scale=1&offset=0,0) It may take quite some time to see some results. That's fine for the above simulation. But my real challenge is, when I am going to optimize room dimension with respect to ASE and sDA calculations, either Galapagos or Octopus goes wildly and never come up with a solution. I believe the time-consuming calculation, especially sDA with higher -ab numbers, trigger the lag a lot? Any suggestion/trick to improve it?
Most importantly, based on your experience, for example to optimize window/exterior shades sizes and achieve ASE<10% and sDA>55% (LEED v.4 requirements), Octopus (due to its capacity of multiple objectives) is the only choice? Any other approaches within grasshopper?
The alternative approach in my mind as a GH beginner is as follows. But I am not sure whether it is doable. Again, your comments will be greatly appreciated.
Since all my room/window/shades dimension are controlled by number sliders, I am thinking whether a component from GH will trigger these number sliders (not necessary to be all of them but one by one) automatically. If this is possible, I can do "data recorder" to record outputs from ASE and sDA. Eventually I will have a database of the input parameters and sDA/ASE results.
Does it make sense? Is there a component which can trigger number slider output at certain step?
Many thank!
Cheney …
GH, same as using sweep2 command in Rhino.
The one on the right is what I got so far (the output smooth our the kink of the original rails). Basically I am just following the methods provided by sdk sample: http://wiki.mcneel.com/developer/sdksamples/sweep2 .
The following is the function I copy and use directly from the SDK sample. By using this function, I can generate the sweep surface at right. But I want to have is the one in the middle with the kink edges. Can anyone show me how and where to modify he settings? I guess some sweep arguments need to be changed? I have try couples, such m_simplify, m_bSimpleSweep, m_bSameHeight, m_rebuild_count... but still cannot find a right combination for this function to output the sweep surface I want. Any suggestions or helps are very appreciated. Thanks for your help and time on this.
'Sweep2 function'----------------
Sub Sweep2( ByVal Rail1 As IOnCurve, _
ByVal Rail2 As IOnCurve, _
ByVal sCurves As List(Of IOnCurve), _
ByRef Sweep2_Breps As List(Of OnBrep))
'Define a new class that contains sweep2 arguments
Dim args As New MArgsRhinoSweep2
'Set the 2 rails
Dim Edge1 As New MRhinoPolyEdge
Dim Edge2 As New MRhinoPolyEdge
Edge1.Append(Rail1.DuplicateCurve())
Edge2.Append(Rail2.DuplicateCurve())
'Add rails to sweep arguments
args.m_rail_curves(0) = Edge1
args.m_rail_curves(1) = Edge2
args.m_bClosed = False
Dim section_curves As New List(Of OnCurve)
'Loop through sections to set parameters
For Each Section As IOnCurve In sCurves
Dim sCurve As OnCurve = Section.DuplicateCurve()
section_curves.Add(sCurve)
Dim t0 As Double = 0
If Not Edge1.GetClosestPoint(sCurve.PointAtStart(), t0) Then
If Not Edge1.GetClosestPoint(sCurve.PointAtEnd(), t0) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge1.GetClosestPoint(sCurve.PointAt(s), t0)
End If
End If
args.m_rail_params(0).Append(t0)
Dim t1 As Double = 0
If Not Edge2.GetClosestPoint(sCurve.PointAtStart(), t1) Then
If Not Edge2.GetClosestPoint(sCurve.PointAtEnd(), t1) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge2.GetClosestPoint(sCurve.PointAt(s), t1)
End If
End If
args.m_rail_params(1).Append(t1)
Next
'Set shapes
args.m_shape_curves = section_curves.ToArray
'Set the rest of parameters
args.m_simplify = 0
args.m_bSimpleSweep = False
args.m_bSameHeight = False
args.m_rebuild_count = -1 'Sample point count for rebuilding shapes
args.m_refit_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_sweep_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_angle_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AngleToleranceRadians()
Dim sBreps() As OnBrep = Nothing
If (RhUtil.RhinoSweep2(args, sBreps)) Then
For Each b As OnBrep In sBreps
Sweep2_Breps.Add(b)
Next
End If
Return
End Sub
…
you working on a PV system which will power a domestic hot water boiler?
To answer your questions:1) Each grasshopper component (ghpython being one of those too) is using grasshopper's data matching algorithm. This algorithm takes care of complex issues which may arise from combining lists with single items, data trees with different number of items per branch and so on.I think there is a way of introducing a call to other processor's threads per each inputted surface, but this will be a very difficult job, as it will require writing a custom data matching algorithm. I do not think I am up to that task.Instead I tried to introduce the multithread only to the final part of the PVsurface component and one of its time consuming parts: calculation of sun angles, solar radiation and ac/dc power output.I attached the test file below, but sadly it didn't go well: the multithreaded version mostly runs at the same time as the regular version.I do not think I am qualified enough to answer why is that so, but I think that it may have something to do with the type of the function that the multithreading is applied to: the code is suppose to run few separate functions a couple of thousand times, and work with a couple of lists. From my experience, the multithreading works the best when a single list or two are supplied to a single function. I may be wrong on this.I am very sorry to say that I can not implement this feature.2) I am not familiar if open source PV modules database has been released.But one can always download the data for specific modules from producers websites. It can then easily be transferred to a .csv file or other text file.Ladybug Photovoltaics are based on NREL's PVWatts model.In comparison with other commercial software applications, PVWatts offers a more generalized system model, with some of the values and characteristics being assumed or embedded.The Fuentes empirical thermal model we are currently using follows the same logic: it generalizes the Module characteristics. The following characteristics are only editable: module efficiency, temperature coefficient and module mount type.It may be possible to replace Fuentes with some other, less generalized 5 parameter thermal model. But as an architect, I would definitively need help on this.
Sorry if my reply did not fulfill your expectations, and thank you for the kind words!…
:
______________________________________________________________________
As most of you know by now, Grasshopper will be included in Rhino 6 for Windows. We are almost finished with the Grasshopper in Rhino 6 development and you are invited to try it.
There are many enhancements, including:
High DPI displays are now supported.
Compatible with existing Grasshopper plug-ins.
New components including Make2D, Bend, Flow, Maelstrom, Splop, Splorph, Stretch, Taper, and Twist...
GhPython is now included. It features its own GHA compiler and a major node-in-code speed up.
Stable development target: Your plug-ins continue to work each minor Grasshopper upgrade.
RhinoCommon enhanced: More Rhino core functionality is accessible from within Grasshopper.
Developer documentation is online with guides and API references.
Now:
Download the current Rhino WIP for Windows
Try all your existing Grasshopper definitions
Report any problems you find here...
We want to make sure this new Grasshopper works for you. If you have any issues, David needs to hear from you very soon.
Thank you,
- Bob
Visit Grasshopper at: http://www.grasshopper3d.com/?xg_source=msg_mes_network
______________________________________________________________________
So...
Any news about OS X version? Many of us won't use Parallels or whatever win emulator or have a win machine nearby.
Hope you are working at it.
Cheers
gbrl
…
Added by Gabriel Netto at 3:44pm on October 29, 2016