to run at full screen. I've gone as far as using an iPad to use as the second monitor via AirDisplay (which actually works really well) but have never been satisfied with any setup that required you to look back and forth as if at a tennis match all day long.
Not long after first using Grasshopper 3+ years ago I've had the desire for a "Live Viewport" component that would allow a live image of the 3d geometry being generated directly in the canvas. Every once in a while I search the forums with the hope of finding a solution, but always come up empty handed. Someday this might exist although for now I have found what might be the next best thing to a native "Live Viewport" component and its enabled with a small app named Sticky Previews. This app uses the task bar preview feature within Windows 7's aero interface to create custom, floating preview windows from any open window currently running. I've only just discovered the app, but it seems to do the trick and has been stable and problem free so far. -- I will post an update if I find out that I might have spoken too soon. The install allows for a 30 day trial and is $15 bucks to purchase. I just found the app and don't know anything about this group that created the app. If you happen to know of them, Id be curious to find out more.
divided windows, cramped and slow;
unified window with floating rhino model preview;
link to the apps webpage;
http://www.ntwind.com/software/sticky-previews.html
Also works with other apps;
and the about me page screen shot;
…
Added by Tyler Selby at 11:25pm on November 26, 2012
sive:
It is using up all or a lot of the cycles on the app UI thread. So there's no computing power left over to handle mouse events, keyboard events and paint events.
It is using up more memory than the computer physically has, so Windows starts paging (i.e. using the hard-disk as a memory space). Since disc read/write access is orders of magnitude slower than RAM read/write speed, this will slow down everything.
Some other application is using a lot of computing power/memory and Windows deems that app more important than Rhino.
8GB might not be enough if Rhino needs more than 5GB or so to run. Windows will take up ~2, other apps will take up ~1 unless they are also doing heavy lifting, so you have about 5 left over for Rhino+Grasshopper+++. It is not difficult to make Grasshopper use lots of a memory, but its also not demanded. If you generate 5000 complicated Brep objects, they are going to have to be stored somewhere.
However I cannot comment from here about whether your problem is processor or memory related, or both.
…
it within the same smart umbrella? Or put it differently: is it worthy to exploit/consider/evaluate GH methods and development orientations that could "approximate" Utopia?
Let's split the case into segments:
The parametric part thing (although critical) is complex and rather beyond the scope of GH. Affects Rhino far more than GH. That said Microstation has 3 levels for doing this (but forget Microstation and/or Gen Comp).
So for a start we can focus in GH acting as a "composer" in 3D place of all the required (hopefully real) parts for the job. Parts must be nested AND readable as such by an external AEC app.
I'll post here (soon I do hope) all the parts that are required for assembling this. I mean individual static "blocks" that we assume (wrongly) that remain static: I mean we presuppose that the whole GH geometry is fixed (thus this is really a smart sketch of some sort) and no further changes are on schedule (that MAY affect parts).
That said I prefer an incomplete Utopia (one thing that "does" it all, or it thinks that does it) than a myriad of individual apps that take input one from the other and promise the Holly Grail (and/or delivering it). The core reason that I use Microstation as my basic platform is exactly that (obviously with a certain price to pay: bugs, shortcomings, wrong concepts in places etc etc etc).
Best, Peter
…
loop is a simple component
to iterate generative shapes with Grasshopper®
http://antonioturiello.blogspot.com/
RHINO OFFICIAL BLOG
FOOD4RHINO PROJECT
AEC-APPS.COM REVIEW
r this or that etc etc).
3. I would strongly advise to use some decent feature/dimension driven CAD app in order to create families of concrete deck/beam(s) profiles "manually" (the good old way PLUS recording history and using parameters for the steps taken). Find a friend who knows, say, AECOSim and ask for a small demo on that matter (specifically ask what DDD is [Dimension Driven Design]). Then you can have these in Rhino/GH, define some topology, do the "solid" and if 1M of decks/beams are required rather use instance definitions and plane to plane transformations (that's what the Orient component does) instead of creating 1M clone objects.…
n splitting curves and then join them to create the region; but I'am looking for a more straightforward solutions. 3- I know some plugins like clipper could do this, but I'm looking for more flexible solutions.
4- I tried Brep[] CreatePlanarBreps(IEnumerable<Curve>) in ghpython, but it doesn't work.
…
he two, including project information, materials, etc.
I'm looking at embedding Ecotect information within VB (or possibly C#) components and was looking for the most efficient connection.
It looks like I have 2 main options:
1. XML database-centric model of which both GH + ECO write to the XML document.
2. LUA scripting from within GH and ECO.
XML would be the first choice as it seeks to contain data purely outside of both apps, however, the redundant code that ECO needs to read / write gbXML files may be a headache to script the content.
Another question I had was to whether I can populate data (such as weather, location, materials, etc) directly from the Ecotect libraries (.lib) to feed into the GH components or would I need to decompile these first.…
(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
of memory and can thus create far larger images then when it has to share memory space with an application like Rhino.
Combining images is not difficult if you know a bit of VB/C#, so I can help you out if you tell me exactly what you'd ideally need. Whether as a grasshopper script component or stand-alone app.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…