et us consider a plane somewhere in space, 10 units along each side, and it has UV domains 0-1 in both directions. It's a perfect square surface basically.
This surface only really 'exists' on the inside of the UV domains. You can evaluate the surface at {0,0}, which will give you the lower left corner, you can evaluate it at {1,1}, which will give you the upper right corner or you can evaluate it at {0.5, 0.5} which might give you the point in the middle. If you evaluate it at {2,-5}, you will get a point that is beyond the surface edge.
This surface 'space' is strictly two-dimensional and it is also bounded, meaning it has a finite region in which things can be said to exist. If we attach a point to this surface at UV coordinates {0.5, 0.5}, then move the surface about, the point will move with the surface. So it's XYZ coordinates will change, but the UV coordinates are still {0.5, 0.5}! These are just two ways of looking at the same point. Either we treat the point as a coordinate in infinite 3D euclidean space {x,y,z} or we treat it as anchored to a surface {u,v}. Going from XYZ to UV is usually called "Projecting" or "Pulling", going from UV to XYZ is usually called "Evaluating" or "Sampling", but they are mathematically very similar processes.
Evan mentioned that Voronoi only works in the flat 2D plane. He suggested remapping the points from the surface onto the World XY plane, then solving the Voronoi diagram, then mapping the result back onto the surface again.
Basically that means projecting all your XYZ points to surface UV space. That will give you a collection of points defined strictly by 2 coordinates, i.e. it is completely flat. You solve the Voronoi diagram on these flat points, and then you have to put the flat points (and the flat voronoi cell outlines) back onto the surface.
Have a look at the [Surface CP] and [Evaluate Surface] components, they provide the methods required to map coordinates from XYZ space to UV space and vice versa.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:51pm on April 29, 2010
basically managed to deal with most geometries by the VB components. But now, in the rhino 5 common, a lot of method need the implementation of IEnumerable, like brep.joinbreps and curve.joincurves, and so on.
I checked the constructor of RhinoList, it shows rhinolist can implement IEnumerable.
Public Sub New ( _ collection As IEnumerable(Of T) _
)
But when I use list or array for syntax that requires IEnumerable (of Curve), IEnumerable(of Mesh) and so on, it just results in fault: '1-dimensional array of rhino.geometry cannot be converted to 'rhino.geometry'...
Help! I'm suffering this for two days....
'…
some problems. I could be wrong, but I am guessing it is a parsing issue... ?
I was able to filter by geo location by inputting:
airport &geocode:38.863236,-76.994934,10km
(the ":" gets parsed as a code, but it seems to work ok, using "=" instead of ":" returns null)
(parse query= q=airport&geocode%3A38.... )
But when I try to use something like this:
blue%20angels&rpp=5&include_entities=true&result_type=mixed
the "=" gets parsed as "%3D", and result is null...
I also tried some of the examples listed on twitter's api page, (http://search.twitter.com/search?q=place%3A247f43d441defc03), also null.
Questions:
Is there a way around this?
Have you been able to use more complex search query parameters?
Is the geolocation/place of the tweet returned? Could it be parsed and outputted by component?
Thanks!
Reference:
https://dev.twitter.com/docs/using-search
https://dev.twitter.com/docs/api/1/get/search…
tle.
I use rhino with the nurbsrelaxation plugin. Recently we have had rhino do some work to come up with an automated drawing tool via grasshopper.
Since grasshopper has been added to rhino i have noticed that when drawing surfaces and then using the nurbs tool the tools behaviour has changed and is now including iterations at the end of its process doubling the amount of time it takes to draw/finalise the surface/shape.
Below i have included 2 screenshots, the first one shows the surface(yellow edges), and then the cursor showing the nurbs icons (toolbar) and the rest of the info is in the command boxes.
The 2nd one shows info in the command line, detailing what happens once the tool is run (this is where you can see the iterations occuring).
Having done a little research i get the impression that this may be grasshopper related but cannot find any confirmation of this nor of anyone experiencing the same issue.
I also know that nurbsrelaxation is a plug in so not everyone will use this.
Can anyone help me with this as i would like to know why the iterations are occurring and if we can eliminate or reduce them.
Many thanks in advance
Matt…
Added by Matt Fairley at 4:08am on November 10, 2015
mains doesn't match. This happens quite a lot with more detailed SRTM files like :
DEM SRTM 1Second Hydrologically Enforced
5 metre Digital Elevation Model (DEM)
which can be found there :
http://www.ga.gov.au/elvis/
When using more "standard" SRTM files like from https://earthexplorer.usgs.gov/ the issue seems to disappear..
Do you think that it could come from the pixel resolution (there's a slight change there...) ? Sometimes it works without any real explanation behind it..
Any thoughts or inputs would be very appreciated as some of those SRTM files have a better resolution thant the "standard" one.
Thanks !…
de modelación en 3D y aprovechen las ventajas que plantean, como mejorar su proceso de diseño y explorar múltiples alternativas para un proyecto en lapsos de tiempo muy reducidos en comparación de los métodos tradicionales.
En consecuencia, los alumnos tendrán la posibilidad de disminuir sus tiempos de trabajo, con resultados iguales o incluso mejores a los que obtenían con anterioridad; mejorar la calidad de sus presentaciones y, lo que es más importante, ampliar la fundamentación de sus proyectos en el aspecto funcional y formal, dependiendo de las características del proyecto.
Para lograr estos objetivos, se contemplan dos temarios y un ejercicio práctico.
Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, con el objetivo que el alumno pueda continuar aprendiendo con alguno de nuestros siguientes workshops o de manera autodidacta.
Además del contenido teórico se incluye un ejercicio práctico, la magnitud del ejercicio y el material que se le destine se definirán con base en el número de asistentes.
El workshop tiene una duración de cinco sesiones:
Sesión 1 – Temario de Rhinoceros
Sesión 2 y 3 – Temario de Grasshopper
Sesión 4 y 5 – Ejercicio práctico
El horario es de 9 am a 4 pm, con una hora de receso para tomar un refrigerio.
No es necesario traer el equipo necesario para trabajar, se cuenta con un equipo para cada persona asi como el material de trabajo para el ejercicio práctico, por lo cual se les recomienda que no traigan portátiles u otro material, únicamente dispositivos de almacenamiento si desean guardar sus trabajos.
El costo del evento es de $3,500 estudiantes y $4,000 profesionales.
(Para poder tener el descuento de estudiante es necesaria una constancia de la universidad de la que proviene, acreditando que el interesado está cursando algún semestre de la carrera. Personas graduadas que estén cursando una maestría o algún grado superior no reciben el descuento).
Para apartar su lugar pueden realizar un depósito de $1,500 y terminar de efectuar el pago antes del 15 de abril si es mediante un depósito bancario o el primer día del evento en efectivo.
El evento se realizará en las oficinas de Vegasot, ubicadas en Circuito Cirujanos No. 23-A
Cd. Satélite, Naucalpan, Edo. de México 53100
http://www.vegasoft.com.mx
Para cualquier duda por favor escriban un correo a luzytextura@gmail.com, por teléfono al 044 55 4381 3302, o en facebook.com/archbernardorivera…
edit 29/04/14 - Here is a new collection of more than 80 example files, organized by category:
KangarooExamples.zip
This zip is the most up to date collection of examples at the moment, and collects t
. From the Thermal Comfort Indices component, Comfort Index 11 (TCI-11):MRT = f(Ta, Tground, Rprim, e)
with:- Ta = DryBulbTemperature coming from ImportEPW component- Tground = f(Ta, N) where N comes from totalSkyCover input. Tground influences the long-wave radiation emitted by the ground in the MRT calculation.- Rprim defined as solar radiation absorbed by nude man = f(Kglob, hS1, ac)- ac is the clothingAlbedo in % (bodyCharacteristics input)- I can't find any definition in the code of Kglob and hS1. Could you tell me please what are those values referencered to? --> probably the globalHorizontalRadiation but how?- e = vapour pressure calculated from Ta and Relative Humidity input
Do you agree that in this case the MRT does not depend on these inputs: location, meanRadiantTemperature, dewPointTemperature and wind speed?It does not depend neither on the other bodyCharacteristics like bodyPosture, age, sex, met, activityDuration...?
MRT calculated by the TCI-11 method is the mean radiant temperature of a vector pointing vertically with a sky view factor of 100%?For ParisOrly epw,
2. From the SolarAdjustedTemperature component (that seems to be more used for the UTCI calculation examples on Hydra compared to TCI-11).
In contrast to the TCI-11, this component distinguishes diffuse and direct radiation and contextualizes the calculation thanks to _ContextShading input, right? It can also be applied to a mannequin thanks to the CumSkyMatrix and thus evaluate the dishomogeneity of radiation exposure.This component seems not to consider the influence of vapour pressure on the result --> is it then more precise to put the MRT output (from the TCI) as an input of meanRadTemperature for SolarAdjustedTemperature?The default groundReflectivity is set to 0.25 --> is GroundReflectivity taken into account in the Tground or MRT calculation in the TCI component? If yes, what is the hypothesised groundReflectivity?The default clothing albedo of 37% (TCI-11 bodyCharacteristics) corresponds to Clothing Absorptivity of 63%?
If the CumSkyMatrix input is not supplied, I get 9 results for the mannequin --> where are those points/results coming from?
If the CumSkyMatrix input is supplied,I suppose the calculation of the 482 results correspond to a calculation method similar to the radiation analysis component that is averaged over the analysis period. Right?But I don't understand why the mannequin is composed of 481 faces and meshFaceResult gives 482 results.
Finally, what is the link between the MESH results, the solarAdjustedMRT and the Effective Radiant field ? Is there a paper to have a detailed explanation of the method?
3. Here are some results for the ParisOrly energyplus weather data. You can find here attached the grasshopper definition.There is no shading in this simulation and the result coming from the ThermalComfort indices for MRT is very different compared to the solar adjusted MRT.Why such a big difference and which of the result should be plugged into the UTCI calculation component?
Results for ParisOrly.epwM,D,H:1,1,12
Ta : 6.5°Crh: 100%globalHorizontalRadiation: 54 Wh/m2totalSkyCover: 10MRT (TCI-11): 1.2°C
_CumSkyMtxOrDirNormRad = directNormalRadiation : 0 Wh/m2diffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.64°CMRTDelta: 4.14°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.47°CMRTDelta: 3.97°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = MRT (TCI-11)solarAdjustedMRT: 5.17°CMRTDelta: 3.97°C
Thanks a lot for your helpRegards,
Aymeric
…
three categories, each one corresponding to different shapeType_ input:- polygons (shapeType_ = 0): anything consisted of closed polygons: buildings, grass areas, forests, lakes, etc
- polylines (shapeType_ = 1): non closed polylines as: streets, roads, highways, rivers, canals, train tracks ...- points (shapeType_ = 2): any point features, like: Trees, building entrances, benches, junctions between roads... Store locations: restaurants, bars, pharmacies, post offices...
So basically when you ran the "OSM shapes" component with the shapeType_ = 2, you will get a lot of points. If you would like to get only 3d trees, you run the "OSM 3D" component and it will create 3d trees from only those points which are in fact trees. You can also check which points are trees by looking at the exact location on openstreetmap.org. For example:
Or use the "OSM Search" component which will identify all trees among the points, regardless of whether 3d trees can be created or not.However, when it comes to 3d trees there is a catch:
Sometimes the geometry which Gismo streams from OpenStreetMap.org does not contain a "height" key. Or it does contain it but the value for that key is missing.OpenStreetMap is free editable map database, so anyone with internet access and free registered account on openstreetmap.org can add features (like trees) to the map database. However, regular people sometimes do not have height measuring devices which are needed for specific objects as trees.So "OSM 3D" component will generate 3d trees from only those tree points which contain a valid "height" key.However, a small workaround is to input a domain(range) into the randomHeightRange_ input of "OSM 3D" component (for example the following one: "5 to 10"):
This will result in creation of other 3d trees which do not have defined height, by randomizing their height. randomHeightRange_ input can also be applied to 3d buildings, and it is definitively something I need to write a separate article on.
In the end it may be that nobody mapped the trees in the area you are looking for.
After you map a tree to openstreetmap.org then it will instantly be available to you or any other user of Gismo. I will be adding some tutorials in the future on how this can be done. But probably not in the next couple of weeks.
Let me know if any of this helps, or if I completely misunderstood your issue.…
Added by djordje to Gismo at 3:52am on February 8, 2017