the end of the workshop Student performance objectives
- Understanding some basic concepts of Grasshopper, such as; Mathematical Function, Geometry, etc.
- Creating a simple parametric design system.
---------------------------------------------------
Schedule :
Deadline for Registration : April 02,2013
Workshop Starts : Thursday, April 02, 2013 - 5:30 pm
The workshop consists of 10 lectures, Each lecture lasts for 3 hours.
3 lectures per week
---------------------------------------------------
Fees :
600 L.E
You have to fill the Registration Form below for place reservation.We only have few places available.
---------------------------------------------------
Prerequisite :
-Basic knowledge of any 3d modeling software “Sketchup, 3dsmax, Rhino, Maya, ...,etc.” is required to attend the workshop.
---------------------------------------------------
Registration Form:
https://docs.google.com/forms/d/1W5CptB7FyU2d37_aqtSaBN_sxPqj7491HUN_NFgGyg8/viewform
---------------------------------------------------
Previous workshop
https://www.facebook.com/events/469048376477647/
https://www.facebook.com/media/set/?set=a.548388031851299.1073741826.470747186282051&type=1
https://www.facebook.com/events/178326265647678/…
ming to standards and practical aspects of efficient fabrication etc. Nested blocks etc is pretty adequately defined in STEP, which is what IFC is based and derived from. The trouble really is getting the other AEC software to acknowledge IFC models (that are more than primitive coordination models). This takes time, and as you've seen, I've started developing the importer for the receiving software (Revit at this stage). If demand exists and time permits, I'll consider other software to follow. I just haven't encountered enough interest yet from any of the software you mention to consider it a higher priority. I also acknowledge my IFC tools are still very much in progress, but priority for development is given to projects requiring particular functionality.
The geometric issue you're encountering is different. Every CAD system operates to a tolerance at some level (due to binary computers vs decimal human number systems) even if it is hidden from the user. My tools (like grasshopper) adopt this tolerance from Rhino again giving the user the ability to control aspects (such as fabrication tolerances etc). Be careful, there's always confusion with higher/lower tolerance values, I'd prefer to use terms looser or stricter. If you raise (relax) the tolerance, I expect the pipe to be less successful (are you modelling something 50metres long to a micromillimetre tolerance etc). This effects various steps in formulating a sweep or a pipe function.
Again the designer has the knowledge or decisions to make if a curved member is actually curved, or broken into linear segments with miter ends at connections etc. With IFC you can nominate cutPlanes (half spaced solids) etc, not exactly trivial at this stage but possible. If this information is required for fabrication etc, best to set the GH definition up this way. If you're visualizing only, sweeping/piping the polyline will give the effect (but be difficult to use downstream in any subsequent software).
I'm sure I'm not really enlightening you on much here, but my 2c anyway. Say hi to Caroline (or any equivalents) when you next see her for me. …
Added by Jon Mirtschin at 5:37am on January 31, 2012
onent. According to the glossary of the (admittedly somewhat old) reference of Sun, Wind and Light, there are separate definitions for the two metrics. They are as follows:
Sky Component - The portion of the daylight factor (at a point indoors) contributed by luminance from the sky, excluding direct sunlight.
Sky View Factor - The sector of the sky as seen from a daylight aperture or building surface. It can be measured as either a fraction or as a three-dimensional solid angle.
It seems that we all thought these metrics were the same but it turns out that Sky Component is just a weird (and almost deceptive) metric. Frankly, I can't understand what it is used for. However, perhaps the even more deceptive fact is that the Sky component computed with a uniform Radiance sky is not actually using a perfectly uniform sky as seen here.
So we will always get VSC results that are not aligned with that which we get from the sky view components. All of this and the fact that sky component seems to be an outdated metric makes me want to take it out unless someone can give a good reason for how it could do more good than the harm that it has done here in deceiving us.
I still see important merit in keeping the sky view components as sky view is important for modelling the cooling down of surfaces at night as they radiate heat to the cool night sky. Sky component just seems like an outdated daylight metric.
Let us know your thoughts and I have opened up a github issue for further discussion:
https://github.com/mostaphaRoudsari/ladybug/issues/230
-Chris…
ce issue with Rhino and shouldn't make an issue with EnergyPlus but just to have cleaner geometries, I untrimmed base surfaces so zones are closed brep now.
I also noticed that when you are adding multiple openings to a surface, the surface doesn't show-up in the output of createHBZoneFromHBSurfaces. The surfaces are there though and show up once you explode the zone! Again should be a tolerance issue for join. I need to take a closer look to both of these.
Also, in a number of the zones you had wall surfaces connected to createZoneFromHBSurfaces both before and after adding glazing. I removed parent surfaces so you don't end up having duplicate surfaces.
Back to adjacency which was your question, the issue happens since you have couple of zones with the same name so component was assuming them to be the same zone so it wouldn't solve the adjacency (Yes! it shouldn't. That was a bug which is fixed now). I changed the names and now it should find the surfaces that you are looking for.
Moreover, once you solve the adjacency, next solveAdjacency won't overwrite the BC unless you set remCurrentAdj to True.
Mostapha…
oCommonSDK, I modified a working C# component that does something similar (ReduceMesh, written by Andrew Heumann). Both scripts are attached.
Aside from changing the component name and eliminating the P parameter, I made two modifications to the script:1) changed line 87 from private void RunScript(Mesh M, double P, ref object A) to: private void RunScript(Mesh M, ref object A)2) changed line 93 from: Rhino.RhinoApp.RunScript("_-ReduceMesh _ReductionPercentage " + Convert.ToString(P) + " _Enter", false); to: Rhino.RhinoApp.RunScript("_-MatchMeshEdge " + " _Enter", false);When I run the ReduceMesh component, the mesh object I feed it gets baked, the ReduceMesh command is run, the temporary object is deleted, and the reduced mesh result is returned. (Thanks, Andrew).When I run the MatchMeshEdge component, the mesh object I feed it is baked, the MatchMeshEdge command is run, but the temporary object is not deleted and no result is returned. The runtime error reads: "Sequence contains no elements (line 0)". I have a feeling that the command line string I am handing to RunScript is incomplete. When I enter it manually on the Rhino command line I see that it wants a mesh and three parameters. Of course I can hit Enter to accept the default values, but when you invoke a command through RunScript do you have to supply all parameters regardless? Also, where would I find details on the argument types that the command wants? For example, the last parameter reads "RatchetMode=On" or "RatchetMode=Off". How do I know if the type is Bool or the literal string "On" or "Off"?I am a complete novice at this so any help you can provide would be greatly appreciated! …
correct:
- the right value in the 0. path {0;77} is the smallest one.
- right value in the 1. path {0;78} is the value which is closest to the chosen value in the preceding path
- ..and so on for {0;79} and {0;80}
but when the paths change their first level, the iteration should start from the beginning:
- right value in the 4. path {1;32} is the smallest one.
- right value in the 5. path {1;33} is the closest to the chosen one in {1;32}.
- right value in the 5. path {1;34} is the closest to the chosen one in {1;33}.
..to be continued.
..this is, what I want to achive in the VB code, I implemented at the beginning of the discussion.
..and this is how I designed the input-parameter of the VB-element:
if someone could help me .. super-great!
…
Mac due to its versatility , but given this new laptop will be using mainly on Rhino, GH , i have some doubts whether to switch to a window based laptop.
I have a look at some high-end window laptops, Dell Alienware for example, with same specs as MBP and found the price are even more expensive than MBP , about 10-15 %.
With the new Rhino 5 is coming , will Bootcamp be good and efficient enough to run Rhino, GH and some rendering programs?
From my experience i find Rhino and Gh run smoothly on Bootcamp , but never run those programs on window based laptop myself , it's impossible for me to know the differences.
Some say BootCamp only deliver 80% performance of the program , if it's true i would really consider switching to window based laptop.
Any suggestions?
and if you suggest me to switch , what brand should i go for ?
Thank you,
…