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
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
finite element line with
start point
end point
id
cross-section (optional)
local coordinate system (optional)
some property (optional)
some other property (optional)
additional settings (optional)
etc
Now in 99% of the cases, users will only specify the first 4 parameters and leave the others blank. I'm not a huge fan of to many inputs so to clean up the canvas/components, I thought about exposing the optional parameters only upon zooming in on the component.
So far I've sometimes added a secondary component with more inputs to specify a list of additional settings (similar to the "settings" panel that exists/existed in Kangaroo), but this I find rather messy.
Alternatively I guess I could quite happily live with exposing the additional parameters at the click of a button. This I can do with the ZUI as it is written? I still need to get my head round what's what in this happy world of the canvas' third dimension...
…
e the meaning or posting "ready" (kinda) solutions in response to something asked in the code related forum? (that could be rather ridiculous: Greetings code freaks: a user - that you've never heard of - asked this and I did that ... utterly ridiculous).
Now .. if a request comes from a novice either a component based solution or a freaky one ... well ... they have a very limited usage (if any usage at all) on a per se basis: because only time combined with a certain experience could yield the required ability to deal with issues before happening.
On the other hand ...to tell you the truth I believe that's far easier for a novice to get some "basic" programming skills and deal with his/her issues (who are in 99% of cases data management related ones) than to attack them via components.
On the other hand I believe that in the future (not the distant one) ... anyone involved in this ugly business AND not speaking some freaky language he could be rated as class D citizen (brave new world: here we are).
But that's a highly personal opinion (extreme to the max, as usual, he he).
PS: I don't think that the majority of posts here come from novices (yesterday a fellow user asked a very challenging thing: the one with the max rectangle).
take care …
u are posting in the wrong place.
99% of the posted questions in the general discussion forum are from novice grasshopper users who have lack of very basic knowledge.
In my opinion, the best response to these posts is providing the simplest (easiest to understand) solution to the problem, plus an explanation of why the definition wasn't working, plus some suggested fields of study.
On the other hand, you provide a very fancy solution, which gets the job done (and usually a bunch of other jobs as well), but there is 0% chance it will be comprehended or further developed by the OP...
This is the typical giving_fish_VS_teaching_how_to_fish debate.
As for the "please ignore me if you enjoy being primitive" argument, I am afraid it is not as simple as that. A post with 3-4 replies (which, in this case, would be 3 subsequent versions of your solution, plus an awkward "ehm, tyvm" from the OP) has a great chance of going unnoticed by anyone who could provide a gh solution...
And finally I have to point out that the right place for coding discussion is just a doorstep away.
cheers,
a not-pissed-off co-member of this forum …
Added by nikos tzar at 8:29am on February 15, 2015
ostly via C# because ... er ... the remaining 99% (how to do some real-life canopy and/or a real-life truss out of the relaxed line graph) is only doable via code - no ExoW/IL (so ... the 1% is indeed doable).
At first ... just double click the Kangaroo1 engine, halt the simulation AND ONLY THEN redirect the resulting line list to the ExoW/IL. As delivered neither is active.
Note: ExoW and/or IntraLattice MAY or MAY NOT work (each one has his own issues, but ExoW despite the glitches yields way better looking liquid stuff). So the liquid root may or may not be the holly grail that you expect (life sucks).
Note: As is delivered this only does a liquid node load bearing structure (ideal for Planet Utopia). Paint the thing black, do some proper pavement, populate with birds of pray, wait for the envelope def (that's freaky), put humans inside, lock the doors > massacre.
…
narity constrains as well. Let's over-simplify the case. Using that planar test data set shown we create a classic Adjacency Matrix that tells us what node is connected with what (you can use Sandbox for making the connectivity required in order to make the Matrix) :
Some other freaky thingy gets the Matrix, does freaky things (using recursion) and finally yields node indices that belong to a closed loop/cycle (see the forefront and the back). The other indices shown (describing "bigger" loops) are used for other type of stuff/checks:
More soon…
to perform the kind of merge I want. Basically:
I have a series of three integers, each representing a radius measure:
Radii[0-2]
I have a three sets of series of 3Dpoints, each set with ~100-400 vals:
PListOne[0-333]
PListTwo[0-333]
PListThree[0-333]
I want to link the data paths up so that the Radii form the first dimension of the array, and that the second dimension is the corresponding points set. So
Radii[0] = 500 (the radius)
Radii[0][0] = 50,75,0 (the first point in PListOne)
...
Radii[2][99] = 44,66,0 (the 100th point in PListThree)
This should be really simple, but I cant seem tog et my head around the right components to do it. I've attached a file with number series in place of the radii/points lists. If someone could show me how to merge the components in the manner above, it would be extremely appreciated.…
all the other rules.
2. No Flattening! use path shift / trim tree instead of flattening.
3. No Path Mapper! I have never met a data operation with the path mapper that could not be achieved through relative means.
4. No Simplify! It makes things *look* nicer but believe it or not those zeros are meaningful and shouldn't just be eliminated. If you are OCD about the way your paths look, then Path shift after every operation that introduces a new branch level (a new "0" at the end) IF AND ONLY IF you are sure that in the case of your definition the component will always function "1 to 1" - that is, for every single input there is only one output.
5. If you absolutely must flatten (to take a global bounds, or generate random values for every item, or whatever) be sure to Unflatten before continuing.
6. Design for the worst case - start with primary inputs in the most complex data structure your definition is likely to need to be able to handle (a tree for instance) rather than a single item.
If you follow the above rules, 99% of the time your definitions will respond appropriately to any change in upstream data structure. If you want an example of how this works in practice, post your definition and I can help find "relative" approaches to the "absolute" things you are currently doing. …
ss lots of questions,Hope guys show me some more different ways to figure out thoes kinds of problems,Thanks.
That is a construction project,the balconies should be overhang between 1 to 3 meters.
Program A is a patten consist of increasing balconies as the floors get upper.(In the picture is 29 at the first floor and ended with 2 more balconies for each floor, )Each part for a different floor,the twelfth floor have 29+(12-1)*2=51 balconies.
Questions From A,
A1:How to use the {(series)} to creat this atrium,As the floors increase the number of the balconies change by arithmetic progression.
A2:How to control the angle of the balconies,both the angle with floor and the balconies ending part.
Program B is use line to shape the commercial atrium,program A is more small pieces of rectangles.The {(TweenCrv)} command.
Questions From B,
B1:How to draw random points between the 1 to 3 meters region of the balcony,And those point form a shape also belongs to that region.
B2:Use a curve or other ways to control the changing speed of each floors' balcony.Right now the balcony is a Linear change.
Thanks for your Help.
Q1:Is there a way in Grasshopper to control the model to Modulus,less different unit parts to build such a Atrium.(For Exanple,only use 900mm and 600mm two different width of the Glass railings to bulid the model A OR B)…