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! …
, HVAC, blah blah).
BIM is NOT a parametric process at least having in mind graphical editors the likes of GH (or stuff the likes of Generative Components): it's a holistic data management approach. Some concepts used in BIM apps (for instance in AECOSim etc) the likes of "walls"/"openings" etc are "parametric" in the sense that allow auto perforation of this with that. On the other hand AECOSim is feature driven (since Microstation works in that "mode" as well) ... a thing that complex things even more with regard what is actually "parametric" and what not.
BIM is as good as the meta data structure is (especially the spec related aspect - Goggle MasterFormat and the likes). BIM AEC apps are notoriously incapable to work (without a lot of lines of code) with proper RDBMS. On the other hand Bentley Systems ProjectWise ... well ... but that's another animal (by no means a topic for the inexperienced).
In descending order or importance a contemporary AEC practice should use:
1. A general information "controller" like ProjectWise (who said/did what/when/why).
2. A Specs (say CSI - not the TV soap opera) management app.
3. Several Meta data RDBMS.
4. A BIM suite of apps.
5. Optionally some parametric thingy.
PS: For AEC ... when inviting the parametric thingy to the party you have only 2 options:
ProjectWise + AECOSim + Generative Ciomponents (my choice).
?? + Revit + Dynamo.
…
Or if this doesn't work the the lines who's end points Y value doesn't match
5) join all remaining curves. this gives you polylines for each row.
6) From these you can extract control points that will be on differrent branches
i would demonstrate this but i'm stuck watching the wedding at a friend's and until mcneel makes a rhinoid with gh app you'll have to wait 'til later…
omponents and Revit means Dynamo.
Both are masterminded by the very same fella (Robert Aish: an ex Bentley R&D head, then Autodesk paid more [life sucks]).
AECOSim eats Revit for breakfast but has a far steeper learning curve ... meaning that the masses would opt for Revit.…
sites the likes of Code Project etc etc) that may fit to your workflow/goals. Also the available literature/printed manuals/e-manuals/books etc etc.
3. Take into account the quality of the available editors (like VS etc etc). That said the "build-in" GH editor is a bit of a crap (but it's OK for smallish/not complex coding).
4. Most importantly: // computing is the holly grail these days (and it would become the standard in the years to come: either via trad CPU cores or via CUDA/Tesla type of stuff)... thus take into account ... well ... the obvious.
BTW: If 1 is true and there's some workflow around that involves many apps ... try to write code that is as "GH neutral" as possible.…
tructures)
Bad news: real-life AEC trusses are far and away from lines.
Ugly news: Rhino is NOT an AEC app by any means nor it would ever be. For AEC app I mean the known 3 (Allplan, Revit and my favorite: AECOSim) and/or proper MCAD apps (like CATIA/NX). In plain English : without exporting (meaning (a) bake in nested blocks + (b) export via STEP) proper structured data (assembly/component) this WIP case is absolutely useless.
why may you ask.
well ... trusses are made with numerous shop drawings like this, that's why:
more soon.
best, Peter…
some weird engine, you know, he he) IS NOT like designing plain vanilla AEC things.
Therefore features/calculation methods/capabilities as found in MCAD apps (considered off topic by many in our trade) are mandatory for certain types of designs.
Anyway and if we forget FEA stuff, currently I have 3 C# goals:
(1) master the art of controlling the placement of existed blocks in GH defined topology(done),
(2) master the art of baking blocks(done) and
(3) master the art of baking heavily nested blocks that NX/Catia can understand (progress is slow).
…
te and anything you can remove is a benefit (I also find it looks much better, but this is personal taste).
Of course, there are far fewer things going on at the screen on a phone than in a computer. It's very possible this doesn't translate well into an interface for a software like Rhino. I've also had no problems using Windows 8 and a few simple 'metro apps' but these are simple apps that don't compare the complexity of CAD software.
Even Microsoft hasn't gone full metro in the desktop. They did however remove a lot of superfluous shadows, bevels and effects and it looks much better than in Windows 7 in my opinion.
In every new version of Windows I always resented they just added new effects and decorations to the UI without adding much to usability and only slowing down the system. I've found it strange that for the first time that I think they are moving in the right direction Microsoft receives the biggest backlash ever for it. Apparently I have a very heterodox view on good UI and when people were complaining on the superfluous decorations of previous windows installments they didn't really mean it, they just had an axe to grind with the company.…
r visual programming tools in the games world. MS's Kodu, looks interesting. Kismet and Visual3d look even more interesting..... mainly because they are more 'interactive' or 'reactive', rather than DAG-based.
Seems like the evolution path for GH-similar apps is:
1. base 3d or CAD app based on C/C++ code.
2. Add scripting language interface
3. Add some kind of visual interface
4. Add graph sorting / propagation engine
5. Re-jig base 3d or CADD app to make managed/interpreted scripts run faster, multi-threaded.
6. Add dynamic typed language, DLR stuff
6. ....
6. Add constraints solver...?
7. Rebuild CAD display engine to be procedural at the GPU level?
Seems like there are available tools for converting scripts into some kind of flowchart. There are even visual debuggers. MS even has something called the 'Debugger Canvas'. Spreadsheet constraints.
Seems like the time is ripe for lots of new apps like GH.
…