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
tors: R.G.D.E tutors Mostafa R. A. Khalifa, Architect (PhD - UNICAM - Italy)
Assistants: Nagham Baitawy - Architect - Jordan
Ahmed Hassan - Architect & TA - Egypt
deadline registration August, 25th , 2013
http://grasshopperworkshopamman.blogspot.com/ introduction: This workshop will introduce basic and advanced notions of Grasshopper and the methodology of parametric design and algorithmic modeling and its usage in Architecture, design, landscape, and urban scale. It is intended for professionals and students with a minimum experience in 3D Modeling.
…
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…
ponents at all (C# , that is). Obviously this is a no-no > the wrong thing to do > back to the drawing board.
In the mean time get these 2 that are related with the issue (but how? I have no idea, he he).
The flatten (get the flying laundry back in a "stationary" state, he he) is challenging because ... if you change some mysterious things it turns ultra paranoid.
The other (intro to 3d grids) has a broad "repertoire" depending on your choices (and it doesn't comply with your grid inputs all the times - blame AI, he he):
…
of stuff. Then it works either with ExoW (black mesh) or IntraLattice (blue mesh).
That said ExoW is tricky: occasionally reports engulfing issues and stops playing the game. For instance in this (diagonal) anchor mode and with some U/V random values:
Whilst IntraLattice appears rather less temperamental:
The other def is more complex and works using the Proximity approach that makes more sense with regard random 3d line graphs (as an exercise: Add a gate and use IntraLattice as Plan B).
best
…
ners, and software developers. We are seeking 1 or 2 creative software programmer(s) for a permanent position to work on a combination of projects: from small high-end artworks to huge building facades.The kind of person we’re after: * Love experimenting and tinkering with technology. * Be a quick learner and ready to learn a new piece of software, device, API or language if a project requires it. * Able to work on several projects at once, thrive on challenges, delivering to customer deadlines. * Work well within in a team and also able to deliver on own initiative.The ideal person will have experience of the following: * Object oriented programming. Ideally with C/C++. * SDKs like OpenCV, openFrameworks, etc. * Interfacing computers with a range of peripherals. * Graphics programming, OpenGL, shaders, AR, etc. * May also have experience with other ‘patch’ based software such as Max/Msp or VVVVExperience or appetite to learn the following an advantage: * Lighting interfaces: DMX, Artnet, etc. * 3D stereoscopic and autostereoscopic graphicsJob Terms * Salary to be determined based on experience. * Position available now * Standard job benefits/terms will apply.Application Process * In your cover email please elaborate on your experience working in C++ and any other development environments. * email a CV and portfolio to: growing@cinimodstudio.com with ‘Software Developer Recruitment’ in the subject line. * We will arrange interviews with a number of applicants at our London studio.
http://forum.openframeworks.cc/index.php?PHPSESSID=0lm73j8h1pjpm1g5v7gjgo3u15&topic=6445.0…