y case. Here's the thing. There is this subject at my university where we are assigned a famous building and we need to recreate it in Rhino. We're given bonus points if we manage to code some interesting part of it in Grasshopper. So far so good, I'm doing pretty well with Rhino and by far I am happy with the results I've achieved with modelling the given building. Harbin Opera House by MAD is the building I'm trying to model. There is one particular surface:I've built this surface in Rhino and now I'm trying to map pyramids on it. Not only have the pyramids to be different in height, but their height has to be dependent on the curvature of the surface. I'm getting some results but it seems to be exactly the opposite of what I need. I want to have higher/spikier pyramids where my curvature analysis shows red/blue and lower/slopier pyramids where the analysis shows green colour.At the moment I'm not really sure how the code I have works, but it seems that the height of the pyramids is dependent on a distance from a point in space to the projection of the cap-point of a pyramid.Here're my Rhino and Grasshopper files:surface1.3dm
surface1.ghI'd be grateful if someone of you guys could handle my problem. I've got one more issue with this surface, but once I get a solution to the first 1 will let know what the second one is.Thanks in advance and keep well!…
te some implications and questions so I will go one by one:
"Now I would like to use a single VRay material as a template for creating multiple identical materials"I hope this will work, but as VRay does not expose any SDK, I would not guarantee any specific result.
"Now I need to add them to the document material table"This is done with a reference to a document instance, such as the one you get with the code doc.Materials (both in C# and Vb.Net).
"I'm not going to learn C# to modify his script"That's a pity, it would be nice to pass on this troublemaker to somebody else! :)Btw, C# and Vb.Net are very very similar. This script could be written in Vb.Net too.
"Reference to a non-shared member requires an object reference. (line 96)"This only means that you need to access the Materials property on an instance, not on the type (class) name. Change that line using what is written at point 2.
"Do I understand that the material has to be assigned to a particular object in order to enter the Material Table?"No it does not. But if you call the _Purge command it will be removed if it does not have an object that references it.
"Can I assign it to a Layer instead?"You do not need to. But this would be achieved with doc.Layers[whichLayer].RenderMaterialIndex = materialIndex; in C# or doc.Layers(whichLayer).RenderMaterialIndex = materialIndex in Vb.Net.
"Any ideas? A better way to do this?"If you found a way to bypass the VRay SDK not being there, this should work.
"Giulio's component has a type hint defined as a Material"It does not any longer. The hint was there in earlier versions of Grasshopper, but now the hint has disappeared. This is not so bad, and it is also the only way you would be able to use either a Material instance already or a string for a material name.
"How was that done?"Probably it was done in an older version of Grasshopper. But which version are you using?
"I can't figure out how to cast the input as a Rhino.DocObjects.Material, so you can see that I have cast it as a compatible type in the first 2 lines... is there a cleaner way?"That sounds like a good way actually. Be sure your component responds properly when something wrong is inputted, though.Dim mTemp As Rhino.DocObjects.Material = CType(M, Rhino.DocObjects.Material)in one line might also work. See msdn for more conversion operators and functions.
I hope this helps,
- Giulio_______________giulio@mcneel.com…
lts.
In the visualization, points is an interesting option. It's a matter of aesthetics I guess, I go with surfaces :) Also what you can try is selecting Filters -> Slice (you can also find it in the icons above the pipeline viewer), in the Slice options below the pipeline press Z normal and on the Z coordinate press some height relevant to the buildings (e.g. 1.75m a typical human scale). That would show you the flow around the buildings on that height. Experiment with selecting other normals and values. Keep playing with the filters there's some cool things in there. Also you can check out the mailing list and extensive paraview documentation.
Concerning the errors I apologize because I just downloaded your case.
It appears that the decomposeParDict is not included in the system folder. I am not sure if this is due to BF not going through the whole workflow yet or an ommission on our side. Please feel free to add it in Github. I will also note it down and pass it to Mostaph to check. In the meantime please find attached a VERY detailed decomposeParDict file. I took the liberty to set it at 4 processors (the numberOfSubDomains value) and also selected (that is uncommented) the scotch decomposition method. It's the easiest method to use since it is automatic and doesn't require any more inputs on how the domain is decomposed on the x,y,z directions (which would require you to change values in the attached file).
Now, the different folders created are simply snapshots of the current solution at the specific timestep. To control how often the solver is saving change the writeInterval number in the controlDict file. You can also change almost all these values on the fly, while OF is running.
Finally, concerning the other errors of parafoam it seems somehow parafoam is reading the intial condition names instead of actual results from the solution files and it doesn't like it.
Does this happen only when you open the case (i.e. at 0 time) or does it also happen when you move to an other timestep?
Also, are you using paraFoam, paraview or the paraFoam -builtin method?
The extension of the paraFoam file seems to be .foam which means you are probably using the built in viewer. That might be the issue but I'm not sure.
Can you try running paraview, navigate to your case folder, open the .foam file and see if there is still an error?
Also, if it isn't much trouble can you zip one of the time folders and attach it here? I'd like to take a look at what's inside to check against what the error report says.
Once again thanks for testing!
Kind regards,
Theodore.…
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
.
Today we have gone live, and the plugin is available on Food4Rhino. You will find an installer package, sample files, and a demo video on getting started:
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo and poke around in the code:
https://bitbucket.org/andheum/humanui
Check out today's coverage in Architect Magazine:
http://www.architectmagazine.com/technology/nbbj-releases-human-ui-to-bring-parametric-modeling-to-the-masses_o
Finally join our group and ask any questions or post any comments here:
http://www.grasshopper3d.com/group/human-ui
See below for detailed description!
----------------------------------
Human UI
Primary Development by:
Lead Developer: Andrew Heumann / andheum / @andrewheumann
Product Manager: Marc Syp / marcsyp / @mpsyp
Contributing Developer: Nate Holland / nateholland / @_NateHolland
Gone are the days of faking a user interface by laying out sliders and text panels and hiding wires on the Grasshopper canvas. Human UI interfaces are entirely separate from the Grasshopper canvas and leverage the power of Windows Presentation Foundation (WPF), a graphical subsystem for rendering user interfaces in the Windows environment.
OLD NEW
In other words: Human UI makes your GH definition feel like a Windows app. Create tabbed views, dynamic sliders, pulldown menus, checkboxes, and even 3D viewports and web browsers that look great and make sense to anyone--including designers and clients with no understanding of Grasshopper.
Human UI has been in development at NBBJ for over a year, as part of a larger NBBJ Design Computation initiative to deliver our tools internally as Products -- with fully automated installation, managed dependencies, analytics, documentation, and “magical” user experience. Human UI has been a huge component of the user experience part of this puzzle, and we are excited to share it with the larger Grasshopper community so that others can benefit from it and contribute to its development.
The initial release of Human UI is accompanied by a few simple examples to get you started, but we have developed sophisticated user interfaces with these tools at NBBJ and will slowly be rolling out more advanced examples. We also look forward to opening up the development to the community and seeing what new features and paradigms we can add.
Download the plugin at Food4Rhino and get started building Custom UIs for Grasshopper right away! We are happy to answer any questions or field discussion in the dedicated Grasshopper Group. Please join us!
Join the Grasshopper Group
http://www.grasshopper3d.com/group/human-ui
Download the plugin + sample files
http://www.food4rhino.com/project/human-ui
Visit the Bitbucket Repo
https://bitbucket.org/andheum/humanui
We look forward to seeing where this project takes you, please share your projects made with Human UI!
Sincerely,
Design Computation Leadership Team, NBBJ
…
Introduzione a Grasshopper", il primo manuale su Grasshopper.
.
I corsi PLUG IT nascono dalla volontà di promuovere le nuove tecnologie digitali di supporto alla progettazione e condividere il know-how maturato attraverso ricerca, collaborazione con i più importanti studi di architettura e pubblicazioni internazionali.
.
Verranno introdotte le nozioni base di Grasshopper approfondendo le metodologie della progettazione parametrica e le tecniche di modellazione algoritmica per la generazione di forme complesse. Il corso è rivolto a studenti e professionisti con esperienza minima nella modellazione 3D e si articolerà in lezioni teoriche ed esercitazioni.
. Argomenti trattati:
- Introduzione alla progettazione parametrica: teoria, esempi, casi studio - Grasshopper: concetti base, logica algoritmica, interfaccia grafica - Nozioni fondamentali: componenti, connessioni, data flow
- Funzioni matematiche e logiche, serie, gestione dei dati - Analisi e definizione di curve e superfici
- Definizione di griglie e pattern complessi - Trasformazioni geometriche, paneling - Attrattori, image sampler
- Data tree: gestione di dati complessi - Digital fabrication: teoria ed esempi - Nesting: scomposizione di oggetti tridimensionali in sezioni piane per macchine CNC
.
Verrà rilasciato un attestato finale.
.
Ulteriori info e programma completo su: www.arturotedeschi.com e su www.samilolab.it…
s levels of detail by subdividing a 6 sided cube mesh and projecting its vertices according to a referenced height map. This is one of the standard conventions for building full sizes planets. At the lowest level (0) the mesh planet is made of 6 pieces(each 32x32 resolution). The next level down (1) is made of 24 pieces... 6 divided by 4 = 24. Level (2) is 96 quads etc etc. The script will generate each quad at its sub-division level and compare edge vertices to neighboring quads. It will then make sure any shared vertices are in fact at the same projected vector. This ensures a planet quad with edge vertices that match.
The problems comes in texturing each quad.
If I build the quad as a nurb surface from points I can place the texture easily because each surface UV maps squarely to my texture map (which is also square).
If I build the quad as a mesh I cannot just apply the square texture to the mesh UVs. This is because when you unwrap the UVs from a mesh they will not unwrap like a nurb surface's UVs. Therefore to get the correct mapping I would have to manipulate each UV back to an evenly aligned array (which is 1024 points in a 32x32 resolution UV). Maya and blender have 'relax uv' and 'align UV' functions but they don't do the trick and manual corrections are out of the question. So why not skip the mesh method and use the nurb method?
I did this and there is a trade off. The nurb will accept the material texture I want with no other work on my end but when I export the object as an .obj rhino creates its own mesh to describe the nurb(with various unsatisfactory setting options). This works great up to a point because at some level the interpreted mesh will have vertices that do no match at the edges, ie .. creating visible seams in the mesh. The picture below is the nearly seamless planet at LOD(1) made of 24 quads, each with 32x32 vertice resolution and a 512x512 jpg texture running in Unity3d 5. It works but at close level there are seams. This will be resolved simply by having the next LOD(x) instantiate before getting close enough to see the seam but at core nerd level I want the seamless mesh.
So, I can make the seamless mesh but I can not realistically texture map it. I can also make the nurb surface from points and texture it at the expense of the edge vertices matching. I am at the split in the road but I want to have my cake and eat it too. Thoughts, comments, trolls...?
Thanks for reading =)
Footnote: For you pros I am not using seamless noise across the map I am using grasshopper to sew up my otherwise non perfect edges.
Other programs in the pipeline:
-WorldMachine 2
-Wilbur
-Photoshop
-Unity3d…
, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:
2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:
3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.
4) 9 new components have been added:
"Address To Location" - finds latitude and longitude coordinates for the given address.
"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.
5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!
Basically just forget about this yellow panel:
This panel is not valid anymore, so just use any unit you want.
6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone.
The version 0.0.2 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
And example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
Any new suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 5:13pm on March 1, 2017