(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…
er ... but ... Autodesk has other plans in mind.
Given the opportunity the main reason to use a solid modeller is ... well .. the fact that when you arrive in a polysurface (in a surface modeller) this signals the end of the road whilst in the solid apps it's just the beginning.
That said the best solid thingy out there is Siemens NX closely followed by CATIA (SolidEdge and SolidWorks are both owned by these 2).
The best way to get the gist of these things is to find some friend who (hopefully) knows his onions and ask for a 5 minutes demo.…
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.
…
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…
ee. That said these things (masterminded by a certain David R) are not bad at all ... but if you write code that is "supposedly" transferable (kinda) to other CAD apps ... well ... I would strongly recommend the other classic nested C# collections.
2. The HLP method is one out of many: for instance for a better approximation of the required fitted plane we can use the divide Curve method etc etc.
3. GH components use (in most of cases) methods exposed in Rhino SDK > get the thingy and start digging into the rabbit hole. Of course David did some other components as well that use "less" classic SDK methods (if at all).
4. HLP is a classic approach to count the beans in nurbs curves. Of course I could use PolyCurves and recursive explosion blah, blah ... but here we are not after segments (at least at present time). On the other hand if that was a Faceted Dome (planar Polylines) ... well getting the nodes that way it could be an overkill (this means business for V2).
5. Mastermind some plane orientation policies in order to finish(?) the @$%@$ thing. For instance: Given Plane plane, define a Plane.WorldXY at plane.Origin and section these 2 > then get the cross product (sectionVector, plane.ZAxis) for the new orientedPlane Y axis etc etc (this presupposes that any plane Z axis points "outwards": use Dot Product and a center point as apex etc etc).…
i want to draw a line between them. The first point called FisrtPt is a fixed point from RHINO but the second point called SecondPt is the point which i want to be able to get its data from the UI.)…
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.
…
r even a geometry.
We want to develop open source architecture, and be able to reuse easily open source elements of projects shared by the community.
We are interested to display the 3D files in the browser, thanks to connection with external services like http://beta.speckle.xyz or others though at the moment it is not yet available.
When I discovered the grasshoper forum, I liked the fact that people talk very openly about their modelling problems and share definition files...
But I think Bricks could be a complementary publication mode, to find in a glance an element with all its geometry and a link back to the forum post to join the discussion.
Indeed when I work as an architect, I have not always the time to browse a forum with all its discussions to find a suitable element for my project.
I've quickly reposted 2-3 forums posts to test it out.
I would love to have your feedbacks on this new way of publishing grasshoper definition files and more globally 3d reusable geometries.
Here you can see a single definition or the list of definitions that can be classified at the left thanks to custom categories.
If you create an account and upload a few definitions and 3d images and files, you could also tell us, what you think of this process.
Sébastien
www.twitter.com/sebastien_lucas…