o express my gratitude. I've been experimenting with your definitions (and still am), but let me extend my question.
Actually what I'm trying to achieve, is to recreate another project by Andrew Kudless, the spore lamp (I mentioned the Chrysalis at the beginning just because of the animation, which wasn't included in the Spore Lamp presentation).
Basically the spore lamp seems to me to be something like a preliminary study to the Chrysalis III project (I think it's a similar approach).
Andrew stated on his site that he used kangaroo for this project, so the Spore Lamp consists in my opinion either of a relaxed voronoi 3d diagram (b-rep, b-rep intersection) on a sphere which then has been planarized, or more likely it is a sort of relaxed facet dome.
The trick is to:
1. obtain a nicely-balanced voronoish diagram (or facet dome cells)
2. keep each cell/polyline planar (or force them with kangaroo to be planar) in order to move scale and loft them later on.
Here is what I have by now. (files: matsys spore lamp attempt)
That's the closest appearance that I got so far (simple move scale and loft of facet dome cells with the amount of transformations being proportional to the power of the initial cell area: bigger cell = bigger opening etc.) - with no relaxation of the diagram. But it's obviously not the same thing as the matsys design.
Here are some of my attempts of facet dome relaxation, but well, it certainly still not the right approach, and most importantly I don't know how to keep or force the cells to be planar after the relaxation.
1. pulling vertices to a sphere - no anchor points. That obviously doesn't make sense at all, but the relaxation without anchor points gives at the beginning a pattern that is closer to what I am looking for. (files: relaxation 01)
2. pulling vertices to a sphere - two faces of the initial facet dome anchored (files: relaxation 02)
3. pulling vertices to the initial geometry (facet dome) no anchor points (files: relaxation 03)
The cell pattern of the lamp kinda looks like this:
you can find it here: http://www.grasshopper3d.com/forum/topics/kangaroo-0-095-released?g...
Done with Plankton (of course without the "gradient increase" appearance), but in fact not, I took a look at Daniel Parker's Plankton example files, and it's not quite the same thing. Also the cells aren't planar...
The last problem is that during the relaxation attempts that I did, the biggest initial cells became enormous, and it's not like that in the elegant project by Andrew Kudless, that I'd like to achieve.
So to sum up:
Goal no 1: Obtain an elegant voronoi /facet dome cell pattern on a sphere (or an ellipsoid surface, whatever).
Goal no 2: Keep the cells planar in order to be able to loft them later and obtain those pyramidal forms, and assemble easily
Any ideas? Or maybe there's a completely different approach to that?…
bsp;
-Vehicle elements (3D objects and a component for custom vehicles; models from Google Warehouse)
-Traffic Velocity Graphs, drawn on every trajectory curve (allow custom graphs drawn)
-Traffic regulation elements (such as Traffic Lights and Stop Signals) and traffic density
-Particle Systems on trajectory curves, just to manage the traffic regulations and avoid collisions based on security distances
-Traffic Vehicle Animation Modes (Dots, Bounding Boxes or complex Meshes with attributes for final rendering (Giulio Piacentino´s Render Animation)
-Vehicle Lights and Vehicle Sights, to make visual studies
Team:
-Sergio del Castillo Tello (Doctor No, lead programmer)
-Everyone that wants to be involved, support.. these tools
The development of Roadrunner is planned to take part within a Research Group Program at ETSAM (University of Architecture in Madrid); This forum group is created just to test the interest of the community, while we keep on developing (it is still being tested), probably we will share the whole thing in the future. Cheers!
Traffic Cluster Scheme
Traffic Elements
Traffic Urban Systems
Vehicle Elements
Roadrunner - overview
Roadrunner 0 Basics
Roadrunner 1 Modes
Roadrunner 2 Elements
Roadrunner 3 Urban Systems…
3 arms and 6 legs (PS: Remember: in real-life our fee is proportional to the budget > thus > like Godzilla > the bigger the better).
In the mean time (auto detection of struts < min Allowed == true) get the gist of the whole "torque" issue, the other gist not to mention the other-other gist.
Of course you can opt for NOT making the cables (green) that stabilize the "extension" part of a given tensegrity strut ... yielding the Mother in Law syndrome (fat and ugly):
But ... hmm ... well ... are you really the chosen one? Here's your chance for the ticket to Paradise (full Lord's assistance, that is). Identify this engine, name the designer and the related immortal racer (when men were men).
Moral: Heaven can wait. …
ese explanations help (we will also look at your file) asap.
About your question regarding the Tutte graph drawing algorithm (also known as topological embedding):
The Tutte algorithm can be viewed as a special case of Spectral Graph Drawing, which is a mathematical solution for topological embedding formulated as an optimization problem. The formulation of the topological embedding (e.g. as in Tutte algorithm) is in fact quite similar to the so-called force-directed drawing that is often solved by heuristic methods like the one we have made for the SYNTACTIC plugin. You can read more about Force-Directed Graph Drawing (a.k.a. coin-graph drawing and kissing disks drawing) and Spectral Graph Drawing and Spectral Graph Theory in my dissertation.
The functionality of the Tutte algorithm is only guaranteed for graphs that are 3-connected, i.e. graphs with more than 3 vertices which cannot be torn apart unless at least two vertices are removed.
https://en.wikipedia.org/wiki/K-vertex-connected_graph
Speaking of the conditions for the Tutte algorithm to work properly: Practically, this implies, for instance, that there should not be rooms connected only to one other room.
Anyhow, long story short, we have decided to continue with Spectral Graph Drawing and 3D force-directed graph drawing. These algorithms are ready and with a couple of adjustments for maximum speed and stability we will release them shortly. Some conditions for these algorithms are easier to ensure, but in general if a node(room) is connected to only one space or the graph is not well connected one cannot expect a good graph drawing from neither of these methods. The other issue that is also common is that the force directed graph drawing will not work if one forces a big bubble to be squeezed in the middle of smaller bubbles. Stay tuned. …
he plug-in supports intuitive design of paneling concepts as well as rationalize complex geometry into a format suitable for analysis and fabrication. The plug-in is closely integrated with Rhino 7 and is widely used for architectural and other building designers.
Download
The new PanelingTools for the new Rhino 7.2 is now available. You can access Rhino 7 evaluation and upgrades from here…
Documentation
For documentation and examples, please check:
PanelingTools Manual for detailed description of commands and options.
PanelingTools for Grasshopper Manual includes tutorials and description of PT-GH components.
Paneling Scripting page has a listing of paneling methods for RhinoScript.
Paneling Tutorials page has links to video tutorials.
Paneling Short Clips page has short video tutorials that covers the core functionality of PanelingTools.
Paneling Gallery page has users projects with PanelingTools.
Videos
**NEW** PanelingTools Webinar Course - December 2014 learn how Paneling tools works and how best to integrate it into your design process.
Paneling Tools Webinar - February 11, 2011
Paneling Tools Webinar on Vimeo
Feedback
Please tell us what you think and how you are using PanelingTools to help shape future development.
Join the PanelingTools Group in Rhino Forum and post photos, news and discussions. Make sure to tag with keyword “PanelingTools”.
For questions and feedback, contact the developer.
Source: McNeel Wiki
Keshia C. Stich
Grid Paneling Group
…
s.
Yes, I see the issue now. Good catch!I am a bit reluctant to add a new input, as I would have to add it to the "OSM Shapes" component too. Both "OSM Search" and "OSM Shapes" components have more inputs than outputs, so I was kind of more keen to add another output (titleOriginPt), then input. This output can then be used to move the title with Grasshopper "Orient" component.
It's useful to say that: If a terrain has been added to the groundTerrain_ input of the "OSM Search" component, then the title would go below the terrain, which makes it more readable I guess.Let's see how this issue goes, maybe in the end more people will ask for adding a titleOriginPt_ input as well.
For the same thing (not sure about this) maybe a legend with colors for the filtered building types, assuming you can search for more than one at the same time.
This is a very good suggestion! At the moment it is not possible to search for more than one OSM object. I understand the importance of having such feature, but this would require from me to rewrite the "OSM Search" component. Maybe it can be a little less time consuming if a new additional component will be created. So one would have to copy an "OSM Search" component for each type of the OSM object he/she wants to search for, and then outputs from all those "OSM Search" components will drain into the upper mentioned new component which will make a colored legend for each OSM object. Just a suggestion.However there is one issue with all this OSM objects search, that I haven't mentioned: OpenStreetMap data can store amenities of the same type on different shapeType_. For example, in find_hotels.gh we are using shapeType_ = 0 (2d polygons), we make 3d shapes from them, and then we search among those 3d shapes.However, if one sets the shapeType_ to 2 (points) one will also find hotels among the points.It may take a more knowledgeable OpenStreetMap user to explain this, but in general: if a hotel occupies all floors of the building, then it would be found the way we did it in find_hotels.gh (shapeType_ = 0). But if a hotel does not occupy all floors, or a user who mapped the hotel was not certain whether it did occupy the whole building or not, then a hotel would be mapped as a single point. I assume this will be the point of hotel's entrance, but I may be wrong on this.I attached an example file below which shows this.So if there's going to be a new component created: which will map hotels, restaurants, bars... or other buildings types with a legend of some sort, then this aspect needs to be taken into consideration. It can probably be fixed with some sort of point inclusion (in a polygon). Let's see.It's definitively another very valuable suggestion!!…
Added by djordje to Gismo at 5:26pm on March 2, 2017
sent a 3D shape without any ambiguity. If the shape you're trying to convey falls outside the scope of existing standards, then it can't be done, but this is a problem of standards, not an intrinsic shortcoming of pencils.
[...] with the computer theoretically acting as a decision maker.
The computer makes no decisions on it's own. It's a fully deterministic machine, meaning that any output is the result of applying a set of rules to some pre-existing data. Humans make the rules. At no point can you blame the computer for coming up with a bad answer, it's always some human who is responsible.
[...] it seems to often be split between Computerization, and Computation.
I'm willing to concede there exist cases that are unambiguously one or the other, but there's a gradient in between these two extremes, they are not separate categories. If I draw a box by specifying the 8 corner points as XYZ coordinates then computation can be said not to be involved. If I draw a box by specifying 2 opposite corners then the computer has to compute the other 6 coordinates and we're already on our way towards the other extreme. If I draw a box by specifying a width, height and a required volume, more computation is needed. If I specify a box by a width, a volume and the requirement is doesn't cast too much shadow on some other shape, more computation is needed. At what point do we say "now it qualifies as computation/solving"?
--
David Rutten
david@mcneel.com…
Added by David Rutten at 7:22am on November 28, 2013
hes or surfaces on this: it's the nature/topology of your design that dictates that approach):
This C# only (as usual) collection of scripts works in 2 phases:
Phase A: Gets points in 3d space (NOT internalized in order to alter them manually) and creates a mesh. Depending of your search distance (actually: radius) the mesh is variable. If you bypass phase A (feed the 2nd C# with some other mesh of yours) then the mesh is triangulated automatically.
Phase B: Gets the mesh and creates your "tri-breps" in a DataTree where first dimension branches are indexed as the mesh faces (Note: "tri-breps" are not joined to a closed brep for speed).
PS: An auxiliary 3rd C# gives you an indication about the size of mesh edges in order to enter proper offset (where offset means offset of the tri-mesh edges) values.
PS: If you overdone with values > faces are excluded (and the equivalent tri-breps are NOT created):
PS: if you enter possible/doable offsets > all faces play ball:
best, Peter (Load Rhino file first)
…
hem and mine with some axis more in 3d space):
To tell you the truth you need a lot of other "constrains" for your nodes since they are shaped (I can easily guess the "method" used) by "fusion" and not connected via some ball type (MEANING: that the clearance between adapters should comply to a second constrain AFTER clash matters are addressed: this is one line of code more into that C#).
So ... I'll thy to translate the C# into components (but is 100 times easier to work with code than with these ... er ... mysterious/cryptic GH components, he he).
more soon…