you still have left, what matters is how much memory Rhino is using compared to how much Windows is prepared to give it. On 32-bit systems this is usually 2, sometimes 3 Gigs. On 64-bit systems it's such a high limit that it's unlikely you've reached the limit.
You're low on or out of specially allocated memory/handles. Certain processes such as GDI drawing or winforms UI elements require a handle per instance. Every window, every label, every button, every slider, every bitmap... each one has a unique handle associated with it. Depending on the windows version, you either get a few, some, a bunch or lots of these handles to play with. When you start running out, usually the first sign is that the UI goes all wonky. Text disappears, fonts suddenly look terrible, parts of windows go missing. When all the GDI handles that are allowed have been claimed, the application will crash. The same may be true for OpenGL or DirectX handles, I'm not an expert on those.
There's an arithmetic error causing an overflow error. Sometimes these are handled gracefully and you get a proper crash or error message, sometimes they cause software to start accessing the wrong memory.
It's just some random crash that decides to manifest as an out-of-memory crash. This happens a lot and it makes these crashes very difficult to track down.
Since your images start going black before the crash, I'm tempted to think we're dealing with a #2 crash here. Maybe all these images we're saving out are hogging GDI handles and choking the system. If the handles or GDI objects assigned to Rhino keep going up and up as you write out these images, that'll be good supporting evidence. You can use the Windows 8 Task Manager to keep an eye on these values, or if you're running an older version of Windows I recommend installing Sysinternal Process Explorer in lieu of the Task Manager.
…
Added by David Rutten at 1:20pm on February 28, 2015
something (C# or components) that does a planer periodic nurbs - any shape imaginable in fact (shown a humble "figure of 8").
2. Imagine a capability (C# only: sorry) to create a "guide" (indicative/intermediate) surface. Basically: patch the nurbs from step 1 against a variety of user controlled curves/points/cats/dogs/you name it.
3. Imagine doing this U/v quad mesh thingy (we can fill the "gaps" [C# only: sorry] with the base boundary easily - especially when triangulating the mesh - but better work as shown):
4. Imagine calling the cavalry (Kangaroo) and instructing to do ... things on that "normalized" mesh.
5. What things? Well ... like equalize edges, "inflate", planarize the quads (extra WOW stuff that one), pull it against the "guide" surface [from step 2] or some other weird ideas of mine.
this is what V2 does (WIP).
more soon
…
file. A TSpline made thing in fact.
2. This atroci ... er ... hmm ... I mean unspeakable beauty uses an exo-skeletal load bearing structure hence is THAT big (BTW: Apparently nobody knows what thermal bridge is nor thermal expansion nor vapor condensation ... but these are "minor" details these holly blob days, he he).
3. 2 means that some nodes of that "grid" MUST "meet" floors in order to support them and (hopefully) withstand some seismic forces. BTW: A Richter scale 9 (for an hour) is all what this building actually needs (that's acid "humor").
4. The "smarter" way to do this is to spread "some" (i.e a lot) random points (Note: David's algo yields "evenly-spaced-points" within the limits of the possible) on the guide blob (a polysurface in fact).
5. Then ... you need some algo that tests proximity AND "adjusts" the Z in order to have some node points "co-planar" (Z) with the floors.
6. Then you triangulate all that stuff (the points, that is) using some decent Ball Pivot Algorithm (NOT Delauney) and you get a triangulated mesh that "engulfs" the guide blob. If you want some quads (as shown) this is also possible.
7. So you have edges ... i.e poly lines (per mesh face) and if you offset them ... you have "drilling" profiles that you must use against a second guide "thickened" blob for creating a continuously smooth exo-skeletal LBS (as shown). Of course Rhino (being a surface modeller) could require years to do this solid difference opp (or an eternity).
8. Rounding the "lips" of that LBS Brep is out of question with Rhino or GH (but it can been done very easily using other apps). Then you must "split" the Brep (in modules? in nodes + "rodes"? you tell me) in order to make it in real-life (what about forgetting all that?, he he).
9. Then, there's the glazing thingy that is made via quads meaning planarity. This is achievable with Kangaroo2 but is a bit tricky.
Moral: WHAT a gigantic pile of worms is this thread of yours...
more soon.
…
ruses could follow. Then cones are made and some other things.You can move the cones around via the equivalent slider. If the cones "touch" then ... well .. test it and see what's happening,
2. Interactive capability is not present: assume that you have 666 paths/cones > by what means you think that you could control what's happening? By adding 666 sliders? (not in a million years).
3. Rhino is amusing with regard the solid union Method. Depending on Karma you can get this:
or that :
4. Leaving aside N3 .. if the real-time response goes AWOL with just 8 cones what would be the situation if you add 666 cones? This is the reason for using K to solve this ... obviously with "some" compromises yielding "vault" stuff like this:
or like that (an Alien billiard (C)(Tm)(US patent pending) for planet Zorg):
Moral: stick to the Soap_opera approach.…
achieving some preliminarily/conceptual Academic solution that "may" qualify as "realistic". I have several defs that do similar stuff ... but this is an Academic forum and as you can understand a real-life solution would never appear here.
But let's forget the W task (truss out of relaxed mesh with depth, known as W in our trade). See for instance a step prior the "thickness".
General guideline:
1. Create a boundary (a BrepFace) and attempt to do some "reasonable" Mesh via Mesh Machine.
2. Mastermind a policy to manage anchors (naked and/or clothed vertices). This appears easy but is impossible without code IF you want to do it interactively.
3. Separate naked edges from clothed ones (as we do in real-life in tensile membranes etc etc) in order to apply different goal parameters.
4. Relax the mesh (K231 engine).
5. Either work with a "geodesic" structure (W = 0) or make a truss out of the mesh in 4. In either case decide the real-life system in use (say a Mero KK or some other).
6. Check clash truss members issues and interactively vary vertices in order to resolve them.
7. Create all the required connectivity Trees (VV, VE, EV).
8. Mastermind the skin solution (only for experienced pros: avoid at any cost that one).
My advice? Unless you are very determined ... well ... what about choosing an easier design task?
…
ge curves. The source code is available as usual on GitHub, https://github.com/mcneeleurope/ShortestWalk.
Here some examples of walks on predefined and custom grids.
With equilateral grids (1, 2, 3), the shortest walk on the network is the same both counting the edge length and the number of links. With these types of grids, there are often several solutions, one of which is selected by the ShortestWalk component. If the automatic search is used (no lengths are specified), then the A* algorithm is used and this will result in a path that departs "not much" (there are more rigorous definitions) from the straight path.
With the square grid (2), the geometry is called taxicab or Manhattan, and results in the total distance being the sum between the number of vertical steps and the number of horizontal steps.
The circular grid (4, 6) shows a case in which curve distance and "link distance" (number of edges that are walked, uses Dijkstra's algorithm) results is completely different paths. This example here selects the tangential road (4) or the "city center" (6).
Finally, Voronoi diagrams (5), Delauney triangulations (7) and random mazes or labyrinths (8) can be walked, searched and solved quickly, if a solution is possible, now even if there are multiple overlapping curves.
These examples show two-dimensional grids, but it is possible to also compute (weighted) walks on three-dimensional networks.
The compiled Grasshopper assembly (.gha) and the examples can be downloaded from Food4Rhino. Join the group if you want to get updates for new releases.
- Giulio________________
giulio@mcneel.comMcNeel Europe, Barcelona…
al other things:1. the minimum and maximum spacing between points (a certain 'x' and 'y');2. the jump between two next points - let's say it is always 2. So if a minimum possible spacing is 'x' (pt.1) then the next one would be x+2, then x+4, x+6 etc. until it gets to x+n=y (the maximum);3. how many maximum/minimum points there are in a row - when a division reaches the minimum 'x' or maximum 'y distance I want it to stay there for a while (e.g. [...] x+(n-2), x+n=y, y, y, y, y, x+(n-2), x+(n-4)...) Therefore, what I want to get after dividing the base curve are curve pieces of following lenghts/points on the curve with following distances between them (for example):x, x, x, x+2, x+4, x+8 . . . x+n, y, y, y, y, y, x+n . . . x+4, x+2, x, x, x, x, x, x, x, x+2, x+4 . . . x+n, y, y, y, x+n . . . x-2, x, x, x, x, x-2 . . . and so on and on.As you can see the amounts of x's and y's in a row changes (Rule no.3).I've tried this with graphs and attractor points and got nowhere in almost 2 weeks (though I'm a beginner).. Perhaps someone here will have an idea :)I'm attaching a picture of what I have in mind (may be easier to understand than what I wrote for some people :))Cheers…
ou will see all of the available components on a ribbon at once so there is no need to keep clicking drop down menus.
It's all about discoverability with GH. What if you're a beginner and don't know about the Create Facility (dbl click canvas) how can you find Extr?
Even if you hover over every component or use the drop down lists you will not see the name Extr appear anywhere.
Sure it makes sense that Extr is short for Extrude but it's also the Nick Name of Extrude to Point component
So you can easily miss the fact that one has a Distance Input verses a Point Input.
I think I made the move to Icons around about the move from version 0.5 to 0.6, possibly before. I initially thought that I would go back to text because I loved the mono chromatic look of the text but I soon realised that Icons were the way forward. The greatest benefit is speed. You don't need to digest and decipher every component (which is written 90 degrees to the norm).
I'm not saying you should move to Icons forthwith but at least consider that once you have a better knowledge and understanding of GH, Icons will set you free.
My top ten tips that I would highly recommend to anyone wanting to better themselves with GH.
1) Turn on Draw Icons
2) Turn on Draw Fancy Wires
3) Turn on Obscure Components
4) Use the Create Facility like a Command Line eg "Slider=-1<0.75<2" or "Shiftlist=-1"
5) Use Component Aliases to customise your use of the Create Facility eg giving the Point XYZ component an alias of XYZ will bring it up as the first option on the Create Facility as opposed to the other possibilities.
6) Try to answer other people's questions even if it's not relevant to your own area. By looking into solving a problem outside of your comfort zone and then posting your results it is very rewarding but it also lets you see the other approaches that get posted in a new light.
7) Take the time to understand Data/Path structures.
8) Buy a second monitor - There is nothing that can compare to real estate when working in Grasshopper.
9) Read Rajaa Issa's Essential Mathematics
10) Pick a panel in a tab on the ribbon and get to know every component inside and out and then move on. Start with the Sets Tab > List Panel…
Ladybug + Honeybee:
(Follow steps 0-4 for basic functionality and 0-9 for full functionality)
0. If you have an old version of LB+HB, download the file here (https://app.box.com/s/ds96em9l6stxpcw8kgtf)
and open it in Grasshopper to remove your old Ladybug and Honeybee version.
1. Make sure that you have a working copy of both Rhino and Grasshopper installed.
2. Open Rhino and type "Grasshopper" into the command line (without quotations). Wait for grasshopper to load.
3. Install GHPython 0.6.0.3 by downloading the file at this link (http://www.food4rhino.com/project/ghpython?ufh) and
drag the .gha file onto the Grasshopper canvas.
4. Select and drag all of the userObject files (downloaded with this instructions file) onto your Grasshopper canvas.
You should see Ladybug and Honeybee appear as tabs on the grasshopper tool bar.
(If you are reading this instruction on github you can download them from http://www.food4rhino.com/project/ladybug-honeybee)
5. Restart Rhino and Grasshopper. You now have a fully-functioning Ladybug. For Honeybee, continue to the following:
6. Install Radiance to C:\Radiance by downloading it from this link (https://github.com/NREL/Radiance/releases/download/4.2.2/radiance-4.2.2-win32.exe) and running the exe.
7. Install Daysim 4.0 for Windows to C:\DAYSIM by downloading it at this link (http://daysim.ning.com/page/download) and running the exe.
8. Install EnergyPlus 8.1 to C:\EnergyPlusV8-1-0 by going to the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/energyplus_download.cfm), making an account, going to "download older
versions of EnergyPlus, selecting 8.1 and running the exe.
9. Copy falsecolor2.exe (http://pyrat.googlecode.com/files/falsecolor2.exe) and evalglare.exe (http://www.ise.fraunhofer.de/en/downloads-englisch/software/evalglare_windows.zip/at_download/file) to C:\Radiance\bin
10. You now have a fully-working version of Ladybug + Honeybee. Get started visualizing weather data with these video tutorials (https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDXNep1O).
After I've done all the above I followed this video
https://vimeo.com/96155674
And everything works well.
…
nted" in space (at instance definition creation phase): indicates the obvious fact that if garbage in > garbage out (try it).
2. Load the GH thing. Task for you: Using Named Views locate the points of interest as described further and make a suitable view. That way you can navigate rather easily around (hope dies last).
3. Your attractors are controlled from here:
The slider in blue picks some attractor to play with. You can use this while the K2 is running.
4. Don't change anything here (think of it as a black box: who cares how it works? nobody actually):
5. Enable the other "black box": job done your real-life stuff is placed:
6. Enable the solver: your "real-life" things start to bounce around:
7. Go there are play with the slider. A different attractor yields an other solution:
8. With real-life things in place if you disable the C# ... they are instantly deleted and you are back in lines/points and the likes:
9. Either with instance definitions or Lines/points change ... er ... hmm ... these "simple" parameters and discover the truth out there:
10. Since these are a "few" and they affect the simulation with a variety of ways ... we need a "self calibrating" system: some mini big Brother that does the job for us. Kinda like applying safely the brakes when it rains (I hate ABS mind).
NOTE: the rod with springs requires some additional code ,more (that deals with NESTED instance definitions) in order to (b) bounce as a whole and at the same time (b) elongates or shrinks a bit.
More soon.
…