ay to use a sine wave length along a curve with the grasshopper script below. [Update: done, thank you TOM].
I am trying to figure out a way to reverse the sine wavelength.
Current problems:
1.) Reversing the sine wavelength along the curve. And provide a graph to allow for different graphs.
I.e., I want to have a sine wavelength on the base, and 3200mm above a wavelength of a different sort. Current File: (apply curve to any curve)
Brick%20problem.gh
2.) Contouring when lofted to allow for HFrame placement
I need to be able to apply the script to curves; and be able to adjust a series of points, and the multipiers to adjust the width the curve extrudes in the y axis away from the curve at a perpendicular angle.
Current: (took a long time but this is where I am now)
OLD:
Fixing: Achieved:
Also, is there a way to do this without series and by linking surfaces already in Rhino3d?
Sine wavelength below, and intention to use the brick wall on in picture after.
I've been following Nick Senske's work on YouTube for those wondering.
I hope to achieve something similar to the pictures attached:
http://www.zja.nl/image/2014/10/15/2112_500_325.jpg(mediaclass-default.f996b08cf5abfa43b3b03133a89ec231272756a9).jpg
http://www.zja.nl/en/page/2311/parametric-design-for-brick-surfaces
Edits: Removal of unneeded content and grammar. Update of pictures and progress. Thanks to Tom for his assistance. …
Added by Iain McQuin at 9:52pm on October 18, 2016
we're actually using PET sheets for our flexures. We try to design so that the flexures don't go through more than +/- 30 degrees of deflection. If the angular deflection is kept small, the lifetime can definitely be on the order of 1000000 cycles.
As for the design process (item 2), ideally the designer would be able to use a simple 3D CAD tool to design a model of a robot, and the geometry would be represented by dimensioning the individual parts in the model. Maybe there should be some parametric primitive kinematic building blocks like four bar linkages, box frames, etc. that a user could build up a robot from. But, the key functionality the tool needs to provide is for the designer to be able to visualize how the robot will move when it's fabricated. This could mean observing (or plotting) the motion of a leg, a wing, or a series of body segments. Ideally, then, the tool would generate an unfolding of the design. How this would work is still very vague - maybe the user would assist in the unfolding, maybe there would be an optimization routine that computes optimal unfoldings based on criteria like minimal waste, or fewest pieces (I would *not* constrain the problem to construction from a single monolithic piece as in origami). The biggest problem we have right now, is that our design process is totally divorced from fabrication. Even if we went through the trouble of extruding individual thin plates in Solidworks and creating an assembly for visualizing the kinematics of a mechanism, that particular representation doesn't transfer easily to the fabrication process because it's essentially monolithic.
Item 3: The 2D drawing is simple a drawing done manually in Solidworks. There are different layers for flexure cuts, outline cuts, and potentially any cuts to be made in the plastic flexure layer. Depending on the robot, there may be many separate pieces for different parts and linkages in a single robot. For example, the drawing for a robot containing a fourbar linkage may have the linkage laid out as a physically separate piece consisting of five rigid links connected by four flexure hinges. During assembly, the designer would then fold up that linkage and insert it into the robot wherever it's supposed to go. If you're curious you can see some sample 2D drawings for older designs here: http://robotics.eecs.berkeley.edu/~ronf/Prototype/ under the "Example Structures" heading.
I noticed Kangaroo seems to be a popular choice for physical simulations. I don't really even need to include forces like bending resistance - I'm happy to allow the design tool to approximate flexures as pin joint-type hinges. Once the design is unfolded, the details of how to cut the flexures could be worked out in a post-processing step. I wouldn't expect the tool to be able to realistically simulate the bending of the hinges.
I'm going to have to dig a lot deeper into understanding Grasshopper and Kangaroo. I only just got started with Grasshopper today by following the folding plate tutorial on wa11ace.com.au today. …
l, you can find examples of parametric design using LB/HB, specifically the HB component pollinator workflows.
In these examples, a GH component (data recorder) is used to locally store either input parameters or output values of different model configurations and transmit them to pollinator. I can imagine, depending on how your facade is made parametric in GH, that you could save those input parameters (e.g. angle of surfaces or height of extrusion) and output variables for each iteration (e.g. annual shading).
This a search process through the design space. I do think that if you would set up the model as such, then it would be ok that the components in the PV workflow resetted after each iteration as the results would be saved. There is even a really good visualization platform Mostapha has shared to go along pollinator.
You can find examples of these workflows in the forum, simply search pollinator. I have one that I shared somewhere as well, although it was doing rudimentary things it would help.
This design space approach is a bit different than the optimization approach utilizing components like galapagos. It gives you an idea of the space of possible different desings and allows you to compare alternatives. Plus, it usually allows me to avoid all these issues of losing results between components in the workflo.
I also find it very handy and much more efficient than simply allowing a component optimize everything for me. However, it can ncrease almost exponantially (or is it geometrically, I am always bad at this) to the range and number of your input parameters. So, if each square on the wall has more than a couple of input values for a a few input parameters, I would expect this to take a long time. Thankfully, the components in the workflow will let you know exactly how many iterations.
If this method is interesting to you and you follow it I would suggest a few things to hasten the process like utilizing only the squared above and on the sides of the PV panel, since the others won't really affect shading, selecting just 2 or 3 characteristic angles for extrusions, and perhaps approximating energy production through annual shading numbers (since I imagine they have an almost linear relationship).
I do hope that I have understood what you want to do and the above information helps. I'm sure Djordje will give much better feedback on the specifics of the PV workflow. I will try and keep this page saved so that I can send over the example once I'm back at work mid of next week.
Good luck!
Kind regards,
Theodore.
…
ve Intermediate Insight of Computational Design Strategies While Exploring Rangoli Art form in 2 Dimension and 3Dimesion in which Participants will not only be trained to Digitally Design using Parametric software's but they will also be trained to Fabricate them in reality.
This Course will be explored in manner where Participants will understand inter-dependency of Rhinoceros3D & Grasshoper3D through a unique Hybrid Teaching Method While Exploring Rangoli Geometry .
The course will also take participants through Topics such as - Computational Thinking, - Computational / Parametric Design, - Computational Rangoli Exploration, - Digital Fabrication, - 3D Visualization ( Rhino3D 6), - Making Info-graphics & Design Diagrams ( Rhino3d 6 ).
Participants will also be doing a Project at the last Leg of Workshop in which they will implement the skill they gained in first Few Weeks.
{ Tutor } Nitant Pixelkar (Computational Artist / Designer, Mumbai)
Nitant Hirlekar A.k.a. Pixelkar, is a Computational Artist. He graduated from Rachana Sansad school of Interior Design 2011, Mumbai. In Academics He Bagged Two Gold and One Silver Medal on National Level.
In his post academic days, he came across the Emerging Computational Techniques in Design industry in which Algorithm serves as a main Functional part. He uses Algorithms to Deconstruct the Captured images in Pixelated form using the Grid of the Desired Indian Art Forms.
He Heads Collective Group Named "Mutation Lab” which is a multidisciplinary Design & Art Cell. Where they Explore Computational Approach while Designing Various Scales Spatial Installation, Digital Fabrication, Interactive Installations and Computational Consultancy for Various Architects.
He has exhibited his first artwork in Kalaghoda Arts Festival for in 2014 And further in 2016 and 2017.In 2015 he exhibited in Dharavi Biennale” organized by Wellcome Trust,London & Sneha Organisation, Mumbai Which was internationally acclaimed. In 2016 he got Featured on a TV show - The Creative Indian's as an Absolut Creative Indian of the Week.
Academically he is been involved in Many Computational Design Workshops / Elective Studios for School of Interior Design (Rachna Sansad), LS Raheja College of Architecture & Rat-Lab (Delhi).
{ Participants } The Course is aimed at Architecture, Interior Design, Product Design,Furniture Design & Fashion Design Students and Professionals. However we would be thrilled to have any Interdisciplinary Artist / Creator/ Maker to join the Course as well.
{ Level }
Intermediate
{ Timing } Monday To Friday - 6:00 PM to 9:00 PM (15 Hours/ Week = 5 Week X 15 Hours = 75 Hours )
{ Dates } Registration Ends - 24th April 2020 **Subejct to Availablity
{ Workshop Dates } 4th May 2020 To 5th June 2020
{ Venue } Lower Parel,Mumbai ( Details To Be Announced )
{ Schedule }
{Registration Form}…
e a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative.
I get that. That’s why that 3D shape I’m trying to apply the voronoi to was done in NX. I do wonder where the GUI metaphor GH uses comes from. It reminds me of LabVIEW.
"What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."
Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it.
It’s not the primary components that catalyzed this thought but rather the secondary components. I was toying with a component today (twist from jackalope) that made use of three toggle components. The things they controlled are checkboxes in other apps.
Take a look at this jpg. Ignore differences; I did 'em quickly. GH required 19 components to do what SW did with 4 commands. Note the difference in screen real estate.
As an aside, I really hate SolidWorks (SW). But going forward, I’ll use it as an example because it’s what most people are familiar with.
"[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."
Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.
I agree, and disagree. I believe parametric applies equally to GH AND SW, NX, and so forth, while algorithmic is unique to GH (and GC and Dynamo I think). Thus I understand why you prefer the term. I too tend to not like referring to GH as a parametric modeler for the same reason.
But I think it oversimplifies it to say parametric modelers move the clicks. SW tracks clicks the same way GH does; GH holds that information in geometry components while SW holds it in a feature in the feature tree. In both GH and SW edits to the base geometry will drive a recalculation, but more commonly, it’s an edit to input data, beit equations or just plain numbers, that drive a recalculation.
I understand the difference in these programs. What brought me to GH is that it can create a visual dialog that standard modelers can’t. But as I've grown more comfortable with it I’ve come to realize that the GUI of GH and the GUI of other parametric modelers, while looking completely different, are surprisingly interchangeable. Do not misconstrue that I’m suggesting that GH should replace it’s GUI with SW’s. I’m not. I refrain from suggesting anything specific. I only suggest that you allow yourself to think radically.
This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Given a choice, I'd pick kick-ass algorithmic modeller with no parametrics tacked on.
2. Visual Programming.
I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
I'll admit, this is a bit tough to explain. As I've re-read my own comment, I think it was partly a precursor to the context sensitivity point and touched upon other stated points.
This now touches upon my own ignorance about GH’s target market. Are you moving toward a highly specialized tool for programmers and/or mathematicians, or is the intent to create a tool that most designers can master? If it’s the former, rock on. You’re doing great. If it’s the latter, I’m one of the more technically sophisticated designers I know and I’m lost most of the time when using GH.
GH allows the same freedom as a command line editor. You can do whatever you like, and it’ll work or not. And you won’t know why it works or doesn't until you start becoming a bit of an expert and can actually decipher the gibberish in a panel component. I often feel GH has the ease of use of DOS with a badass video card in front.
Please indulge my bit of storytelling. Early 3D modelers, CATIA, Unigraphics, and Pro-Engineer, were unbelievably difficult to use. Yet no one ever complained. The pain of entry was immense. But once you made it past the pain threshold, the salary you could command was very well worth it. And the fewer the people who knew how to use it, the more money you could demand. So in a sense, their lack of usability was a desirable feature among those who’d figured it out.
Then SolidWorks came along. It could only do a fraction of what the others did, but it was a fraction of the cost, it did most of what you needed, and anyone could figure it out. There was even a manual on how to use it. (Craziness!) Within a few short years, the big three all had to change their names (V5, NX, and Wildfire (now Creo)) and change the way they do things. All are now significantly easier to use.
I can tell that the amount of development time that’s gone into GH is immense and I believe the functionality is genius. I also believe it’s ease of use could be greatly improved.
Having re-read my original comments, I think it sounded a bit snotty. For that I apologize.
3. Context sensitivity.
"There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."
Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?
I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal [...] is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.
You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
You bring up both interesting points and limits to my understanding of coding. I’ve reached the point in my learning of GH where I’m just getting into figuring out the sets tab (and so far I’m not doing too well). I often find myself wondering “Is all of this manual conditioning of the data really necessary? Doesn’t most software perform this kind of stuff invisibly?” I’d love to be right and see it go away, but I could easily be wrong. I’ve been wrong before.
5. Components.
"Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."
I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data.
I kinda like this. It’s a continuation of what you’re currently doing with things like the panel component.
"Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"
It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
6. Integration.
"Why isn't it just live geometry?"
This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry.
"Maybe add more Rhino functionality to GH. GH has no 3D offset."
That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).
On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
You work for McNeel yet you seem to speak of them as a separate entity. Is this to say that there are technical reasons GH can only access things through the Rhino SDK? I’d think you would have complete access to all Rhino API’s. I hope it’s not a fiefdom issue, but it happens.
7. Documentation.
Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.
Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
It begs the question that I have to ask. When is GH1.0 scheduled to launch? And if you need another person to proofread the current draft of new primer.
patrick@girgen.com
I can’t believe wikipedia has an entry for feature creep. And I can’t believe you included it. It made me giggle. Thanks.
8. 2D-ness.
"I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"
I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
I believe it’s been helpful for me to have figured this out. I recently completed a GH course at a local Community College and have done a bunch of online tutorials. The first real project I decided to tackle has turned out to be one of the more difficult things to try. It’s the source of the questions I posted. (Thanks for pointing out that they were posted in the wrong spot. I re-posted to the discussions board.)
I just can't seem to figure out how to turn the voronoi into legitimate geometry. I've seen this exact question posted a few times, but it’s never been successfully answered. What I'm showing here is far more angular than I’m hoping for. The mesh is too fine for weaverbird to have much of an effect. And I haven't cracked re-meshing. Btw, in product design, meshes are to be avoided like the plague. Embracing them remains difficult.
As for offsetsurf, in Rhino, if you do an offsetsurf to a solid body, it executes it on all sides creating another neatly trimmed body thats either larger or smaller than the original. This is how every other app I know of works. GH’s offsetsurf creates a bunch of unjoined faces spaced away from the original brep. A common technique for 3D voronois (Yes, I hit the voronoi overuse easter egg) is to find the center of each cell and scale them by this center. If you think about it, this creates a different distance from the face of the scaled cell to the face of the original cell for every face. As I've mentioned, this project is giving me serious headaches.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
Thank you for taking the time to reply David. Often we feel that posting such things is send it into the empty ether. I’m very glad that this was not the case.
And thank you for all of the work you've put into GH. If you found any of my input overly harsh or ill-mannered, I apologise. It was not my intent. I'm generally not the ranting sort. If I hadn't intended to provide possibly useful input, I wouldn't have written.
Cheers
Patrick Girgen
Ps. Any pointers on how to get a bit further on the above project would be greatly appreciated.
…
me of the dimensions that changed ( become Diagonal after they were Vertical or Horizontal)
I sometime use Record History in rhino for saving time, but when I change some points of curves or trim curves , I have problems with dimensions (see the two pictures below).
Problem 2 :
After trimming , only two dimensions should be changed depending on their place in changed curves . But what happens is that all the dimensions become crazy!!!!!!
I always use Aligned dimension in rhino. Now I know that dimensionsdo not exist in grasshopper. So I ask you if we have expertise in BV , C#, can we create a script for dimensions or is it impossible ??
If we can , I only need Aligned dimension.
I hope that I find or create a script that can define all points: start and end of curve ribs and create dimensions from grasshopper to rhino directly with or without the ability to change automatically .
Thank you
…
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
…
lName, signalValue, operationMode):
sigV=signalValue
if sys.version_info[0] == 3:
if type(signalName) is str:
signalName=signalName.encode('utf-8')
if type(signalValue) is bytearray:
sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
if type(signalValue) is str:
signalValue=signalValue.encode('utf-8')
sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
else:
if type(signalValue) is bytearray:
sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
if type(signalValue) is str:
signalValue=bytearray(signalValue)#<========This is line 1052
sigV = (ct.c_ubyte*len(signalValue))(*signalValue)
sigV=ct.cast(sigV,ct.POINTER(ct.c_ubyte)) # IronPython needs this
return c_WriteStringStream(clientID, signalName, sigV, len(signalValue), operationMode)
It displays the following error:
Program started
Connected to remote API server
Runtime error (TypeErrorException): unicode argument without an encoding
Traceback:
line 1052, in simxWriteStringStream, "C:\Program Files (x86)\V-REP3\V-REP_PRO_EDU\programming\remoteApiBindings\python\python\vrep.py"
line 70, in script
Any hint?…
nd the challenge "Building the Invisible: Informing Digital Design with Real World Data". Information about each Workshop Cluster can be found here:
Cyber GardensUse the ForceUrban FeedsSuspended DreamsInteracting with the CityAgent ConstructionAuthored SensingPerforming SkinsResponsive Acoustic SurfacingHybrid Space Structure Typologies
The SmartGeometry 2011 Workshop will take place at CITA http://cita.karch.dk/
Applications to attend the SmartGeometry 2011 Workshop in Copenhagen will close on 31st January 2011. General Conference registration will open within 1 month.
We hope to see you there!
****************************************************
Workshop 28th-31st March
Shop Talk 1 April
Symposium 2 April
Reception 2 April
These events follow the highly successful previous SG events in Barcelona 2010, San Francisco 2009, Munich 2008, New York 2007, Cambridge/London, UK 2006 and multiple preceding events.
Click here for more info...
This year's Challenge is entitled:BUILDING THE INVISIBLEInforming Digital Design with Real World Data
THE PREMISEVast streams of data offer a rich resource for designers. By incorporating external information into our design processes the autonomy of the design is challenged. User data, energy calculations, embedded sensing, material and structural simulation, human behaviour and perception, particle flows and force fields allows design to be situated and responsive. From the simulation of megacities to the solid modelling of material systems, design has the potential to be informed by the real. Design sits not separate from is environment but inhabits an ecological system, open, dynamic and interdependent, diverse, partially self-organising, adaptive, and fragile. Across scale and within time we now have the chance to instil architecture with an immanent intelligence creating new relationships between the user, the built and its ecosphere.THE OPPORTUNITYSystems theorists suggest that data is only a raw material. It can be differentiated from information, knowledge and wisdom. Understanding is multi-levelled: understanding of relations, understanding of patterns, understanding of principles. As digital designers our challenge is in harnessing the power of computation to assist us in informing our design process. Computers help us collect, manage and analyse the environment and inform us about an abundance of data. Our challenge is to use these inputs in a meaningful way to help us make better informed design decisions.THE AIMSG 2011 explores how the incorporation of real world data challenges existing design thinking. The SG 2011 workshop aim is to create physical prototypes of design systems to be exhibited in the SG2011 exhibition.
The SmartGeometry Group is a not-for-profit educational organization dedicated to the use of computational tools in architecture and engineering. SG brings professionals, academics, and industry together to explore the next generation of digital design. SG Workshops are non-platform specific, believing it is the methodology, not the tool, that matters.
…
Added by Shane Burger at 11:23am on January 6, 2011
s before here: http://spacesymmetrystructure.wordpress.com/2011/05/18/pseudo-physical-materials/)
If we want to design repetitive structures, we might want to be able to assign periodic boundary conditions to some structure to enforce translation symmetry. For instance, a long row of connected arches or vaults, which we want to be identical for ease of fabrication.
We could simulate this by adding many identical vaults in a row, and as we added more, the ones near the middle would get closer and closer to being identical. But they would never quite reach the point of being truly identical, even as we added hundreds of copies, and this would be very inefficient for large simulations:
One way around this is to take some points on one side of our structure, and lock them to some points on the other side of the structure using the new TranslationLock component:As far as the physics engine is concerned, each pair of points linked in this way is then actually just one point. It is as though the space itself has been wrapped around to join one side with the other.
Anyone who has played the game Portal will be familiar with a version of this concept (or for the older ones among you - asteroids).
Translation locks can be applied in any direction, and combined with any of the other forces. However, a few things to bear in mind:
-Be careful not to double up forces unintentionally. For instance, if you are adding a gravity load to the nodes of a catenary arch, and you want an equal load on every point, add only half the load to the locked particles, because when joined together these get combined (or equivalently you could add the full load to just one particle of the pair).
Similarly for springs - if you are smoothing a periodic tensile mesh using springs, be careful not to add the forces of the boundary springs twice.
-If you are using this for structural form-finding, remember that space we inhabit in the real world doesn't have these periodic boundary conditions (at least not on everyday scales!), so when you build it you will need to provide appropriate balancing forces at the ends.
-For forces which act on more than 2 particles, such as bending or Laplacian smoothing, you need to lock an appropriate number of particles on one side to those on the other side. Sometimes this may require adding 'ghost vertices'.
For example, here we model a periodic elastica curve:
This is achieved by applying a translation lock to the pairs shown by the red and blue arrows.
(note that the particle at the end of the blue arrow is 1 segment beyond the end of the curve)
One possible use of this tool would be the form-finding of periodic minimal surfaces (following the example of the great Surface Evolver by Ken Brakke). His site has many more great examples of these:
Generating these surfaces in a way that they remain minimal across the boundary would be very difficult without this periodic constraint.
Perhaps more interesting from a design perspective is the possibility to move beyond pure mathematical surfaces, and generate more free-form repeating units, but still preserving continuity across the boundaries, something like the work of Erwin Hauer:
…