work in both versions. I've tested them in Rhino 5 and they work on my machine. If your screen looks like CarloMaria's, can you double check that all of the .gha files and .dll's have been unblocked. To do this, right-click on each of those files (included in the installation folder) and select Properties. On the pop-up menu, at the bottom of the page, you should see a button that says Unblock (this only appears if they are currently being blocked). For some reason, downloading files off the internet causes some of the files to get blocked... and Rhino 5.0 is more picky about loading them in that instance. Let me know if that helps. Also (and I found this out recently from another user)... it's better if you don't have both 32-bit and 64-bit versions installed on your machine at the same time. It seems that sometimes this can cause a conflict too. When the other user uninstalled the 64-bit version, everything loaded fine in the 32-bit application.
There' haven't been any major changes to the OSC components. I did add a couple of features mainly to parse up some of the messages sent from other applications... notably from GyrOSC (http://www.grasshopper3d.com/video/gyrosc-kangaroo). Some of the messages are sent as lists of 4 values (like the quaternions sent in that app) or lists of 9 values (like the matrices sent using that app). Anyway, other than adding datatype parsers for these, I didn't change anything else about the component... so it should work as before. Let me know if you're still having trouble.
Cheers,
Andy …
s app NOR Rhino is a BIM thingy) I've decided to switch direction entirely: forget "bending" and concentrate on ways to have "some direct" (add some "" more) clue about wind forces.
V1 is a bit "basic" (no suction, not to mention the MIA remap force vector values thingy) : V2 does a lot of things more (and the test case is far more ... er ... "challenging": a twisted ultra ugly tower, what else? he he).
BTW: other than LBS "bending" ( pro-stuff for proper FEA SA apps: forget it) the most interesting thing is the air infiltration and water penetration min/max "suggested by building codes" values (a bit "elastic" in several countries) that ... are easily blown away if ... wind blows, that is. As Kim said: don't invest on cheapo curtain walls.
more soon …
r.
Jon has already done some very interesting stuff with regard decomposing matters using IFC schema (I'm not a strong admirer of any schema policy mind - for a variety of reasons).
Now the chaotic case:
1. This is deliberately fuzzy, faulty and chaotic in order to indicate the need (at least IMHO) for a next step with regard handling and visualizing (on a per individual data item basis, not on a per branch basis) data trees.
2. Why this Tree Manager future thing could boost GH up to an unseen level? Exploit the PDF attached - use Saved views and/or the Model Tree "decomposer" (file is greatly reduced in detail - only 1 out of 5 floors shown, no envelope stuff, stripped out of everything actually etc etc etc). Among a variety of things observe that there's transformations that are "selectively" applied whilst various components remain intact (in other words: invite existed "static" objects into the smart chaos) - this means that we need a far better control VS the series (of various type of data) that outline the solution of similar things.
3. What could/should do such a "visual" Tree Manager? Could he function within the existed "one Canvas for all things" environment? Do we need N "sub-canvas" (kinda the Views in any CAD app these days) to handle and visualize complex tree operations? Do we need control on a per data item basis? Do we need a re-mapper of a totally different kind? Do we need a Bake Manager? Do we need a Scenario (parameter combos stored etc) Manager?
Let's the debate begin
Best, Peter
…
imply lets you communicate with the chip in real time with other peripherals. In my case, I'm using the Xbox Kinect to read visual movements, assign a point ID to something like the left and right hand, translate its x-coordinate into a number, and have that number move a robotic arm servo. Sorry if this sounds like your upcoming robotic apocalypse.
My problem is that because my hand is always moving, it is continually reading the data in real time and crashing Arduino because it is continually processing the rotational distance (in degrees between 0-179). For example, if my hand was moving from 1 to 50 degrees, it's computing 1, 2, 3, 4, 5, 6, ..etc instead of 1 and 50 as two separate states.
Is there a way to have a component refresh its value in a certain interval? This would mean it could read my hand at different intervals and print a value at timed increments instead of doing it all in real time. A simple practice exercise would be to create a random component and have the component refresh so that every 1 second or so it would produce a different number. The app is essentially refreshing. I thought the Timer component worked, but I misunderstood what it's used for, and I don't think it does what I intend it to do.
I've attached some pictures to show what I'm attempting.
And a file to recreate the problem with a different instance.
Thanks so much for your help! …
er utilities for dealing with meshes , it also make ease of using voxels in Grasshopper .Yellow contains 40 components in four tabs : Deform , Refine , Utilities , Voxel . it has made easy to create various shapes by adding some deformer componenets that also work in all cordinates simultaneously. some of utility components are directly compiled rhinocommon methods in latest version of Rhino like: Mesh patch , Mesh fill holes so they only work in Rhino 6 . There's also been tried to enable most of subdivision schemes in Yellow like Kobbelt , Butterfly , Loop , ...
Yellow V1.0 makes use of the Plankton halfedge mesh library by Daniel Piker and Will Pearson, released under the terms of the LGPL license (https://github.com/meshmash/Plankton) .
Yellow has been tested in both Rhino 5 and 6 , but you may face minor bugs and you're so welcome to report them for correction. also any suggestion for making Yellow a better plugin is appreciated .
DOWNLOAD @ food4rhino…
Added by Amir Habibi at 2:19am on September 21, 2018
eaky things > thus I barely can see the point of having it (or maybe I must train the cats - in fact I'm doing exactly that these days [windows 7 - the older the better]).
Given the opportunity: happens that some top data retrieval gurus here and there are good friends (don't ask why). Well ... they are not that crazy with SSD since they claim that they are very prone to failures due to current fluctuations (unless you use some top dog UPS). Moral: stick to good old ("slow") stuff.…
mations we use a STANDARD thingy (Plane.WorldXY) VS any other plane (that's what the Orient does). This applies for blocks/cats/dogs/anything: meaning that if anyone in the present or the future uses such a "component" he knows the origin (especially if other CAD apps are used in parallel).
2. NEVER EVER make a thing (i.e. the profile) to be oriented "off center" (in the occasion domain start/end values for x/y). If you want to do that treat the destination plane accordingly. That way you build up a mentality were the "source" is standard - so to speak.
3. RHS (but HEB/HEA/IPN/IPE blah, blah) fillets are related with thickness (in real-life) ... therefore when you offset (always inwards: meaning neg values for counter clock wise closed curves) ... take into consideration that simple fact.
…
l console app that gets triggered after all the image tiles are exported and which will stitch them all together.
It runs outside the Rhino+Grasshopper process so it has at least 2GB of clean memory to operate in. If you're running on a 32-bit OS and the uncompressed image is larger than 2GB, this will still fail and you'll have to patch them by hand.
The intermediate images get written to the Temp directory, so they'll stick around until Windows deems them stale.
I also adjusted the bit-depth, if the output format is jpg or bmp then I use a 24 bits-per-pixel, png still uses 32 bits-per-pixel. Maybe this will solve the Photoshop loading problems. I cannot test this as my install of Photoshop consistently crashes on startup.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
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 .…