ot animating a slider 0 _min, max_1000But i would like to animate an Evaluate curve component, wich animates the meshmin 0_max 1, from a reparametize curve
I´m attaching an image
I´m not sure what i´m doing wrong
But it goes something like this
Initial Value: 0, the starting value of the slider that animates the mesh
End Value: 1 the ending value of the mesh animation
Starting Keyframe: 0, i want 3ds max to animate from keyframe 0
Ending Keyframe: I need 3ds max to finish at frame 100, 3 secs.
Slider: is moving t value of an evaluate curve component
If i export it
Centipede overwrites each obj file
I hope you can give me a hand, ip´m sure my values are nor correct or something
cheers
m…
and pioneers in the fields of architecture, design and engineering.
The event will be in two parts, a four day Workshop 15-18 April, and a public conference beginning with Talkshop 19 April, followed by a Symposium 20 April. The event follows the format of the highly successful preceding events sg2010 Barcelona, sg2011 Copenhagen, and sg2012 Troy.
The Challenge for sg2013 is entitled Constructing for Uncertainty.
more information
CONSTRUCTING FOR UNCERTAINTY
Design and construction, increasingly more information-centric, must also address issues of computational ambiguity. As users, we must drive computational systems to assume new roles and subsume more domains to meet the needs before us. We must consider issues of time and permanence within a cultural and technological landscape of constant change - our most grand gestures will define our environment physically, culturally and economically for generations.
Where historic responses to uncertainty constructed a simplistic environment with basic mechanisms for aggregation and subdivision, we augment these with smart, dynamic and interactive systems. Where modeling capacity has been limited, we now take advantage of vast amounts of data collected by sensing and scanning devices, processed by cluster or grid computing, filtered by machine learning algorithms into patterns, and communicated by ubiquitous devices. Our past data trajectories can guide us in discovering robust and tolerant design systems to meet the demands of a malleable present and uncertain future.
sg2013 Constructing for Uncertainty: transition computational design from the hard space of the ideal to the soft reality of an uncertain built environment.
more information
sg2013 WORKSHOPSThe 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.
more information
sg2013 TALKSHOPAfter four intense days of innovative work, 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.
sg2013 SYMPOSIUMThe Symposium will examine the year's Challenge. Invited keynote speakers will showcase 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.
sg2013 SCHEDULECall for Clusters 26 September 2012Cluster Proposals Due 4 November 2012Workshop Applications Open November 2012
Workshop 15 - 18 April 2013Conference 19 - 20 April 2013
More information about the event can be found at smartgeometry.org…
Added by Shane Burger at 10:35am on October 25, 2012
can toggle these modes from either the Canvas Toolbar, the Remote Control Panel or via shortcuts Ctrl+1,2 or 3
These are pretty self explanatory so I will keep it brief:
No Preview will completely switch off the preview of the Grasshopper Objects in the Rhino Viewports.
Wireframe Preview similar to Disable Meshing will disable any render meshes but keep any curves or Edges visible.
Shaded Preview will shade the preview...
There are two more Icons in this section of the Display Menu:
Selected Only Preview
Preview Settings
Also available on the Canvas Toolbar.
Selected Only Preview is a useful feature for following what your definition is doing at stages along the process without having to switch all previews off and manually turning individual ones back on as you go.
Without Selected Only Preview Toggled
With Selected Only Preview Toggled:
Preview Settings is the area within Grasshopper where you can modify the colours - including transparency - Grasshopper uses to display objects in the Rhino Viewport.
The first thing you should do before altering any settings is to Drag the Default Colours onto the green plus sign to add them to the Presets. This will enable you to restore them easily.
For future reference the default settings are:
Normal = Hue: 0º, Sat: 100, Val: 59, A:100
Selected = Hue: 120º, Sat: 100, Val: 59, A:100
Apart from accounting for taste this feature is particularly useful for anyone that is colour blind[2]:
The way to restore a colour from the preset list is to drag it from the right hand panel to either the Normal or Selected option on the Left
[2] There is a very interesting discourse topic on the McNeel Forums about Red/Green Colour Blindness.
work carried out by Jørgen Holo
…
hat said, the processes that would benefit most from it in Rhino and Grasshopper actually lend themselves remarkably well to multi-threading. Things like Intersections, Meshing, operations on individual items in arrays would all benefit since they involve a lot of repetition where one iteration does not depend on the previous one.
Rhino4 was not designed to be threadsafe, and there were places where it was not possible to thread certain tasks. For example, imagine the Contour command. You'd think that it would be a piece of cake to thread that, you assign the first 25 contour intersections to core 1, the next 25 to core 2, the next 25 to core 3 and so on and so forth. But as it turns out intersecting a Brep and a Plane requires Rhino to build a spatial tree of the Brep first (assuming it doesn't exist yet). These trees vastly speed up a lot of operations and they are created lazily, meaning they get created the first time they are needed. Now we suddenly have four threads all trying to run a Brep Plane intersection and all trying to build the same spatial tree at the same time. This cannot end well. So in Rhino5 we made sure that when the spatial tree is getting build, every other thread that tries to access the Brep gets put on hold until the tree is done.
Then there's problems that the Intersection function might store temporary data on the Brep during the intersection, which makes threading intersections on the same Brep an absolute impossibility.
Then there's the even worse problem that the Intersection function might store temporary data in a static cache, which means you cannot run the function more than once at a time, even if it's on different Breps.
In Rhino5 we tried to rectify all of these problems. I think we got most of them by now.
When Grasshopper switches to Rhino5 for good, we'll start looking into threading a lot more seriously, not in the least because we'll also switch to .NET 4, which has some pretty cool mechanisms for writing decent MT code.
Until then, we'll have to stick to good old fashioned optimization. Christoph's problem was that it takes 12 minutes to open a file. Even if you thread that and you get 100% efficiency (which you won't, there's always additional overhead when threading) it would still take 3 minutes if you have 4 cores. It's an improvement sure, but not much of one. I'd like to know exactly where all that time is spend, then maybe we can remove specific bottlenecks.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
rld.wolfram.com/EnnepersMinimalSurface.html
when i type the equations for z,y,z it says a syntax error so i obviously do not understand how to construct an expression. (screen capture attached)
Any help/explanation of using this function would be greatly appreciated
thanks so much
Capture.JPG…
how it look like:
Thanks again!
import rhinoscriptsyntax as rs
#flag 1 = intersecting, or one inside another#flag 0 = not intersecting, or just touching each other
def checkintersection(obj,brep,tol): test = rs.IsObjectInBox(obj, rs.BoundingBox(brep), test_mode=True) insec=rs.IntersectBreps(obj,brep,tol) if test == True and not insec: flag = 1 elif insec: insec=rs.IntersectBreps(obj,brep,tol) #if one object is inside the other flag1 = minDistanceTwoBreps(obj1, obj2, tol) flag2 = minDistanceTwoBreps(obj2, obj1, tol) rs.DeleteObjects(insec) if flag1 == 0 and flag2== 0 : flag = 0 else: flag = 1 return flag
def minDistanceTwoBreps(obj1, obj2, tol): if (tol is None) or tol < 0.0: tol = rs.UnitAbsoluteTolerance() pt1 = rs.SurfaceVolumeCentroid(obj1)[0] pt2 = rs.BrepClosestPoint(obj2, pt1)[0] dist = 100 precision = 3 # the larger the number - the more precise the distance i = 0 while (dist > tol) and (i < precision): pt1 = rs.BrepClosestPoint(obj1, pt2)[0] pt2 = rs.BrepClosestPoint(obj2, pt1)[0] dist = rs.Distance(pt1,pt2) i += 1 if dist <= tol: flag = 0 else: flag = 1 return flag
obj1 = rs.GetObject("select object 1")obj2 = rs.GetObject("select object 2")tol = rs.UnitAbsoluteTolerance()
flag = checkintersection(obj1, obj2, tol)
print flag…
ion of surfaces and/or "solids" : it's a very complex assembly of "components" either bespoke or widely available in the market. This demo combo summarizes the "common" cases (but the insulation for the opaque parts is WRONG 100%):
2. Contemporary trends (a bit of nonsense) point towards "liquid" forms. These ARE NOT made via "classic" linear systems. Very few actually can do it (I mean: do it yielding a building that doesn't leak]). Here's a totally wrong take on that matter from a very reputable Swiss facade maker:
And er ... hmm ... this :
3. Facade systems (curtain walls, that is) are classified in 4 classes: (a) the good old known humble stuff like the one shown in the first image (b) semi structural [yes], (c) structural [NO] and (d) planar frame-less systems.
4. Designing any proper facade is impossible with Rhino/GH: you'll need totally different software apps to do it - in real life - despite what most people believe/hope/wish.
5. Designing anything without a proper bottom-top approach (I.e. : first do the pistons then the engine) is the best recipe for not becoming (ever) a pro .…
Dogs) i.e. the Holly Grail in Engineering/Design ... although rather easy is 100% impossible without code (especially when you need to manage "solution variations" (alternatives) and recall them any time) ... but I have a strong feeling that you wouldn't be able to handle this: expert only territory. Make a test: get a flat 2d grid of points (a Tree with a single dimension) and attempt to modify Z in points that you choose on a per point basis.
"Impossible" eh?
3. Without Mesh Machine areas like this:
would buy you a ticket to hell (one way).
All in all: doing this properly (The interactive part whilst checking valid typologies PLUS this, this and that) IS NOT a task for a novice by any means. I would strongly suggest ... er ... hmm ... the Soap Opera approach (but this also requires code if a non rectangular grid is used as a "mesh template").…
that both the ASHRAE and European Adaptive models were derived from surveys of awake occupants. While the topic has not been investigated as well as it should be, the few adaptive-style surveys of sleeping occupants that have been conducted show that people tend to desire significantly cooler temperatures when they are sleeping as opposed to when they are awake.
Notably, Chapter 8 of Humphrey's recently-published book on Adaptive Comfort (https://books.google.com/books?id=lOZzCgAAQBAJ&printsec=frontcover&dq=Adaptive+Thermal+Comfort+Foundations+and+analysis&hl=en&sa=X&ved=0ahUKEwi6npqSi__KAhUJMj4KHf7SCXMQ6AEIKjAA#v=onepage&q=Adaptive%20Thermal%20Comfort%20Foundations%20and%20analysis&f=false) provides some interesting insights into this. In a 1973 survey, Humphreys found that the quality of sleep started to deteriorate at temperatures above 24-26C regardless of the time of year and that there was no clearly-determinable lower limit to comfortable sleeping temperatures (in other words, people were fine at 12C if they were given enough blankets). He surveyed only British occupants who were sleeping in traditional beds with mattresses and a wide range of blankets. This is important because the nature of the findings is such that the comfort temperatures would be very different if the survey participants had been sleeping in a hammock or in closer contact with the ground (both popular practices for a number of cultures living in warmer climates). Traditional mattresses cut the ability to radiate body heat in half as compared to a standing human body and I would venture a guess that this is a big reason why much cooler temperatures are desired while sleeping on mattresses as opposed to standing awake/uptight.
So for your case, if you want to account for a time of the day that occupants are sleeping on mattresses, I would change the comfort temperature for this these hours down to 24C. Otherwise, if you are trying to show the comfortable hours of awake people in your space, your current 100% comfortable nighttime hours are a better estimate. I have also noticed that nighttime temperatures become comfortable in extreme weeks of hot/dry climates. This is what is happening in this extreme week simulation of Los Angeles' San Fernando Valley here:
https://www.youtube.com/watch?v=WJz1Eojph8E&index=3&list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
I will put in the ability to set custom values for comfort temperatures into the Adaptive Comfort Recipe soon so that you can test out a 'sleeping comfort temperature' if you would like. I have created a github issue for it here:
https://github.com/mostaphaRoudsari/Honeybee/issues/486
I was not so convinced by Nicol's argument about humidity on those pages as I was when I saw the correlations of both operative temperature and effective temperature to surveyed comfort votes in real buildings. Humphreys shows these correlations on page 106 of the book I linked to above. Notably, the correlation of Effective Temperature to comfort votes (0.257) is slightly worse than the correlation of just Operative Temperature (0.265). In other words, trying to account for humidity actually weakened the predictive power of the metric. This difference in correlation is not so great as for me to discount an Adaptive comfort model based on Effective temperature (as deDear once proposed). However, the correlations of PMV (0.213) and SET (0.185) to comfort votes are so poor that I now use the PMV model only with great caution.
This reason for the decreased importance of humidity may be multi-faceted, whether it's Nicol's explanation or another. Still, the data suggests that we are probably better off ignoring humidity when forecasting comfort and should only consider it when evaluating conditions of extreme heat stress where people's primary loss of heat is through sweating.
-Chris…
e point in each pair that has the lowest Z value (then later the highest Z)... The problem is the intersections are not returned sorted by Z, sometimes the lower point is first in the list, sometimes last. So I need to sort those pairs of points by Z value.I noticed the sort points component does not have any inputs for sort criteria... RhinoScript SortPoints allows you to sort by:
blnOrder
Optional. Number. The component sort order, where:
Value
Component Sort Order
0 (default)
X, Y, Z
1
X, Z, Y
2
Y, X, Z
3
Y, Z, X
4
Z, X, Y
5
Z, Y, X
Will we get something like this in GH? For now I think I can manage to analyze the Z for each and re-order the points, but a more comprehensive point sorting tool might be nice... no? Or did I miss something obvious? --Thx, --Mitch…