her bump on the road. I've evolved the original idea into something that remotely resembles this childish doodle:
That is, 3 different rows of panels with fixed heights but random widths. Each panel will be perforated in voronoi patterns that vary according to my original sun intensity diagram, but I'm thinking they'll have a fixed frame width and a small gap between them, kinda like this other childish doodle:
I've mastered the method of turning my original diagram into a voronoi panel that's denser where the sun hits harder thanks to Vicente's method. But it gives the voronoi frames a width by scaling each cell by .9, but that doesn't yield frames with constant width... which is fine for my 3D, but I wanna use the files to draw diagrams for laser cutting and actual building of the panels, so I guess I can't be too precise there.
Again thanks for all the useful (and funny) input! :)
…
e parallel lines:
http://www.grasshopper3d.com/profiles/blogs/marching-cubes-curve-wr...
It's at least real code I could translate to my native Python, but I still don't know if it's even possible to solve the math to make things not bulge, as his gives the same result at Millipede:
If I join the four corners of the main box, those four bulges nicely disappear.
His field calculation code is pretty simple, just returning a single field value for a 3D test point input, for a single point or curve being considered, but I don't yet see how they add together to form an overall isosurface:
…
nd give it love.2. Everything else is to know the nature of the data and components. Data is all: numbers, formulas, colors, lists, branches, graphics, visual representation, connection between data, hierarchies, etc.3. Work, work and work.Have information is know about data, have knowledge is to know how the data is related with everything else and have wisdom is to have the right mental-programs to process data. And then there's the creativity, divergent thinking, ingenuity and talent that make the mental architecture not be something rigid. Then, to carry out algorithms, the mindset I usually follow is, I start with data/parameters to perform a design, and decompose the process into smaller processes that can manipulate. If I'm at a point where I do not know how to do, two things can happen, that I know what I have to do but can not, or not know how to do, the first is probably lack of knowledge aboud data or components, therefore, it is time to learn; and second, rethink the previous processes if I can avoid the problem, which often leads me to redo the whole algorithm, which is not allways bad.In short, delves into the data and components, so your mental program of execution will be more optimal if you know more about posibilities. And think in terms of process, not in terms of outcome. And work, work, work does the rest. There is no trick, just eager to learn. I did not start to understand that it was really the 3d until I began to learn programming, but this way I will advise you when you have confidence using grasshopper.Perhaps is not what you expected, but it all boils down to devote more hours. Grasshopper is easy to use and hard to learn.…
ithin an Urban context and taking into account the shading of the surrounding context, and we are testing the Ladybug Thermal Comfort Indices component. For what we understand there are two ways to take into account the Mean Radiant Temperature, you can either plug the meanRadiantTemperature_ or the solarRadiationPerHour_. According to the meanRadiantTemperature_ description it seems that if we are doing the calculation outside in the sun we mustn’t plug in anything and we must work only with the solarRadiationPerHour_ (as you also do in the example). Is it correct?
solarRadiationPerHour_ can be calculated in two ways, the first one is shown in your example and uses Ladybug_Radiation analysis component (Very clear thank you so much! : ) ) The other one uses the Ladybug_Sunpath Shading component and from the description is supposed to be more precise. And here are the other questions:
1) there is a parameter that takes into account vegetation, with which degree of detail should it be represented? 2D(silhouette) or 3D surface? Should we separate the trunk from the crown?
2) In this component we can also insert an albedo value. Is this value taken into account in the PET calculation and if yes, how?
3) In the Ladybug_Radiation Analysis component we can input a geometry at the ground level to be calculated and then place an analysis grid at 1.1 _disFromBase. Using Ladybug_Sunpath Shading, where should we place the geometry to be calculated and how can we place the analysis grid like in the other case?
We apologise for the long post!
Thank you very much for all your efforts!!…
rids Surface divisions Panel creation in Rhino Panel morphing and aggregation Panel placement via attractors and colors Panel smoothing with Weaverbird Parametric panel modules TIME 3pm – GMT, London 4pm – Paris, Brussels, Rome, Vienna, Budapest, Bratislava, Warsaw 7pm – Dubai, Abu Dhabi, Baku 6:30pm – Tehran 6pm – Baghdad, Moscow, St Petersburg 5pm – Istanbul, Athens, Helsinki, Cairo, Johannesburg 1pm – Rio de Janeiro, São Paulo, Montevideo 12pm – Buenos Aires, Santiago 10am – Toronto, New York City, Bogota, Lima 9am – Mexico City 7am – Los Angeles ADVANCED SESSIONS (live) The Advanced sessions put the essential knowledge into practical use. The advanced sessions explain specific design strategies, lead you through complex Grasshopper® definitions, show tips and tricks, put plug-ins into use and show you how to connect Grasshopper® to external software and devices. MICHAEL PRYOR Designer, working in the architecture field for four years now on a variety of major built and in construction projects in NYC and China. Co-partner to 3D-Dreaming: Architecture from a digital point of view. Daily user of grasshopper: both in work and exploration, as well as a constant contributor to the grasshopper help forums. Tutor to a variety of digital design and parametric workshops hosted by the Architecture Association with [AY]A Studio, Rese arch, and 3D Dreaming. Creator of the grasshopper tutorial blog [FORMul[a]RCH]. Currently in process of writing his first grasshopper plug in. WEBINARS The rese arch Grasshopper® sessions are unique for their thorough explanation of all the features, which creates a sound foundation for your further individual development or direct use in the practice. The webinars are divided into four groups: Essential, Advanced, Iterative and Architectural. If you are a Rhinoceros 3D or Grasshopper® newcomer, you are advised to take all the Essential sessions before proceeding to the next level. If none of the proposed topics suit your needs or if you require special treatment, you can request a custom-tailored 1on1 session. All sessions are held entirely in English. The webinars are series of on-line live courses for people all over the world. The tutor broadcasts the screen of his computer along with his voice to the connected spectators who can ask questions and comment in real time. This makes webinars similar to live workshops and superior to tutorials.…
Added by Jan Pernecky at 9:39am on January 8, 2015
e chosen to dive into Grasshopper. I’m about 6 months in. If some of my comments are completely off, please take that to mean that a feature is too inaccessible to a newish user rather that it’s just missing, as I may have stated.
One of my primary pain points is this. Things that can be done in other programs are invariably easier in other programs. This is a big enough issue that I doubt there’s an easy solution that an armchair qb like myself can offer up.
The interface:
I’ve used a lot of 3D programs. I’ve never encountered one as difficult as grasshopper. What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design. Yet PTC (Parametric Technology Corp.) has been doing parametric design software since 1985 and has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others.
In the early 2000's, when parametric design software was all the rage, McNeel stated quite strongly the Rhino would remain a direct modeler and would not become a parametric modeler. Trends come. Trends go. And the industry has been swinging back to direct modeling. So McNeel’s decision was probably ok. But I have to wonder if part of McNeel’s reluctance to incorporate some of the tried and proven ideas of other parametric packages doesn't have roots in their earlier declaration to not incorporate parametrics.
A Visual Programming Language:
I read a lot about the awesomeness and flexibility of Grasshopper being a visual programming language. Let’s be clear, this is DOS era speak. I believe GH should continue to have the ability to be extended and massaged with code, as most design programs do. But as long as this is front and center, GH will remain out of reach to the average designer.
Context sensitivity:
There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them.
Sliders:
I hate sliders. I understand them, but I hate ‘em. I think they should be optional. Ya, I know I can r-click on the N of a component and set the integer. It’s a pain, and it gives no feedback. The “N” should turn into the number if set. AAAnd, sliders should be context sensitive. I like that the name of a slider changes when I plug it into something. But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly. I shouldn't be able to plug in a “50” and have everything after turn red.
Components:
Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings.
And this item I’m guessing on. I’m not yet good enough at GH to know if this may have adverse effects. Reverse, Flatten, Graft, etc.; could these be context sensitive? Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?
Tighter integration with Rhino:
I'm not entirely certain what this would look like. Currently my work flow entails baking, making a few Rhino edits, and reinserting into GH. I question the whole baking thing, btw. Why isn't it just live geometry? That’s how other parametric apps work. Maybe add more Rhino functionality to GH. GH has no 3D offset. I have to bake, offsetserf, and reinsert the geometry. I’m currently looking at the “Geometry Cache” and “Geometry Pipeline” components to see if they help. But I haven't been able to figure it out. Which leads me to:
Update all of the documentation:
I'm guessing this is an in process thing and you're working toward rolling GH from 0.9.00075 to 1.0. GH was being updated nearly weekly earlier this year. Then it suddenly stopped. If we're talking weeks before a full release, so be it. But if we're looking at something longer, a documentation update would help a lot. Geometry Cache and Geometry Pipeline’s help still read “This is the autogenerated help topic for this object. Developers: override the HtmlHelp_Source() function in the base class to provide custom help.” This does not help. And the Grasshopper Primer 2nd Ed. was written for GH 0.60007.
Grasshopper is fundamentally a 2D program:
I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen? Pretty much every 3D program in existence has this. I’m sure I can probably figure out how to deconstruct the breps, join the curves, loft, trim, and so forth. But does writing an algorithm to do what all other 3D programs do with a dialog box seem reasonable? I'm sure if you go command by command you'll find a ton on such things.
If you look at the vast majority of things done in GH, you'll note that they're mostly either flat or a fundamentally 2D pattern on a warped surface.
I've been working on a part that is a 3D voronoi trimmed to a 3D model. I've been trying to turn the trimmed voronoi into legitimate geometry for over a month without success.
http://www.grasshopper3d.com/profiles/blogs/question-voronoi-3d-continued
I’ve researched it enough to have found many others have had the exact same problem and have not solved it. It’s really not that conceptually difficult. But GH lacks the tools.
Make screen organization easier:
I have a touch of OCD, and I like my GH layout to flow neatly. Allow input/output nodes to be re-ordered. This will allow a reduction in crossed wires. Make the wire positions a bit more editable. I sometimes use a geometry component as a wire anchor to clean things up. Being able to grab a wire and pull it out of the way would be kinda nice.
I think GH has some awesome abilities. I also think accessing those abilities could be significantly easier.
~p…
it seems that was this. Now all is working fine !
Glad that it worked! But I am still a bit worried. Gismo components only modify the gdal-data/osmconf.ini file and no other MapWinGIS file. So your MapWinGIS installation files should not be compromised. The fact that you did not get the "COM CLSID" error message when running the "Gismo Gismo" component suggests that MapWinGIS has been properly installed. So I wonder if the cause for the permanent "invalid shapes" warning has again something with the fact that your system is again not allowing the MapWinGIS to properly edit the osmconf.ini. Maybe this problem will appear again, and again, and reinstallation of MapWinGIS every time can be somewhat bothersome.
- About the terrain generation, is it possible to have the texture from google or other provider mapped onto the terrain surface from gismo component ? (Same as using the ladybug terrain generator in fact). I try to used the image extracted by ladybug component and then applied it to the gismo terrain but the texture is rotated by 90°.
The issue with the rotation can be solved by swapping/reversing the U,V directions of the terrain surface. A slightly more important issue is that terrain surface generated with Gismo "Terrain Generator" component might have a bit smaller radius than what the radius_ input required. This stems from the fact that the terrain data first needs to be downloaded in geographic coordinate system, and then projected. Some projecting issues may occur at the very edges of the projected terrain, so I had to slightly cut out the very edges of the terrain which results in the actual terrain diameters being slightly shorted in both directions. This means that if you apply the same satellite image from Ladybug "Terrain Generator" component to Gismo "Terrain Generator" component the results may not be the same.I attached below a python component which tries to solve this issue by extending the edges of Gismo "Terrain Generator" terrain, and then cutting them with the cuboid of the exact dimensions as the radius_ input. Have in mind that this extension of the original terrain at its edges is not a correct representation of the actual terrain in that location. But rather just an extension of the isoparameteric curve of the terrain surface. So basically: some 0 to 10% (0 to 10 percent of the width and length) of the terrain around all four edges is not the actual terrain for that location, but rather just its extension.The python component is located at the very right of the definition attached below.
Also, if you would like to use the satellite images from Ladybug "Terrain Generator" component along with "OSM shapes", sometimes you may find slight differences in position of the shapes. This is due to openstreetmap data not being based on Google Maps (that's what Ladybug "Terrain Generator" component is using), but rather on Bing, MapQuest and a few others.
- About the requiredKeys_ input of OSM shapes, I understand what you mean and your advice, but in most cases I use it, the component was working fine even without input. I think it's better to extract all tags, values and keys of the selected area, instead of searching for specific ones as I try to find all data related to what I want after, isn't it ? To check what keys are present on the area also.
Ineed, you are correct.I though you were trying to only create a terrain, 3d buildings and maybe find some school or similar 3d building, for these two locations. The recommendation I mentioned previously is due to shapefiles having a limit (2044) to how many keys it can contain. This requires further testing of some big cities locations with maybe larger radii, which I haven't performed due to my poor PC configuration. But in theory, I imagine that it may happen that a downloaded .osm file may have more than 2044 keys. In that case shapefile will only record 2044 of them, and disregard the others. That was my point.But again 2044 is a lot of keys, and I haven't been checking much this in practice. For example, when I set the radius_ to 1000 meters, and use your "3 Rue de Bretonvilliers Paris" location I get around 350 something keys, which is way below the 2044.Another reason why one should use the requiredKeys_ input is to make the Gismo OSM components run quicker: for example, the upper mentioned 350 something keys will result in 350 values for each branch of the "OSM shapes" component's "values" output.Which means if you have 10 000 shapes, the "OSM shapes" component will have 10 000 branches with 350 items on each branch (values). This can make all Gismo OSM components very heavy, and significantly elongate the calculation process.With requiredKeys_ input you may end up with only a couple of tens of items per each branch.Sorry for the long reply.…
Added by djordje to Gismo at 8:57am on June 11, 2017
proxy). However I decided to use the Human plug-in and scatter them as block instances, this allows me to add some reference lines in a different layer to have a better visual reference of the proxies, and have a lighter work environment in Rhino. (If you have the blocks on a layer and the proxies inside in a different layer, the proxies will render even if their layer is off and they are not showing in the viewport)
The definition has two parts: the bottom part scatters 3 grass primitives on a circle surface and is mostly an updated version of Manuel's definition, I hope he doesn't mind (you can replace the circle with any surface if you want a small patch of grass), you then bake this geometry, create one or several proxies in Rhino and create the blocks; the top part scatters a block on either a Surface, Brep or Mesh.
The definition populates the base surface/brep/mesh with points, then offsets the edges with the circle radius and pulls the points outside that boundary to it, so the circles don't fall outside the surface. (this part was the one that gave most troubles and it still fails sometimes, maybe someone could help me with that)
It also autoflips the normals if they're not up, and aligns the X axis of the target planes to a set direction (so you can have some wind or gravity effect if you want).
I used, and you probably need to make it work: Rhino 5 sr11 64bits, V-ray 2.0, grasshopper 0.9.0076, and Human (3-17-2014)
In my examples I scattered 3 blocks each with its own material, but you can have proxies with multiple materials.
If you make your own grass primitives don't forget to map the textures before scattering.
I'm posting some example renders and sharing the vray materials and proxies I used (I was experimenting with vray2sidedmats and a second diffuse layer with yellow noise mapped to world coordinates)
I'd like some help to get some cooler and different ideas for grass materials and proxies.
If you get some bugs let me know...
Eduardo
…
Added by Eduardo A at 11:54am on September 14, 2015
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…