he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
basis" problem ... all of a sudden - quite recently - a girl posted the MITESIGF (Most Important Thread Even Seen In Grasshopper Forums). She doesn't even realized that: she's novice:
http://www.grasshopper3d.com/forum/topics/array-1
4. Why this MITESIGF is MITESIGF? For 2 reasons:
4.a: Wooden pairs (Beams) Profile Curves (belonging in some tree) MUST allow individual control on a per "item basis" (OK, that's obvious) - see Images posted in the thread. No attractor (or any other "global" policy) can cut the mustard here (to tell you the truth this happens in 99% of pure engineering cases, but they appear very rarely in GH Forums - if at all, mind). If the profile curves are defined with 5 points (or 9 for the double thing) we need "on-the-fly" control over this Array (like the radii in your Sphere Manipulator) :
4.b: Critical Bottom-to-Top issues arise: Create a "global" topology (call it "parent") - the beams - and then place real-life "components" (call them "childs") that affect (most probably) the "parent". OK, that's impossible to do with GH/Rhino (peace of cake with CATIA/Microstation) but you can "approximate" things up to a point. Alternatively: you can "trigger" some interest from GH/Rhino developers if they have any AEC market(s) in mind.
Topic 4.a requires the master-to-slave slider thingy (iterate over branches (index slider:master) > reset the 5 values (value slider:slave) > modify them on the fly > save > increase/decrease branch > ...).
Other than that my definitions are far more challenging than this simple case ... but ... anyway ... long is the path (and hilly).
more soon.
best, The Troll
…
ails.
Some word about the mesh... (see Image_01)
I took a flat 4 points NURBS surface as imput (very easy, it defines the total area of my pavilion) and some points (that defines the contact with the ground).
Then I extracted a grid of points from the NURBS (Surface_Util_Divide surface) and compared 'em with the contol points, in order to associate to each grid's point its own attractor (Vector_Point_Closest Point).
Than I moved the points down. I used the distance from each point to its attractor (inverted) as amplitude for the vector of the movement, in order to say: the nearer you are to the control point, the more intense your movement will be. During this operation I've passed the distances' data list into a graph mapper (Params_Special_Graph Mapper), in order to regulate in a very intuitive and interactive way the shaping of my canopy.
At the end of the process I asked GH for a simple Delaunay mesh (Mesh_Triangulation_Delaunay Mesh). It's a very cool command, I believe!!!
Ok, now some word about the component, it's design and it's repetition/adaptation to the mesh...
(see Image_02)
I took the mesh and extracted components on first and faces's information on second. Then I selected and separated the vertexes (1°, 2°, 3°) of each triangular face into threee well defined list.
Then I re-created the triangles' edges. Please pay attention because it's not the same if you use output information from Delaunay components, because here we need a justapposition of edges where triangles touches each others.
After this work I joined the edges and found their centroid. At the same time I found the mid point of each edge.
Now the component... (see Image_03)
It' a little bit longer to describe: I'll try to be synthetic.
Substantially it is a loft from a curve to a point, repeated three times for each triangle (Surface_Freeform_Extrude Point). The point is an elevation of the centroid of the triangle (you can choose if the exstrusion has a single height or it's related to an attractor. In my case it was fixed). The curve is combination of things. There's an arch, which starts on the edge (there's an offset from the corner) end terminates on the same edge (on the other side, obviously). While it's generation the arch passes through a third point which belong to another segment. This last connects the mid point of the original edge (base triangle) with the centroid. The result is a kind of polyline, with two segments and an arch. If you go back to the image of the component that I posted probably you'll understand what I'm saying better than with the definition.
The posit…
ns. but first allow me to explain what i'm trying to do: i have a serial device i want to talk to, but i have to do it using some sort of handshaking. for instance, when i send a command/data, i need to wait for an appropriate response before sending another. i have used andy payne's general serial components from firefly, but i don't think they'll work for what i want to do, and in general, i want to know how to do this from scratch. i'm using the pyserial library to do the comm, and i can get it to work within one script. here's an example of a working (mostly) port open/close script (x=input param for baud, y=input param for port name, z=boolean input param for open/close):
import serialmyPort=serial.Serial()myPort.baudrate = xmyPort.port = yif z == True: try: myPort.open() except: print "Something went wrong. Cannot open port." if myPort.isOpen() == True: print myPort.name + " is open" if z != True: try: myPort.close() except: print "Something went wrong. Cannot close port." if myPort.isOpen != True: print myPort.name + " is closed"
this all works well and good. here are my questions:
1) I can open the port and then close it. however, if i try to re-open it, i get an access denied error. it seems rhino is holding the port open, as i have to re-start rhino to get it working again. i read through the discussions and didn't see any definitive answers to this problem. any advice?
2) I'd like to share this port with other components (or at least break up the functions of opening/closing the port and read/write, not unlike how the firefly components are organized), but i have no idea how to share an object instance between components. i did see that there is a sticky dict and tried to add myPort to it, but i kept getting errors in the other component when i try to use the object's methods. for instance:
Component 1 Script:
import serial
import scriptcontext
myPort=serial.Serial("COM4", 9600)
scriptcontext.sticky['myPort']=myPort
Component 2 Script:
import serial
import scriptcontext
myPort=scriptcontext.sticky['myPort']
print myPort.read()
but i get messages like:
Runtime error (MissingMemberException): 'Serial' object has no attribute '_port_handle'
any assistance would be greatly appreciated!!
best,
~BB~…
Introduzione a Grasshopper", il primo manuale su Grasshopper.
.
I corsi PLUG IT nascono dalla volontà di promuovere le nuove tecnologie digitali di supporto alla progettazione e condividere il know-how maturato attraverso ricerca, collaborazione con i più importanti studi di architettura e pubblicazioni internazionali.
.
Verranno introdotte le nozioni base di Grasshopper approfondendo le metodologie della progettazione parametrica e le tecniche di modellazione algoritmica per la generazione di forme complesse. Il corso è rivolto a studenti e professionisti con esperienza minima nella modellazione 3D e si articolerà in lezioni teoriche ed esercitazioni.
. Argomenti trattati:
- Introduzione alla progettazione parametrica: teoria, esempi, casi studio - Grasshopper: concetti base, logica algoritmica, interfaccia grafica - Nozioni fondamentali: componenti, connessioni, data flow
- Funzioni matematiche e logiche, serie, gestione dei dati - Analisi e definizione di curve e superfici
- Definizione di griglie e pattern complessi - Trasformazioni geometriche, paneling - Attrattori, image sampler
- Data tree: gestione di dati complessi - Digital fabrication: teoria ed esempi - Nesting: scomposizione di oggetti tridimensionali in sezioni piane per macchine CNC
.
Verrà rilasciato un attestato finale.
.
Ulteriori info e programma completo su: www.arturotedeschi.com e su www.samilolab.it…
r graphics get saved as 24x24 pixel images before they are put into the grasshopper application, which means the icons look like crap when you zoom in. This is the aforementioned problem that needs to be addressed in GH2. There have historically been two approaches to this issue:
Provide pixel images with several sizes.
Render vector graphics directly.
Option 1 is common for apps that do not have variable levels of zoom, such as Windows Explorer. When explorer shows file icons it either shows them in 16x16, 32x32, 48x48, 96x96, or these days, various HUGE sizes. As a result *.ico files allow you put in different images for all these target sizes. Since Grasshopper has variable zoom levels, this is not an ideal solution. Also, it requires a lot more work per icon.
Option 2 is becoming more and more popular as increased graphics speed now allows for the real-time rendering of vector graphics. Yet, you still need a renderer that knows how to draw vector geometry crisply at low sizes. All vector renderers I know just interpolate the geometry linearly and if a line happens to end up 'between pixels' it's just fuzzy.
I don't have hard and fast rules for the icons, but I try to adhere to at least these:
Keep a border of 2 pixels free around the icon content. So basically only use the inner 20x20 pixels rather than the 24x24 you're allowed. This is needed because the drop shadow needs to go there.
Only draw silhouette edges around shapes, not inner creases. Typically a 1-pixel line will do. I prefer to use a dark version of the fill colour rather than black for edges.
Loose curves can be drawn in 1 or 2 pixel thicknesses, depending on how important the curve is.
Try to avoid text in your icons (not always possible).
Stick to 1 colour family per icon, preferably per icon family. You can add highlights with another colour if you must, but too many hues make an icon hard to read (for the example the [Voronoi] icon, it has red, green and blue and it's a bit of a mess, on the other hand [Colour Wheel] has the full spectrum and seems to work quite well...).
Very roughly speaking, if there's both black and red geometry in an icon, it means the red is component input and the black is component output.
Drop shadows are pixel effects, applied to the 24x24 image. They have a blurring radius of 2 pixels, a horizontal offset of 1 pixel to the right, a vertical offset of 1 pixel to the bottom and they are 65% black.
When you use high contrast shapes (for example black edges on a light background) the anti-aliasing provided by vector renderers such as Xara or Illustrator won't be enough to make it look smooth. I'd recommend avoiding high contrast if at all possible, but if not possible then draw a 1-pixel line around the dark bits in 95% transparent black. This effectively extends the anti-aliasing range from 1.5 to 2.5 pixels and it helps make things looks smoother.
--
David Rutten
david@mcneel.com…
s levels of detail by subdividing a 6 sided cube mesh and projecting its vertices according to a referenced height map. This is one of the standard conventions for building full sizes planets. At the lowest level (0) the mesh planet is made of 6 pieces(each 32x32 resolution). The next level down (1) is made of 24 pieces... 6 divided by 4 = 24. Level (2) is 96 quads etc etc. The script will generate each quad at its sub-division level and compare edge vertices to neighboring quads. It will then make sure any shared vertices are in fact at the same projected vector. This ensures a planet quad with edge vertices that match.
The problems comes in texturing each quad.
If I build the quad as a nurb surface from points I can place the texture easily because each surface UV maps squarely to my texture map (which is also square).
If I build the quad as a mesh I cannot just apply the square texture to the mesh UVs. This is because when you unwrap the UVs from a mesh they will not unwrap like a nurb surface's UVs. Therefore to get the correct mapping I would have to manipulate each UV back to an evenly aligned array (which is 1024 points in a 32x32 resolution UV). Maya and blender have 'relax uv' and 'align UV' functions but they don't do the trick and manual corrections are out of the question. So why not skip the mesh method and use the nurb method?
I did this and there is a trade off. The nurb will accept the material texture I want with no other work on my end but when I export the object as an .obj rhino creates its own mesh to describe the nurb(with various unsatisfactory setting options). This works great up to a point because at some level the interpreted mesh will have vertices that do no match at the edges, ie .. creating visible seams in the mesh. The picture below is the nearly seamless planet at LOD(1) made of 24 quads, each with 32x32 vertice resolution and a 512x512 jpg texture running in Unity3d 5. It works but at close level there are seams. This will be resolved simply by having the next LOD(x) instantiate before getting close enough to see the seam but at core nerd level I want the seamless mesh.
So, I can make the seamless mesh but I can not realistically texture map it. I can also make the nurb surface from points and texture it at the expense of the edge vertices matching. I am at the split in the road but I want to have my cake and eat it too. Thoughts, comments, trolls...?
Thanks for reading =)
Footnote: For you pros I am not using seamless noise across the map I am using grasshopper to sew up my otherwise non perfect edges.
Other programs in the pipeline:
-WorldMachine 2
-Wilbur
-Photoshop
-Unity3d…
o Common - just like C#. But Rhino Python has a "Scripting Language Wrapper" which breaks commonly used taks down to simpler functions.
Here's a general Example:
Take a look at the code on this website http://wiki.mcneel.com/developer/rhinocommonsamples/addline). Generally it's Rhino Common code in three language to create a line. They look equally difficult.
But if you use Rhino Python Scripting you can use an simplified syntax to get the same result. It's very similar to Rhino Script.
The code would be:
import rhinoscriptsyntax as rsstart_point = rs.GetPoint("Get start point")end_point = rs.GetPoint("Get end point")line_id = rs.AddLine(start_point, end_point)
OK - No Error Tracking here, but still you can see that the syntax is much simpler. (And in the end you just have less lines of code you have to debug.
And the good thing about Rhino Python is, that you can mix these approaches. Once you reach a level where Rhino Python Script doesn't get you there, which by the way happens very rarely, you can still use the Rhino Common methods.
Also, in Python Sycripting 99% of what you probably would like to do is available as a "wrapped" script function.
Rhino Python Script is currently also better documented than Rhino Common for C# and VB.Net. If you have used Rhino VB Script before, these functions will be very familar to you.
I'm not sure, why it's currently a separate plug-in. I belive the reason is that Rhino 4 (which is supported by GH) doesn't support Rhino Python. Also it's currently WIP, so it needed to be updated more frequently than GH itself. In the long run (I believe) it might be integrated into GH as a general component
- Martin
P.S.: To use Rhino Python within GH is a little more tricky than my example - but nothing compared to developing C#
P.S.2 Here's the code with Error Tracking:
import rhinoscriptsyntax as rsdef AddLine(): start_point = rs.GetPoint("Get start point") if start_point is None: print "No start point was selected" return end_point = rs.GetPoint("Get end point") if end_point is None: print "No end point was selected" return line_id = rs.AddLine(start_point, end_point) return line_idAddLine()
…
well, very similar input data must result in wildly different hashes. For example, imagine we have an algorithm which computes hashes of text, and the hashes it computes are all numbers between 0 and 999. We then apply this algorithm to a piece of text:
"When Spring comes back with rustling shade" = 385
So far so good. Now imagine we change the text slightly, for example by removing a single "l":
"When Spring comes back with rusting shade" = 973
Minor change -> very different hash. There are of course way more unique texts than there are numbers between 0 and 999. This must therefore mean that a lot of text will result in the same hash. For example "When Spring brings back blue days and fair." may also result in a hash of 385. Because of the pigeonhole principle, there is nothing to be done about this.
Now for the tricky bit. Hashes are often used to validate executable code. Say your friend James at MI6 sends you a small program that will allow you to eavesdrop on Angela Merkel, and -over the phone- he tells you the hashcode for that application. You can then hash the application yourself, verify that it indeed results in the same hashcode and then you know you can trust the executable.
But now Jack from the FBI intercepts the email and adds a few sneaky lines of code to the original application allowing him to determine from your internet search history with up to 95% accuracy whether you like extra cheese on your pizza. The application has now been tampered with, it can no longer be trusted and you should be able to figure this out as it will no longer result in the same hash code.
But wait! Some hashing algorithms are more secure than others. MD5 is now officially considered to be 'hacked' and it is no longer recommended for doing naughty spying. Specifically, Jack will be able to inject his own code in such a way that it does not result in a different hash. Instead, the SHA family of hashers are to be used, as it is not yet known how to trick these hashers.
This is where the problem comes in, because apparently the US government has forcefully disabled the use of MD5 for all purposes. This is a shame because I use it to quickly compare bitmap icons for identicalness so I only have to store an icon in memory once. There is no security hole due to this, because I'm not hashing secure data. MD5 is somewhat faster than SHA, and since I have to hash several hundred icons on Grasshopper start, I opted for the faster one.
(Very) long story short; you're hosed. Grasshopper uses MD5; USgov does not like; Grasshopper does not run on USgov computers.
I'll do some testing to see if I can switch to SHA and then we can see whether or not that solves the problem. This however will take a while as I'm going on a business trip next week and have yet to prepare my presentations.
--
David Rutten
david@mcneel.com…
Added by David Rutten at 12:06pm on March 31, 2014