e Workshop and Conference will be a gathering of the global community of innovators and pioneers in the fields of architecture, design and engineering.
The event will be in two parts, a four day Workshop 14-17 July, and a public conference beginning with Talkshop 18 July, followed by a Symposium 19 July. The event follows the format of the highly successful preceding events sg2010 Barcelona, sg2011 Copenhagen, sg2012 Troy, and sg2013 London.
sg2014: Hong Kong
Image: Cities without Ground - Adam Frampton, Jonathan D Solomon and Clara Wong
URBAN COMPACTION
Large cities thrive on density and diversity. But beyond the energy and pollution advantages of the elevator over the automobile, complex issues are at play in concentrating population and built infrastructure in contemporary high-rise cities. How do you meet the challenges of system design for high quality compact urban environments?
Designing for high and increasing density in cities is a complex and wicked problem that calls for innovative approaches to modelling in diverse areas of the city’s dynamics.
sg2014 Challenge: Urban Compaction
WORKSHOP
The SG Workshop is a unique creative cauldron attracting attendees from across the world of academia, professional practice as well as many of the brightest students. The Workshop is open to 100 applicants who come together for four intensive days of design and collaboration.
The annual Workshop is organised around Clusters. Clusters are hubs of expertise comprising of people, knowledge, tools, materials and machines. The Clusters provide a focus for Workshop participants working together, within a common framework.
We now have an open call to submit proposals for Workshop Clusters
call for clusters
CONFERENCE
Talkshop Conference Day One
After four intense days of innovative work, the first day of the conference, the Talkshop, offers an opportunity for critical reflection on what has been accomplished in the Workshop. Talkshop will be an opportunity to open debates, pose questions, challenge orthodoxies, and propose new ideas.
Talkshop will feature informal and open discussions between Cluster participants, leading practitioners and emerging talents in digital design, offering inside perspectives on how the landscape of computational design is reshaping built form.
Symposium Conference Day Two
The second day of the conference, the Symposium, will feature invited keynote speakers showcasing major projects and research from around the globe that mark out the territory of the year's Challenge. The Symposium is a unique opportunity to hear insights into the challenges ahead for the discipline.
Interwoven throughout the day will be reports and highlights from each Workshop Cluster, giving an opportunity to view work created during the previous four days of intensive collaboration, design and development.
More information about the conference, including speakers, to be posted soon.
www.Smartgeometry.org…
Added by Shane Burger at 10:51am on February 3, 2014
it provided that you know how to use it, he he).
Note: prior switching from mesh (via StarlingStar) to brep+holes (via C#) - each one has his own K Engine - stop/kill the Kangaroo animation control mini Dialog otherwise ... you'll have "some" troubles.
djodje:
This thing used (see script in v4b) IS NOT the same as the P thing that you posted (the one that takes 3 arguments where the splitter is a curve).
for David:
Irrelevant with the thread, but a 100% repro case related with the GH inability to internalize data:
This brep is a human figure internalized (but every time when the def is stored and reopened GH reports it as "Null").
So import the man-and-dog.3dm, reference the man (or the doberman), save definition and reopen it.
I'm not sure if Image sampler can store (in file) a thing or two as well:
v5 "soon" (lot's of new stuff and 4.56 divisions by zero) , best, Peter…
le] demo):
1. A transformation Matrix is a 4*4 collection of 16 values that "deform" 3d things according the values in the cells. The orthodox way is to deploy "cells" left to right and top to bottom. Rhino does the opposite (why?) hence we need the transpose method.
2. Since "translate" and "perspective" are "symmetrical" the transpose boolean toggle (within the C#) "flips" rows with columns ... so we get perspective or move.
3. When in perspective "mode" the vanishing points are computed internally within a min/max limit (per X/Y/Z axis) thus avoiding the usual havoc with "extreme" perspective angles (very common "glitz" in pretty much every CAD app - CATIA excluded). Vanishing points (and limits) are oriented with respect the pos/neg value of a given control slider.
Note: slider values are percentages between min/max (mode: perspective) and/or actual values*100 (mode: move).
4.In order to start mastering the whole thing: don't change anything: just play with these 4 sliders selected:
5. The 123 sardine cans challenge: even with DeusExMachine = true (see inside C#: that one redirects the transformation per BrepFace and then joins the breps instead of applying it on a brep basis)... odd things (and/or invalid breps) occur ... thus what is required in order to make things working 100% ??.
he, he
best, Lord of Darkness …
ng the code where its needed. There are several reasons for this. First off, Grasshopper is really not a proper IDE (integrated development environment). GH really doesn't have the debugging, syntax highlighting, and the development flexibility that you can get through Visual Studio. Having worked with VS for a bit, I can tell that it is much easier and more efficient for me to write code there than in GH, and I know more about what's going on with it in VS than in GH.
Secondly, if all I'm going to do within GH is have 2 or 3 scripting nodes that do the heavy lifting, what's the point of me doing that within Grasshopper. If a project is going to be made up of that much code, then you might as well just do it all in code, compile it, and load it up as a plugin or a script. As I mentioned above, it would probably be more efficient to do it that way. Besides, although scripting nodes are great for specialized functionality that may never be native to GH, I'm not sure that the point of GH is to just become another scripting interface.
Lastly, I personally feel that there's a value in the network that winds up being created when you work in GH that is not only worth while to you, but to other people who may have to work with your logic. When its laid out graphically it has a certain kind of accessibility that doesn't seam to be the same when one looks at code (even if its your own). I'm not saying that one is better than the other, but I think that the actual enterprise of creating the network has a certain amount of importance.
In regards to my personal workflow, I generally take 2 (maybe 3) things into account when I determine whether something should be done through code or through GH. The first one is pretty simple...if something can't be done natively in GH, then it goes into code. That seams pretty self explanatory to me. Second is whether, for organizational purposes, a given operation would be better to do through code as opposed to through components. One of the most complex and visually cumbersome things to do in GH is reorganize data so that it reacts in the way that's needed. Sometimes I find this better to do in code rather than the dozen components it would take, so those are the times that this situation sticks its head out. The "maybe 3"rd thing is whether or not I can pass the data between scripting nodes. Unfortunately, for things like transforms that haven't been added, that data is "stuck" in a scripting node, so if I want to continue working with it it almost has to be within the same node*. I guess to some up, if it doesn't need to be coded, and it doesn't make things easier to code it, then I take care of it through standard GH components.
HTH
-Damien
* this isn't 100% the case as there are ways to share data between components, but it may be more effort than its worth depending on the situation…
ay to make some real-life proper nodes for that kind of T truss (we use machined balls solely for MERO KK type of normal trusses).
3. I'll post here soon a modular demo system suitable for this case (real-life for AEC purposes - NOT for decorative/artistic stuff, I don't care about that since I'm an engineer). This would include a policy for the X struts that require a variable linkage (the X angle). and in the same time a multi cable tensioner "bracket".
4. "Basic" coding next week for T trusses ? Er ... well ... are you kidding me right? I mean that ... hmm ...
5. C# things (about 2+K) around me are classified into 2 "groups": things that are weapons in the right hands and others that serve as demos/start points for mostly abstract cases. The former are internal the latter for public use. I'll remove some sensitive lines from a T truss C# maker and I'll post it here as a "guideline" ... for ...hmm... 4.
All in all:
Provided that you have system(s) on hand (see 3) that work 100% OK in an ideal world you'll need:
A. Something that does the general topology AND (especially) clash detection. Maybe Kangaroo as well as a "first pass" with regard rigidity of the structure in case that you don't adopt a classic T "configuration" (there are many > Google tensegrity).
B. Connectivity trees that relate nodes/edges and maybe faces (say for roofing panels/curtain walls etc etc). Without them is impossible to assemble the T thingy.
C: Something that places real-life "parts" as instance definitions and/or (optional) a "tracking variants history" ability.
D. A bullet proof way to EXPORT things (on an assembly/component schema, say: STEP214 - see C) into a proper BIM app (the likes of AECOSim/Revit) and/or into a MCAD app (the likes of CATIA/NX).
E. FEA/FIM in order to validate the structural ability of the components and the T truss itself.
F. Roofing/cladding/envelope components.
G. "Interactive" cost estimation(s) - T trusses are hideously expensive at least versus "classic" trusses (exactly like a planar glazing system that retails 3++ times more than a humble semi-structural one)…
is the way the component was designed, but I love it and have used it multiple times.
You state:
Now for your position 3 the angle is either 0° or 180°. Since calculating the angle will always return both angle and reflex angle, you need to decide, which to use. AlignPlane uses minimal rotation. Hence your WorldXY will get no rotation at all for your position 3.
However... that's not actually true or what is happening. If you look closely at the image supplied in the original post you will see that the plane displayed at 180 is indeed rotated and the X vector is indeed pointing to -X. To double verify that I extracted the X vector from those planes and displayed them... clearly you can see in the image below that the AlignPlane component is rotating the plane at 180.
Now... to get back to the original issue. The problem I pointed out in my original post was not with the AlignPlane component, but rather with the OrientDirection component. It seems to me that component has an issue when fed a target direction of -X {-1;0;0} for a target vector.
To eliminate the confusion caused by the AlignPlane component I eliminated that component from the design and simply used rotated vectors as input to the target direction of OrientDirection. You will see that the results are the same... when given a target direction of {-1;0;0} the object is not rotated, while any other vector input does rotate the object.
I've attached the updated gh file demonstrating the issue using rotated vectors as the input for dB target direction of the OrientDirection component.…
ed rhino object with a uuid - as soon as i take it into a component the point comes out as a non referenced type and the associaiton, UUID, is broken to the original baked rhino object. This happened for a simple translation action using the move component - i specified a vector and moved all referenced points, output points were no longer reference types
For addition, if you use your idea of a uuid for a user string will it matter if you use addition as the two curves will have differnet uuids for the user string. The user could iterate through the user string collection on the created object to decide on which one to use. I guess the order of the user strings on the additive object is imprtant i.e. if A + B = C, then theorder of the user strings on C should be A, B
Some thoughts about how to maintian this.
1. If a grasshopper object is a reference type - the porperty IsReference can be used - then a new instance of a grasshoper object derived from any geometry that is a reference object has the option of copying that user string.
2. May be you can specify a global option as to whether to maintain inputted reference geometry user strings in components? May be a local option when right clickign on a components inputs where you can specify maintain input reference user strings
3. Restrict copying of reference user strings to certain componens where teh order and number of input parameetrs is unaltered when outputting - as you said, this should be the case for translation, scaling operations.
Not sure what the answer is, Im sure if you dont know the answer then nobody will know!!
Steve…
iew mode:
instead of the fabrication mode (individual Breps ready for 3d printing - minus "some" little details with regard their effortless connection > this is what V3 does):
2. GH does not (AFAIK) include the mesh.Offset capability (used a little C# for that).
3. I promise to translate the test C# used into native components ... if the result is what you are after (you never know, he he).
4. Rounding (fillet) the thickened panel lips (around the hole and with regard perimeter panels) is doable but only via code: AFAIK GH does not include the Surface.CreateRollingBallFillet method (something that does fillets, that is - forget it for the moment). In fact ... there's a complex way to do it without that method ... but is not for the moment (next week you'll be 100% more experienced, he he).…
ow much space that combination would take (according to London Design Guidelines). So for the example above, a 3/6/9/2 combination takes up 1219 square metres.
It's true I am storing very weird combinations of units (35/0/0/0 for example, a residential block made only of studios...), but a priori I don't know if it might come in handy one day!
Once I have that calculation done, which doesn't apply to any specific project, I "evaluate" it for a specific project. I have various floorplates of different sizes, so I go through my index looking for good matches (those which are close enough in area) - and here is where I need a recorder, but one that traps only the good results, and only gets better as it reads through the file.
After that, I lay the units onto the floorplate and evaluate how good the solutions I have found are (the usual suspects; orientation, sun exposure, cross-ventilation, etc.). I might need Galapagos for this, but the fact remains I need to cull a huge pool of 33M possible combinations into (say) 100. Hence my need for a recorder.
It would be great to read your thesis actually! If you would be so kind as to share, always looking for different ways of approaching the solution.…
ld be covered in concrete. I input the specs of the architectural fabric. E=.75 v=.3 p=610 and the thickness is .009. Whenever I run the study, and I've done so on several different meshes, it always produces several errant points. What do these points mean. Also when you divide 1 by the deflection does that convert the deflection to meters. I am also curious about the self weight input. Am I correct in assuming that a self weight of 1 applies 100% of all forces onto the model. I have been a big fan of your software and of your ideas and I still use topostruct since it's such a creative tool. I would like to learn more about doing studies in millipede but I need a little more info on what the various optimization setting should be and what tolerance values to apply. There are several inputs for these but I am unsure how to make adjustments. I have tried to follow your manual and demo files and they have been very helpful in getting me to this point but it seems there are some details I still don't get. If you can help explain or if you'd prefer I can provide you with the file to review. thanks …