llet Distance]
[Slider=0..1..10]-->[D][Fillet Distance]
[Slider=1..5..20]-->[F][Unit Z]
[Fillet Distance][C]-->[B][Extrude]
[Unit Z][V]-->[D][Extrude]
This still leaves the problem of having more than one of a single component on the canvas. Referral can be made unambiguous by simply picking the most recent component with the same name. But how do you indicate you want a second Polyline component?
Possible solutions:
Separators in the text:[Point=SetMultiplePoints]-->[V][Polyline]----------------------------------[Point=SetMultiplePoints]-->[V][Polyline]
Keywords or symbols to indicate the creation of a new component rather than the re-use of an existing one:new [Point=SetMultiplePoints]--> new [V][Polyline]new [Point=SetMultiplePoints]--> new [V][Polyline]
(2) is a lot more flexible and (1) may not work at all as it will prevent any reuse above and below the separator.
--
David Rutten
david@mcneel.com…
l design.
2/ Optimization
2.1/ in prefabrication
2.2/ combinatorial
2.3/ approach comparisons (i.e. deterministic vs stochastic)
2.4/ share your research
2.5/ ... etc. the list goes on and on
3/ Share you design rationale and how computation fits in
4/ Need help with this problem...
5/ Challenges and workshops announcements
6/ CD News
7/ Share computational design projects under construction or built (akin to skyscrapercity)
8/ and so many other categories and sub-categories...
Just my first thoughts. That breakdown in optimization is just an example. Maybe 'sections' is an old-school way of seeing things, I just wanted to share some thoughts on the kind of content I look forward to seeing. It can be pragmatic topics, but also theoretical, and allow folks to share their projects and research. Some categories are specific, others broad. I suppose I'm interested in community building with regards to computational design. I think SmartGeometry attempted to accomplish this at some point in the past, to some degree. However their focus appears to be in the workshops and challenges.
I recall the silly flame wars that the CG industry had 20 years ago (lame). I'd avoid that, even if it meant forbidding the mention of any specific software in certain areas or in the entire forum. Which would be tricky, but the endless flame wars and silly comparisons were such a waste of everyone's time in CG.
Without dwelling on this too much yet, I think that the software specific questions belong in software specific forums. If we already had a common language for computational design, you'd just need to add the right description as a meta-tag to any Dynamo or Grasshopper forum post, and you'd be able to find analogous solutions in either forum effortlessly, right?
The Dynamo and Grasshopper forums lack design-centric content. The emphasis is generally on the tools and workflow. Computational design is hybrid in essence, it involves both design and computer programming (be it visual or textual). We could really use a forum for knowledge exchange where the expectation is that both are discussed with equal status.
I disagree that such a forum ought to exclude professional programmers. It should include professional programmers whom have an interest in design, and also include professional designers whom have an interest in computer programming, and everyone in between, and enthusiasts, and artists whom are curious about algorithms as a creative medium, and academics, and students, and etc etc. As long as there is rich content and activity on design as well, not only the computational bit, then the crowd will be diverse and we'll all have more to learn from one another.…
d. If what you say is correct about the small difference between the global horizontal and direct/diffuse calculations in the MENEX model, than the discrepancy likely has more to do with the difference between the approximation of human geometry in the MENEX model (plane or cylinder) and the human geometry approximation in the SolarCal model (some coefficients derived from radiation studies of mannequins). I noticed some fairly large differences between using a suggested global horizontal method and a direct/diffuse method with the SolarCal model (differences on the order of 20%) but I imagine that this is because a mannequin human geometry is more sensitive to changes in solar orientation than a cylinder or plane. All of this is very good to know.
Yes, I guess this might be the case: the sensitivity of the SolarCal model to different parts of human body surfaces and surfaces areas.
Am I correct in understanding that you recently corrected the grey-body assumption about sky temperature in the Thermal Comfort Indices component with this commit? https://github.com/mostaphaRoudsari/ladybug/commit/a2a37b6dccc4e750...
The previous incoming long-wave radiation was derived by Ångström for clear sky conditions. The added correction "(1 + 0.22*((N/10)**2.75))" is a fractional cloudiness factor by Maykut and Church (I attached the publication below which mentions it).
So the emissivity coefficient of the (cloudy) sky is now:
epsilon_sky = (0.82 - 0.25*(10**(-0.094*0.75*e))) * (1 + 0.22*((N/10)**2.75))
I do not think that you could use the same value to calculate the sky temperature with Stefan-Boltzmann law, as the incoming long-wave radiation has been derived from the air temperature (2 meters above the ground), not the sky temperature. So by:
skyTemp = (La / [epsilon_sky * sigma])^0.25 - 273.15
One would get the air temperature from which La is derived, not skyTemp.The possible reason why SolCal Mean radiant temperature is currently getting similar values to Thermal Comfort Indices Mean radiant temperature could be that fact your epsilon_sky is almost equal to 1 (0.95), so it depends solely on La.I spoke with Dr. Blazejczyk, and got a publication on different sky temperature models. Apart from upper mentioned Swinbank, Berdahl-Martin, Melchor it has a lot more methods with mutual comparison of their resulting values. I attached it below.…
d react in length to the variation of their respective angle deviation from the sun.
For the moment I have established a way that depending on Bigger than/Smaller than X value, there is a dispatch of data to produce to types of panel lenghts. As you can see on the image.
But I would be interested to find the way to organize the list of all angles and classify them in groups like 5 packages of 20 degrees deviation. So, the panels deviated 16,3 and 27,9 degrees would go in the package of 15-35º, for example, and the 33,1 would go in the 35-45º...etc..
And the question would be to assign the different groups of angles, to given positions for the vectors that define the panel surfaces.
I am confused at how I should tackle this problem. Is it a question of dividing domains? Or creating sublists? But then, how can I assign the data to a set of positions? Dispatch only works with A/B..
And if so, how could I limit the positions of the vectors that define the surfaces, to a min and max length that would not overlap out of the base pattern?
These are huge questions, eh? But I'm sure that someone has tackled this problem before...
Looks like an accumulation of pretty standard problems,..but all together!
Thanks a million for any examples or hints on how this could work!
M.A.
StepStudies_20100815.3dm
StepStudies_20100815.ghx
…
eps are represented by multiple surfaces so the discussed techniques are not fully workable.
the attached files include my test gh and a solid file to input. I have been able to map a suitable voronoi latticework onto the brep surface - but then I'm stuck. I cannot offset the curves on the brep and create a useable strut surface that way. I cannot intersect swept pipes with the brep surface to create surface patches that could then be joined.
I need some elegant ideas; I seem to be going down a rabbit hole at the moment where I am doing ever more complex workarounds for the grasshopper capabilities. (A case in point; the rail sweep is not working for me for closed 3D polylines, so I am having to cut them up and sweep and cap the segments. Ugh).
Example input brep
Curves on brep - but no simple offset / trim mechanism
Potential rail defining strut trim - but no way to do so...
Brep / rail intersect - but no way to turn this into a surface...
Programme
Voronoi%20strut%20on%20brep%20test.3dm
Voronoi%20struts%20-%20volume%202.gh
…
an Architecture or Engineering degree and a passion for design and coding.
You must have advanced skills in computational programming, experience in software development and creating language dependent API and class definitions. You will be fluent coding in C# and a strong math’s background is essential. The ability to translate syntax in object-oriented languages is required along with an advanced understanding of data structures and algorithms in the CAD or graphics domain. You will have excellent communication skills and be a strong team player.
In return you will work in a highly creative environment, take your shoes off at the door every morning and take advantage of our special office culture.
Hours: Usually 9am to 6pm (with one hour lunch), Mon - Fri. Salary: £30,000 dependent on experience. Benefits: 20 days annual leave per year, plus bank holidays.
To apply please send your portfolio, CV and covering letter to work@ala.uk.com.
No agencies please.
…
r the course is conditional on being committed to change : ) We are looking for people who want personal challenges, not massive videos. We believe on individual training to give learning experience to our students that are based on their choices, interest, passions and ambitions, giving them more voice into the learning process.
As first step we create your course with your input and we start with your weekly challenges. Be part of the new wave of online courses : )
info@pazacademy.xyz
…
next level.
This Parametric Design course will provide the participants with the necessary knowledge and ability to use Grasshopper, a free visual programming plugin in Rhinoceros; you will be guided through a series of hands-on exercises that highlight NURBS modeling and its concepts. We will introduce Grasshopper as a graphical algorithm editor tightly integrated with Rhino’s 3D modeling tools. You will also learn how Rhino is used to render models for visualization, translate 3D models for prototyping, and export 3D models into 2D CAD or graphics programs.
English is the course main language.
Location: Düsseldorf city center
Registration and buying Tickets
www.digitalparametrics.eventbrite.de
Course Calendar:
4 Days 6 hours each
Total duration 24h
2 weekends
Date:
Sat. 17 - Sun. 18 June
Sat. 24 - Sun. 25 June
10:00 - 17:00
Getting Started in Rhino. 2 days (17 - 18 June)
Getting Started in Grasshopper. 2 days (24 - 25 June)
-----------------------------------------------------------------------
Participants will be given a certificate of participation at the end of the course.
-----------------------------------------------------------------------
Course fees:
Professionals: 600€ (excl. MwSt.) Students: 500€ (excl. MwSt.) Students need to provide: Copy of current student ID or proof of student enrollment at University/School.
Group discounts:
Group of 3 professionals: 3x500 = 1500€ (excl. MwSt.)
Group of 3 Students: 3x400 = 1200€ (excl. MwSt.)
Participants are kindly asked to bring their own laptops and have pre-installed Rhino + Grasshopper.
Useful Resources:
Rhinoceros Installation (90 days full version trial available): http://www.rhino3d.com/download
Rhinoceros for Mac (includes Grasshopper) http://www.rhino3d.com/download/rhino-for-mac/5/wip
Grasshopper Free Installation: http://www.grasshopper3d.com/page/download-1
Grasshopper Free Plugins: http://www.food4rhino.com/app/lunchbox http://www.giuliopiacentino.com/weaverbird
Main Tutor:
Rihan
M.A. Dipl.Ing. Architect
Architect at RKW Architektur + Düsseldorf
For any questions about the course, please email: info@immersive-studio.com…
ll geometry.
The difference with programs like Inventor is that they are made for production, regardless of the fabrication method. I won't go into detail about that, and instead focus on the modeling process.
In this little model, the starting point actually is a bit obvious, the foundation.
The only contents in the 3dm file are 27 lines. These indicate the location of each footing, and the direction of the tilt of each column. Everything else is defined in GH with the use of numbers as input parameters.
Needless to say, instead of those lines you could obviously generate lines and control the number of columns and panels, hence establish their layout, with any algorithmic or non-algorithmic criteria you please. That marks a major difference between GH and Inventor.
You can generate geometry with Inventor via scripting/customization (beyond iLogic), with transient graphics for visual feedback similar to GH's red-default previews. However Inventor's modeling functions are not set to input and output data trees. I won't go into detail on that, but suffice to say that the data tree associativity of GH was for me the first major difference I noticed. I've used other apps with node diagram interfaces like digital fusion for non-linear video editing since the late 90's, so the canvas did not call my attention when I first started using GH.
Anyways, here's a screen capture of the foundational lines:
In the first group of components, the centerlines of the rear columns are modeled:
And the locations in elevation for connection points are set. Those elevations were just numbers I copied from Excel, but you can obviously control that any way you please. I was just trying to model this quickly.
The same was done for the rear columns:
The above, believe it or not, took me the first 5 hours to get.
Here's a screen capture of what the model and definition looked like after 4 hours, not much:
If you're interested, next post I can get into the sketching part you mentioned, which is a bit cumbersome with GH, but not really.
I wouldn't say that using GH to do this little model was cumbersome, it just needed some thinking at the beginning. You do similar initial thinking when working with a feature-based modeler.…
Added by Santiago Diaz at 12:44am on February 24, 2011