uments:
1. You are targeting CATIA don't you? (not exactly tomorrow but ... soon) and/or SolidWorks (hello C# haven't we met before?).
2. You MUST deal with nested block instances instead of what you are trying to do right now (I'm talking about the real MERO things not abstract Lines and points). This is not doable with GH components I'm afraid (but it's rather easy with code).
3. You MUST deal with RDBMS in order to keep track with what's going on in your company per project per case per designer (who sells that bolt? what's his cat name? is he a reliable supplier? what I'm doing in life? ... that sort of "queries"). At this point: CATIA is 1% CAD things and 99% PLM stuff (Product Life cycle Management). We do want that since it's 21st century running don't we?.
I hear you: but these are 3 arguments ... indeed but ... hey who's counting? he he.
Method:
A. This def attached has a very simple C# that gets mesh Pts and makes a nice U/V style collection of points (DataTree in plain English).
B. Then we go to that umbrella sticks thingy: we can calculate anything (already the thing does "some") plus your collections of divided points (with the right way, he he) VS a given node: you said (Skype) that you want to calculate angles with these (from 2 to 6) in mind: obvious since you are doing real-life MERO things.
C. Then we could calculate the appropriate Planes for PlaneToPlane transformations: get a nested instance definition (the red things that you've showed to me yesterday) placed at 0,0,0 (Plane.WorldXY) and put in in every Plane collection related with every node (clash defection is an obvious must).
Case resolved, closed: what about that Vodka?
More in Skype
…
merely automates finding clear intersections between pairs of objects and then splits the objects along those intersection *curves*, deletes the trims, then joins the remains, and cycles on. But within the confusing Rhino Settings tolerance value, wherever surfaces actually just sort of come closely together, there *is* *no* clear intersection curve. So it bugs out and stops working EVERY time you try more than a dozen or two spheres.
Some software can do this by switching to volumetric pixels (voxels). $9K-$30K Geomagic Freeform is an example of this. It also fails sometimes, often due to memory issues, as you can imagine since it needs to fill all inner space of each sphere definition with 3D pixels.
Materialize Magics for $16K can often handle such Booleans well. It will take a seeming lifetime to figure out such often pirate software kludges though.
One thing you can try though is to simply drape a mesh or NURBS plane onto the top of your spheres.
There's a well known *reason* your Booleans are failing. Nobody here has yet even hinted at it:
The main reason is that Rhino/Grasshopper developers don't care about the human element. The math exists to make this work very fast, every time. It just has to join things *right*, incorporating human knowledge of kissing surfaces, instead of acting stupidly, like some pocket calculator. But that would involve hacks that make 99% of complex Booleans work instead of 10%, and we can't have that since it will be SLOWER for the other 1% that just happen to have no nearly kissing or really kissing surfaces.
You could also use the new Cocoon plugin to do a surface *around* your structures, with a given radius of extension beyond the spheres, then offset that surface back the same radius. That is 100% robust, but won't offer quite as sharp of intersections, more rounded, like most everybody wants anyway.
You can *test* Boolean failures, by running a Grasshopper intersection command, to see the intersection curves, and zoom in to see how badly many of them are, all knotted, or twisted, or even with gaps, often with gaps.
It's a math problem nobody at McNeel wants to solve, sorry.
Just write a check for $25K and spend six months taking notes, like I did, and you can merge your simple spheres finally.…
Added by Nik Willmore at 6:33pm on October 20, 2015
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.…
mmon.sdk ,but i herad its used in rhino5.
or example: the book grasshopper primer second edition ,page 98
i dont know what is the "doc.absolutetolerance" and where i can find about it....i dont kow it should be a class or a fuction,i tried to search the rhino4. net sdk,i cant find it ....maybe its my searching problem.
but according to the grasshopper primer, i indeed know many kind of Variables,many functions,basic structure, loops, and conditions,and what is onutil.xxxx and rhutil.xxxx.but i found all this imformation is not helpful enough to me when reading the examples downloaded from many disscussions.when i found a new variable or new funcion,i dont know where i can find the introduction about them,such as the upper coding:"doc.absolutetolerance".i tried to use the auto complete such as
dim xxxx as oncurve
xxxx. to find the class oncurve's funtions and variables ,but its too uneffcient.
-----------------------------------------------
And,i dont know the difference between the components vb script and dotnet vb script....
because i found when i type onutil. the auto complete has noting appear...and the variables declaring is not the same. in vb script dim xxxx as curve but in dotnet vb script its dim xxxx as oncurve,which is the same as the grasshopper primer teached me...but i guess.... the vb script component is just like the rhinoscript(not the same),and the dotnet vb script is more powerful than it. am i right?
------------------------------------------------
at last i dont know these.
Imports System Imports System.IO Imports System.Xml Imports System.Data Imports System.Drawing Imports System.Reflection Imports System.Collections Imports System.Windows.Forms Imports Microsoft.VisualBasic Imports System.Collections.Generic Imports System.Runtime.InteropServices
when i search google about them,the introduction about them is too professinal for me to understand......i just want to know what i can do by using them ...
-------------------------
sorry for disturbing you so much!!!
best regards!
yours truly
YUAN.T
…
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
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
basis" problem ... all of a sudden - quite recently - a girl posted the MITESIGF (Most Important Thread Even Seen In Grasshopper Forums). She doesn't even realized that: she's novice:
http://www.grasshopper3d.com/forum/topics/array-1
4. Why this MITESIGF is MITESIGF? For 2 reasons:
4.a: Wooden pairs (Beams) Profile Curves (belonging in some tree) MUST allow individual control on a per "item basis" (OK, that's obvious) - see Images posted in the thread. No attractor (or any other "global" policy) can cut the mustard here (to tell you the truth this happens in 99% of pure engineering cases, but they appear very rarely in GH Forums - if at all, mind). If the profile curves are defined with 5 points (or 9 for the double thing) we need "on-the-fly" control over this Array (like the radii in your Sphere Manipulator) :
4.b: Critical Bottom-to-Top issues arise: Create a "global" topology (call it "parent") - the beams - and then place real-life "components" (call them "childs") that affect (most probably) the "parent". OK, that's impossible to do with GH/Rhino (peace of cake with CATIA/Microstation) but you can "approximate" things up to a point. Alternatively: you can "trigger" some interest from GH/Rhino developers if they have any AEC market(s) in mind.
Topic 4.a requires the master-to-slave slider thingy (iterate over branches (index slider:master) > reset the 5 values (value slider:slave) > modify them on the fly > save > increase/decrease branch > ...).
Other than that my definitions are far more challenging than this simple case ... but ... anyway ... long is the path (and hilly).
more soon.
best, The Troll
…
ceros.
Public concerné /
Architectes et designers, utilisateurs de Rhino souhaitant paramétrer Rhinocéros à l’aide de Grasshopper,
programme associant des composants et une structure de graphe interagissants avec le modèle Rhino.
Une bonne connaissance de Rhinocéros est nécessaire. La langue de la formation est le français.
Structure et Objectif de la formation /
La formation se déroule sur 3 jours : les 2 premières journées sont consacrées aux « fondamentaux » de
Grasshopper avec en préambule une introduction au design et à l’architecture paramétrique et leurs impacts
dans la conception, la création et la construction.
La troisième journée sous forme d’atelier est dédiée à l’étude de cas concrets proposés par les stagiaires, qui,
quelques jours avant la formation, pourront envoyer leurs projets par mail à - info AT rhinoforyou DOT com -
Les stagiaires, après la formation, pourront rester en contact avec les formateurs de HDA par le biais du
blog complexitys.com et le twitter @HDA_Paris. La durée de cette formation permettra d’atteindre une
autonomie et une bonne compréhension basée sur des exemples concrets.
Programme ind icatif des notions traitéES pendan t la formation /
Introduction à la conception Paramétrique . Rhinoscript, Grasshopper: différences et similarités . Interface
graphique de Grasshopper . Objets, Données, Listes . Opérateurs scalaires : La mathématique de
Grasshopper . Gestions des données : la logique de Grasshopper . Vecteurs, Points, Lignes, Surfaces : La
géométrie de Grasshopper . Listes, Arbres, Branches . Le dessin paramétrique: exercices divers et exemples
. Références, Bibliographie, Support de cours . Ateliers d’architecture et design paramétrique (3ème jour) .
Moda lité de la formation /
Venir avec un PC portable équipé de Rhinocéros version 4.0 SR 7 et de la dernière version du plug-in
Grasshopper (téléchargeable sur www.grasshopper3d.com).
Le coût du stage de 3 jours est de 1050 € HT par personne.
Réserver votre place dès que possible car les places sont limitées à 10 participants maximum.
Inscriptions et renseignements: Jacques Hababou, info AT rhinoforyou DOT com
Pour en savoir plus sur l’architecture paramétrique: www.complexitys.com…
ger at the scale of rooms, walls and atria, but that of cells, grains and vapour droplets. Rather than the flow of people, services, or construction schedules, the focus becomes the flow of light, vapour, molecular vibrations and growth schedules: design from the inside out.
The sg2012 challenge, Material Intensities, is intended to dissolve our notion of the built environment as inert constructions enclosing physically sealed spaces. Spaces and boundaries are abundant with vibration, fluctuating intensities, shifting gradients and flows. The materials that define them are in a continual state of becoming: a dance of energy and information.Material potential is defined by multiple properties: acoustical, chemical, electrical, environmental, magnetic, manufacturing, mechanical, optical, radiological, sensorial, and thermal. The challenge for sg2012 Material Intensities is to consider material economy when creating environments, micro-climates and contexts congenial for social interaction, activities and organisation. This challenge calls for design innovation and dialogue between disciplines and responsibilities.sg2010 Working Prototypes strove to emancipate digital design from the hard drive by moving from the virtual to the actual in wrestling with the tangible world of physical fabrication. sg2011 Building the Invisible focused on informing digital design with real world data. sg2012 Material Intensities strives to energise our digital prototypes and infuse them with material behaviour. They have the potential to become rich simulations informed by the material dynamics, chemical composition, energy flows, force fields and environmental conditions that feed back into the design process.
More information can be found at http://www.smartgeometry.org
sg2012 take place at Rensselaer Polytechnic Institute, Troy, in upstate New York from 19-24 March 2012. The Workshop and Conference will be a gathering of the global community of innovators and pioneers in the fields of architecture, design and engineering.
The event will be in two parts, a four day Workshop 19-22 March, and a public conference beginning with Talkshop 23 March, followed by a Symposium 24 March. The event follows the format of the highly successful preceding events sg2010 Barcelona and sg2011 Copenhagen.…
ceros.
Public concerné /
Architectes et designers, utilisateurs de Rhino souhaitant paramétrer Rhinocéros à l’aide de Grasshopper, programme
associant des composants et une structure de graphe interagissants avec le modèle Rhino.
Une bonne connaissance de Rhinocéros est nécessaire. La langue de la formation est le français.
Structure et Objectif de la formation /
La formation se déroule sur 3 jours : les 2 premières journées sont consacrées aux « fondamentaux » de Grasshopper
avec en préambule une introduction au design et à l’architecture paramétrique et leurs impacts dans la conception, la
création et la construction.
La troisième journée sous forme d’atelier est dédiée à l’étude de cas concrets proposés par les stagiaires, qui, quelques
jours avant la formation, pourront envoyer leurs projets par mail à info AT rhinoforyou DOT com
Les stagiaires, après la formation, pourront rester en contact avec les formateurs de HDA par le biais du blog
complexitys.com et le twitter @HDA_Paris. La durée de cette formation permettra d’atteindre une autonomie et une
bonne compréhension basée sur des exemples concrets.
3 Formules possibles /
3 jours ( Initiation+Atelier ) : du lundi 20 septembre au mercredi 22 septembre
2 jours ( Initiation ) : lundi 20 et mardi 21 septembre
1 jour ( Atelier ) : mercredi 22 septembre
Programme ind icatif des notions traitéES pendan t la formation /
Introduction à la conception Paramétrique . Rhinoscript, Grasshopper: différences et similarités . Interface
graphique de Grasshopper . Objets, Données, Listes . Opérateurs scalaires : La mathématique de
Grasshopper . Gestions des données : la logique de Grasshopper . Vecteurs, Points, Lignes, Surfaces : La
géométrie de Grasshopper . Listes, Arbres, Branches . Le dessin paramétrique: exercices divers et exemples
. Références, Bibliographie, Support de cours . Ateliers d’architecture et design paramétrique (3ème jour) .
Moda lité de la formation /
Venir avec un PC portable équipé de Rhinocéros version 4.0 SR 7 et de la dernière version du plug-in
Grasshopper (téléchargeable sur www.grasshopper3d.com).
Le coût du stage est de 350 € HT/jour par personne.
Réserver votre place dès que possible car les places sont limitées à 10 participants maximum.
Inscriptions et renseignements: Jacques Hababou, info AT rhinoforyou DOT com
Pour en savoir plus sur l’architecture paramétrique: www.complexitys.com…